Software Architecture

Motivation, Qualities and Development Cycle

June 2001

Siegfried ReichSunTREC Salzburg

siegfried.reich@salzburgresearch.at

2

Overview

Envisioning Architecture: Motivation, Definition, Development Cycle

Creating and Analysing Architectures: Qualities and Architectural Styles

Developing Architectures: Unified Process (UP) and Phases

Discussion: Implications for REGNET

3

Motivation: The Vasa (Bass, 1998)

King Gustavus Adolphus was at war with Poland and ordered the biggest battleship ever to be built (the "Vasa").

The ship was built, sent off to Poland and fired her guns in salute on leaving Stockholm's harbour in August 1628. She rolled over and sank immediately.

Lessons learned: enterprise goals influence requirements which lead to an architecture which in turn leads to a system. The architecture is based on the architect's experience and the technical facilities of the time - and both were not up to the needs in the case of the Vasa.

goals architecture system

4

Definition of "Architecture"

Following Bass (Bass, 1998) a software architecture is the structure of the system which comprises its components, the externally visible properties of these

components and their relationships.

5

Why Architectures?

We need architectures in order to (Jacobson et al., 1999) understand the system organise the system's development foster re-use evolve the system

This can/will be part of thetechnology implementationplan (TIP)

6

Influences on the Architecture

Architects are influenced by Customers and end users Developing organisation Technical environment Their (i.e., the architects')

experience

Architecture development is not a linear process: the environment influences the architecture which in turn influences the environment ("Feedback Loop", Lehmann, 1995).

Requirements: these are almost never understoodcompletely, hence involvementof stakeholders at early stagesand reviews are essential.

7

The Architecture Cycle 1/2

The architecture affects the structure of the developing organisation (e.g., individual groups work on the components identified)

The architecture can affect the enterprise goals of the developing organisation (e.g., focus on certain markets)

The architecture can affect the customer requirements for the next iteration of their system

The process of developing that system will affect the architect's experience

Few systems may influence the software engineering culture (e.g., RDBMS, CORBA, the WWW)

8

The Architecture Cycle 2/2

Architect

Customers and end users

Developing organisation

Technical environment

Architect's experience

Requirements

architecture

system

REGNET Architecture Cycle

Content Group, EU

Technical Group

Architects ("us")

9

Steps to Develop a System

Identifying the business case(s) Understanding the requirements (e.g., with use

cases, prototype development, etc.) Creating or selecting the architecture Communicating the architecture (e.g., using

Architecture Definition Languages (ADL), Unified Modelling Language (UML), etc.)

Analysing and evaluating the architecture Implementing the architecture (including ensuring its

conformance with the specification)

10

Some Practical Guidelines

Architecture should be done by a single architect or small group

Have a list of requirements at hand Document the architecture using an agreed notation Review the architecture with your stakeholders Use well defined modules that encapsulate properties

that might be subject to change The modules should allow teams to separately work on

their implementation Never rely on a particular version of a tool or product Modules that produce data should be separate from

those that consume data. This tends to increase modifiability.

11

Module Structure, Uses Structure

Information hiding: Interfaces of modules only reveal those aspects that are unlikely to change: the implementation details remain hidden.

Simplicity: modules should be simple enough to be understood on their own.

Modularity: modules should be exchangeable without affecting other modules.

Dependencies: the uses structure (of a module's procedures) is important for the runtime behaviour and for checking implications of changes, e.g. procedure p1 of module m1 uses p2 in module m3 - does that imply that we need to change m3 just because we modify p1?

Layering: the uses structure thus affects the layering of the modules.

12

Introduction to Quality Attributes

Architectural qualities describe the characteristics of a system: systems are often re-designed not because they are functionally deficient but because they are hard to maintain, port or are too slow, etc.

Architectural qualities can never be achieved in isolation: portability for instance, will typically hurt performance.

Qualities are separated into system qualities, business qualities, and architectural qualities.

13

Qualities 1/4

System qualities discernible at runtime Performance (e.g., intercomponent communication,

parallelism, etc.) Security (e.g., secure kernels, authentication servers,

etc.) Availability (e.g., fault tolerance with redundant

components, etc.) Functionality (i.e., work for what the system was

intended for) Usability: further broken into learnability, efficiency,

memorability, error avoidance, error handling, etc.

14

Qualities 1/4 in REGNET

Performance (e.g., intercomponent communication, parallelism, etc.): response time for queries, scalability (data, clients), etc.

Security (e.g., secure kernels, authentication servers, etc.): secure transactions (B2C, B2B)

Availability (e.g., fault tolerance with redundant components, etc.): downtime in seconds, replication of components, etc.

Functionality (i.e., work for what the system was intended for): querying (quality vs. response time), shopping, autonomy

of regional services, individualisation, data entry, publishing

Usability: further broken into learnability, efficiency, memorability, error avoidance, error handling, etc.

15

Qualities 2/4

System qualities not discernible at runtime Modifiability (e.g., modularised and encapsulated

components, etc.) Portability (e.g., via portability layer, etc.) Reusability (e.g., loose coupling of components,

etc.) Integrability (e.g., consistent component

interfaces, allowance for incremental builds, etc.) Testability (e.g., modularised and encapsulated

components, incremental builds, etc.) These qualities will form the basis for metrics to be

used for evaluating the REGNET architecture.

16

Qualities 2/4 in REGNET

Modifiability (e.g., modularised and encapsulated components, etc.): which components do we plan to modify

Portability (e.g., via portability layer, etc.): what platforms/systems do we need to support?

Reusability (e.g., loose coupling of components, etc.): important for technology implementation plan (TIP)

Integrability (e.g., consistent component interfaces, allowance for incremental builds, etc.): which existing components and interfaces (standards) do

we need to integrate? Testability (e.g., modularised and encapsulated components,

incremental builds, etc.)

17

Qualities 3/4

Business qualities Time-to-market Costs of the development effort Projected life-time of the system which affects e.g.

modifiability, etc. Targeted market (mass market vs. specific market)

which may impact portability and/or security aspects.

Use of legacy systems which implies extensive integration facilities.

18

Qualities 4/4

Architectural qualities Conceptual integrity: have one ( few)

architect(s), one set of design ideas, etc. Correctness and completeness Buildability, i.e., can the system actually be built in

a timely manner

19

The Architecture Development Process

The technical architecting process

The organisational architecting process: leading,

communicating, consulting, etc.

Architecturalrequirements

Structuring(Analysis, Design)

Evaluation(Implementation,

Testing)

cycle n+1

rework

20

Unified Modeling Language

Standardised language to support ... ... phases of the software life cycle (SLC) ... communication between stakeholders ... documentation of the results achieved ... development of a broad range of tools

UML and the SLC Every diagram can be used in every phase! Use Cases focus on requirements Activity/State/Collaboration Diagrams focus

on analysis Class/Package diagrams focus on design and

implementation Use Cases Test

21

Workflows and Phases

CoreWorkflows

Phases

Requirements

Analysis

Design

Implementation

Test

Inception Elaboration Construction Transition

iter#1

iter#2

--- --- --- ---iter#n-1

iter#n

Use Case driven Architecture centric

An iteration in theelaboration phase

Phases of a system's cycle (Unified Process, UP)

CoreWorkflows

Requirements

Analysis

Design

Implementation

Test

22

Workflow - Requirements Capture

Candidate Requirements List requirements of stakeholders in a feature list

Understand system context If project complexity requires build a domain or

business model to understand/clarify the system context

Capture functional requirements In a use-case model

Capture non-functional requirements Supplementary requirements description

23

Summary and Conclusions for REGNET

Architectures are important for understanding systems and organising the developing of systems fostering re-use and evolving systems.

There is no process or method that guarantees a successful architecture (and subsequent system).

Have iterations!

24

References

Bass, L., Clements, P., and Kazman, R. Software Architecture in Practice. Addison-Wesley, 1998.

Bredemeyer, Software Architecting - How is Software Architecture Created? Available from http://www.bredemeyer.com/, 2001.

Jacobson, I., Booch G., and Rumbaugh, J. The Unified Software Development Process. Addison-Wesley, 1999.

Lehmann, M. Process Improvement - The Way Forward, keynote at CAiSE ’95, Jyväskylä, Finland, Springer Verlag, LNCS 932, 1995.

25

Architectural Styles

These are in some ways analogous to architectural styles in building, such as Roman, Gothic, etc.

Architectural styles consist of some key features and rules for combining them.

Architectural styles are determined by the component types (e.g., data repository,

process, etc.) a topological layout semantic constraints (e.g., a data repository may

not itself change the values stored in it, etc.) a set of connectors (e.g., procedure calls, sockets,

data streams, etc.)

26

Style 1: Data-centred Architectures

Integrability of data is key Coordination via data store Clients can be added easily (good scalability of clients) If clients execute as separate processes this is referred

to as client-server style

Shared Data

ClientClient Client

ClientClient Client

computational component

passive data component

27

Style 2: Data-flow Architectures

Reuse and modifiability are key System is seen as a series of transformations of data E.g., batch style or UNIX pipes Pro: eases maintenance, high reusability (of

independent components) Con: batch mentality makes interactive applications

difficult, ordering of components can be tricky, performance can be poor as input/output have to be simple, e.g., unstructured ASCII data, so each component has to do parsing.

Validate Sort ReportUpdateTape Tape Tape

Tape

Tape Page

passive data component

28

Style 3: Virtual Machine Architectures

Goal is to achieve portability Interpreters, e.g., Java, as examples Performance costs due to additional computation

Program Data

InterpretationEngine

Program Being Interpreted

Internal State

Program Instructions

Selected Instruction

Selected Data

UpdatesData

Output

Input

State Data

29

Style 4: Call-And-Return Architectures

Goals are modifiability and scalability E.g., main-subroutine architectures, remote

procedure call systems, object-oriented systems The main-subroutine architecture decomposes

programs into smaller pieces to help achieve modifiability.

Main

Sub 1 Sub 2 Sub 3

30

Call-And-Return Architectures cont.

The object-oriented style: access to objects' internal states via interfaces only ( achieve modifiability via encapsulation).

Object

Object

Object

31

Call-And-Return Architectures cont.

Layered systems: higher layer builds on functionality provided by the lower layer

Goals are modifiability and portability

User Interface

Useful System

Basic Utility

Core