You are on page 1of 86

Software Architecture

New wine in old bottles?
(i.e., software architecture ≅ global design?,
architect ≅ designer)


  What is it, why bother?

  Architecture Design
  Viewpoints and view models
  Architectural styles
  Architecture asssessment
  Role of the software architect

SE, Software Architecture, Hans van Vliet, ©2008 2

The Role of the Architect

requirements solutions
architect developers

assess creates assess

visualises prescribes

appearance, architectural construction,
behaviour design co-operation

SE, Software Architecture, Hans van Vliet, ©2008 3

Pre-architecture life cycle

requirements quality



SE, Software Architecture, Hans van Vliet, ©2008 4

Characteristics   Iteration mainly on functional requirements   Few stakeholders involved   No balancing of functional and quality requirements SE. ©2008 5 . Software Architecture. Hans van Vliet.

the easy way stakeholders requirements quality (few) agreement architecture detailed design development implementation SE.Adding architecture. Software Architecture. ©2008 6 . Hans van Vliet.

Software Architecture. Hans van Vliet. ©2008 7 .Architecture in the life cycle stakeholders (many) requirements quality architecture agreement development SE.

©2008 8 . Software Architecture. Hans van Vliet.Characteristics   Iteration on both functional and quality requirements   Many stakeholders involved   Balancing of functional and quality requirements SE.

making development predictable SE.Why Is Architecture Important?   Architecture is the vehicle for stakeholder communication   Architecture manifests the earliest set of design decisions   Constraints on implementation   Dictates organizational structure   Inhibits or enable quality attributes   Architecture is a transferable abstraction of a system   Product lines share a common architecture   Allows for template-based development   Basis for training. Hans van Vliet. ©2008 9 . Software Architecture. gaining expertise.

Where did it start?  1992: Perry & Wolf  1987: J.A. program families  1972 (1969): Edsger Dijkstra. Sharp @ NATO Software Engineering conference:   “I think we have something in addition to software engineering [. Zachman.] This is the subject of software architecture. Architecture is different from engineering.P. ©2008 10 . program families  1969: I.. 1989: M.” SE. Hans van Vliet. Software Architecture. Shaw  1978/79: David parnas.

which comprise software elements. Addison-Wesley. 2003. ©2008 11 .) SE. and Kazman. the externally visible properties of those elements.   (from Bass. Software Architecture in Practice. Hans van Vliet. Clements. and the relationships among them. Software Architecture.Software Architecture. definition (2)   The software architecture of a system is the structure or structures of the system. SEI Series in Software Engineering.

  architectural styles.Software Architecture   Important issues raised in this definition:   multiple system structures.   rules and guidelines.   externally visible (observable) properties of components.   The definition does not include:   the process. SE. ©2008 12 . Hans van Vliet. Software Architecture.

Software Architecture. Hans van Vliet. or logical structure   process. ©2008 13 . or coordination structure   physical structure   uses structure   calls structure   data flow   control flow   class structure SE.Architectural Structures   module structure   conceptual.

2000. ©2008 14 . Software Architecture.) SE. definition (3)   Architecture is the fundamental organization of a system embodied in its components. their relationships to each other and to the environment and the principles guiding its design and evolution   (from IEEE Standard on the Recommended Practice for Architectural Descriptions.Software Architecture. Hans van Vliet.

SE.Software Architecture   Architecture is conceptual. Software Architecture.   Architecture is about fundamental things.   Some people have slightly different ideas. Hans van Vliet. ©2008 15 .   Architecture exists in some context.

portability. functionality. usability   And some are not observable via execution: modifiability. integrability. Hans van Vliet. Software Architecture. testability SE. ©2008 16 . reusability.   Some qualities are observable via execution: performance.Software Architecture & Quality   The notion of quality is central in software architecting: a software architecture is devised to gain insight in the qualities of a system at the earliest possible stage. availability. security.

Hans van Vliet.Overview   What is it. ©2008 17 . Software Architecture. why bother?   Architecture Design   Viewpoints and view models   Architectural styles   Architecture asssessment   Role of the software architect SE.

Ch 7)   Choose module to decompose   Refine this module:   choose architectural drivers (quality is driving force)   choose pattern/tactic that satisfies drivers   apply pattern   Repeat steps SE. Hans van Vliet. Software Architecture.Attribute-Driven Design (Bass et al. ©2008 18 .

within user interface: security ⇒ authenticate users   Lower-level. Hans van Vliet. ©2008 19 .Example ADD iterations   Top-level: usability ⇒ separate user interface ⇒ Seeheim/three tier architecture   Lower-level. within data layer: availability ⇒ active redundancy SE. Software Architecture.

Hans van Vliet. Software Architecture. ©2008 20 .Global workflow in architecture design synthesis architecture context backlog evaluation evaluation requirements results SE.

Software Architecture. Hans van Vliet. options and decisions A designer is faced with a series of design issues   These are sub-problems of the overall design problem.   This process involves choosing the best option from among the alternatives.   Each issue normally has several alternative solutions (or design options)   The designer makes a design decision to resolve each issue.Design issues. SE. ©2008 21 .

fat-client client in a Programmed in Java separate client-server user interface client layer style thin-client Programmed in Visual Basic Programmed in C++ no separate monolithic user interface layer SE. Hans van Vliet. Software Architecture. ©2008 22 . Decision space The space of possible designs that can be achieved by choosing different sets of alternatives.

Hans van Vliet. Software Architecture.. fat-client client in a separate flexibility client-server user interface client layer style thin-client layered MVC no separate monolithic user interface layer SE.. Tree or graph?   Issues and options are not independent . ©2008 23 .

Software Architecture. Hans van Vliet. ©2008 24 .Tactics  Approaches to attaining the right level of quality for a given quality attribute.g. SE. authentication for Security negatively influences Usability.  Some tactics negatively influence other attributes => need for balancing  E.

Tactics for Availability and Reliability

 Fault detection: ping, heartbeat, exception
 Fault recovery: voting/polling, active redundancy
(hot restart), passive redundancy (warm restart),
rollback and spare
  Fault prevention: removal from service,
transactions, monitoring
 Availability may also profit from Security tactics
such as Authentication, Limit Access and Intrusion
 More details: see Bass et al, 2003

SE, Software Architecture, Hans van Vliet, ©2008 25

Why is documenting design decisions

  Prevents repeating (expensive) past steps
  Explains why this is a good architecture
  Emphasizes qualities and criticality for

  Provides context and background
  Note: not all decisions are of a technical nature

SE, Software Architecture, Hans van Vliet, ©2008 26

Uses of design decisions

  Identify key decisions for a stakeholder
  Make the key decisions quickly available. E.g., for introducing
new people.
  ..., Get a rationale, Validate decisions against requirements
  Evaluate impact
  If we want to change an element, what are the elements
impacted (decisions, design, issues)?
  ..., Cleanup the architecture, identify important architectural

SE, Software Architecture, Hans van Vliet, ©2008 27

Elements of a design decision

 Issues: design issues being addressed
 Decision
 Status: e.g., pending, approved
 Assumptions: underlying assumptions
 Alternatives
 Rationale; the why of the decision taken
 Implications: e.g. need for further decisions

SE, Software Architecture, Hans van Vliet, ©2008 28

why bother?   Architecture Design   Viewpoints and view models   Architectural styles   Architecture asssessment   Role of the software architect SE.Overview   What is it. ©2008 29 . Software Architecture. Hans van Vliet.

Software Architecture. ©2008 30 . Hans van Vliet.Which type of questions do viewpoints answer?   How much will it cost?   How secure will the system be?   Will it perform?   How about maintenance cost?   What if requirement A is replaced by requirement B? SE.

Hans van Vliet.Analogy with building architecture   Overall picture of building (client)   Front view (client. “beauty” committee)   Separate picture for water supply (plumber)   Separate picture for electrical wiring (electrician)   etc SE. Software Architecture. ©2008 31 .

for technicians   A small sample … SE. ©2008 32 .Architecture presentations in practice   By and large two flavors:   Powerpoint slides – for managers. consultants. users. Software Architecture. etc   UML diagrams. Hans van Vliet.

Software Architecture.SE. ©2008 33 . Hans van Vliet.

SE. Hans van Vliet. Software Architecture. ©2008 34 .

©2008 35 . Software Architecture. Hans van Vliet.SE.

Hans van Vliet.SE. Software Architecture. ©2008 36 .

Software Architecture. Hans van Vliet.SE. ©2008 37 .

©2008 38 . …   Different representations   For different people   For different purposes   These representations are both descriptive and prescriptive SE.So. Software Architecture. Hans van Vliet.

©2008 39 . Software Architecture. Hans van Vliet.IEEE model for architectural descriptions Mission Environment System Architecture Architecture Stakeholder Description Rationale Concern Viewpoint View Library Viewpoint Model SE.

or concerns relative to. team. Hans van Vliet. SE.   View: a representation of a whole system from the perspective of a related set of concerns. ©2008 40 . or organization (or classes hereof) with interests in.Some terms (from IEEE standard)   System stakeholder: an individual. Software Architecture.   Viewpoint: A viewpoint establishes the purposes and audience for a view and the techniques or methods employed in constructing a view. a system.

integrator   Maintainer   Manager   Quality assurance people   Government agency SE.Stakeholders   Architect   Requirements engineer   Designer (also of other systems)   Implementor   Tester. Hans van Vliet. Software Architecture. ©2008 41 .

©2008 42 . Software Architecture. Hans van Vliet.Viewpoint specification   Viewpoint name   Stakeholders addressed   Concerns addressed   Language. modeling techniques SE.

Software Architecture.Kruchten’s 4+1 view model End-user Programmers Functionality Software management Implementation Logical Viewpoint Viewpoint Scenarios Process Deployment Viewpoint Viewpoint Integrators System engineers Performance Topology Scalability Communications SE. ©2008 43 . Hans van Vliet.

. Hans van Vliet.e. classes and interactions amongst them).   Typically. it shows the key abstractions (e. i. SE.4 + 1: Logical Viewpoint   The logical viewpoint supports the functional requirements. Software Architecture. the services the system should provide to its end users.g.. ©2008 44 .

Hans van Vliet.4 + 1: Process Viewpoint   Addresses concurrent aspects at runtime (tasks. Software Architecture. and fault-tolerance. system availability. ©2008 45 . concurrency and distribution. processes and their interactions)   It takes into account some nonfunctional requirements. such as performance. threads. system integrity. SE.

and objects-must be mapped onto the various nodes. and implementation viewpoints-networks. processes. reliability (fault-tolerance). and scalability.4 + 1: Deployment Viewpoint   The deployment viewpoint defines how the various elements identified in the logical.   It takes into account the system's nonfunctional requirements such as system availability. tasks. performance (throughput). SE. Software Architecture. ©2008 46 . process. Hans van Vliet.

Hans van Vliet.4 + 1: Implementation Viewpoint   The implementation viewpoint focuses on the organization of the actual software modules in the software-development environment. SE.   The software is packaged in small chunks- program libraries or subsystems-that can be developed by one or more developers. Software Architecture. ©2008 47 .

  it validates and illustrates the architecture design.   This viewpoint is redundant with the other ones (hence the "+1"). Software Architecture. SE. use cases) to show that the elements of the four viewpoints work together seamlessly. both on paper and as the starting point for the tests of an architectural prototype. Hans van Vliet. but it plays two critical roles:   it acts as a driver to help designers discover architectural elements during the architecture design. ©2008 48 .4 + 1: Scenario Viewpoint   The scenario viewpoint consists of a small subset of important scenarios (e.g..

Software Architecture. shared data (repository). class   Component and connector (C & C) views   These are runtime elements   Process (communication). uses. ©2008 49 . layered. implementation SE.Architectural views from Bass et al (view = representation of a structure)   Module views   Module is unit of implementation   Decomposition. Hans van Vliet. client-server   Allocation views   Relationship between software elements and environment   Work assignment. concurrency. deployment.

Software Architecture. relation “inherits from” SE. layer n can only use modules from layers <n   Class: generalization. larger modules are composed of smaller ones   Uses: relation is “uses” (calls. passes information to. Hans van Vliet. ©2008 50 .Module views (static)   Decomposition: units are related by “is a submodule of”. Important for modifiability   Layered is special case of uses. etc).

Component and connector views (dynamic)   Process: units are processes. connected by communication or synchronization   Concurrency: to determine opportunities for parallelism (connector = logical thread)   Shared data: shows how data is produced and consumed   Client-server: cooperating clients and servers SE. Hans van Vliet. ©2008 51 . Software Architecture.

Software Architecture. Hans van Vliet. ©2008 52 .Allocation views   Deployment: how software is assigned to hardware elements   Implementation: how software is mapped onto file structures   Work assignment: who is doing what SE.

Hans van Vliet.How to decide on which viewpoints   What are the stakeholders and their concerns?   Which viewpoints address these concerns?   Prioritize and possibly combine viewpoints SE. ©2008 53 . Software Architecture.

Hans van Vliet.A caveat on quality   A view can be used to assess one or more quality attributes   E. some type of module view can be used to assess modifiability   It should then expose the design decisions that affect this quality attribute SE. ©2008 54 .g.. Software Architecture.

Software Architecture. Hans van Vliet.Overview   What is it. ©2008 55 . why bother?   Architecture Design   Viewpoints and view models   Architectural styles   Architecture asssessment   Role of the software architect SE.

  Examples:   main program with subroutines   data abstraction   implicit invocation   pipes and filters   repository (blackboard)   layers of abstraction SE. Software Architecture. Hans van Vliet. ©2008 56 .Architectural styles   An architectural style is a description of component and connector types and a pattern of their runtime control and/or data transfer.

©2008 57 . with <problem>   THEN for some <reasons>. for example <examples>. Software Architecture. Hans van Vliet. apply <pattern> to construct a solution leading to a <new context> and <other patterns> SE.General flavor of a pattern   IF you find yourself in <context>.

  No standard notation has emerged yet. ©2008 58 . Software Architecture. SE.Components and Connectors   Components are connected by connectors.   They are the building blocks with which an architecture can be described. Hans van Vliet.

symbol table. scheduler. E. ©2008 59 . SE. adt. filter.g.g.g. server. State is retained between invocations of operations. E. E. function. control module.   memory: maintains a collection of persistent data.   manager: contains state + operations.   controller: governs time sequence of events. Software Architecture.Types of components   computational: does a computation of some sort. file system. E. Hans van Vliet.g. data base.

pipes)   implicit invocation   message passing   shared data (e. Hans van Vliet. Software Architecture. ©2008 60 .g.Types of connectors   procedure call (including RPC)   data flow (e. blackboard or shared data base)   instantiation SE.g.

Characteristics of the reqs’s guide the designer in his choice for a particular style. and control structure (order of execution of components)   variants   examples SE.   solution: in terms of components and connectors (choice not independent).   context: characteristics of the environment that constrain the designer. ©2008 61 .Framework for describing architectural styles   problem: type of problem that the style addresses. Software Architecture. req’s imposed by the style. Hans van Vliet.

objects. control is decentralized variants: caused by language facilities SE. usually.Abstract-data-type style problem: identify and protect related bodies of information. OO-languages which provide the class-concept solution:   system model: component has its own local data (= secret it hides)   components: managers (servers. adt’s)   connectors: procedure call (message)   control structure: single thread. Software Architecture. ©2008 62 . Data representations likely to change. Hans van Vliet. context: OO-methods which guide the design.

Software Architecture. Data is long-lived. compilers.Repository style Client Client Shared Data Client problem: manage richly structured information. to be manipulated in many different ways. ©2008 63 . components: one memory. Hans van Vliet. may depend on input or state of computation variants: traditional data base systems. Independent computational elements. blackboard systems SE. context: shared data to be acted upon by multiple clients solution: system model: centralized body of information. many computational connectors: direct access or procedure call control structure: varies.

OSI model) solution:   system model: hierarchy of layers. hierarchical classes of services.g. Hans van Vliet. often limited visibility   components: collections of procedures (module)   connectors: (limited) procedure calls   control structure: single or multiple threads variants: relaxed layering SE..Layered style Layern Layer2 Layer1 problem: distinct. “Concentric circles” of functionality context: a large system that requires decomposition (e. Software Architecture. ©2008 64 . virtual machines.

Software Architecture.Typical layer architecture SE. Hans van Vliet. ©2008 65 .

©2008 66 . Software Architecture. Hans van Vliet.Model-View-Controller (MVC) style Controller View n n Model problem: separation of UI from application is desirable due to expected UI adaptations context: interactive applications with a flexible UI solution:   system model: UI (View and Controller Component(s)) is decoupled from the application (Model component)   components: collections of procedures (module)   connectors: procedure calls   control structure: single thread variants: Document-View SE.

Hans van Vliet. ©2008 67 .Other  Pipe-filter  Peer-to-peer  Client-server  Service Oriented Architecture SE. Software Architecture.

©2008 68 . Hans van Vliet. Software Architecture.Overview   What is it. why bother?   Architecture Design   Viewpoints and view models   Architectural styles   Architecture asssessment   Role of the software architect SE.

modifiability. Hans van Vliet.Architecture evaluation/analysis   Assess whether architecture meets certain quality goals.r.t. reliability. Software Architecture. performance   Mind: the architecture is assessed. such as those w. maintainability. ©2008 69 . while we hope the results will hold for a system yet to be built SE.

Software Architecture. ©2008 70 .Software Architecture Analysis Software implementation System architecture properties Properties Qualities SE. Hans van Vliet.

Software Architecture. etc SE. ©2008 71 .Analysis techniques   Questioning techniques: how does the system react to various situations. often make use of scenarios   Measuring techniques: rely on quantitative measures. Hans van Vliet. simulation. architecture metrics.

often already available   change-cases . availability)   far-into-the-future scenarios .more extreme form of change-case   risk scenarios SE.Scenarios in Architecture Analysis   Scenarios as “what if”-situations   use-cases .how does the architecture react to change?   stress situations . Software Architecture.extreme conditions that need to be met (performance. ©2008 72 . Hans van Vliet.

Hans van Vliet. Software Architecture. ©2008 73 .Preconditions for successful assessment   Clear goals and requirements for the architecture   Controlled scope for the assessment   Cost-effectiveness   Key personnel availability   Competent evaluation team   Managed expectations SE.

Hans van Vliet. i. ©2008 74 . how well quality attributes interact.e.Architecture Tradeoff Analysis Method (ATAM)   Reveals how well architecture satisfies quality goals. how they trade off   Elicits business goals for system and its architecture   Uses those goals and stakeholder participation to focus attention to key portions of the architecture SE. Software Architecture.

Phases in ATAM  0: partnership. preparation (informally)  1: evaluation (evaluation team + decision makers. ©2008 75 . one day)  2: evaluation (evaluation team + decision makers + stakeholders. Hans van Vliet. two days)  3: follow up (evaluation team + client) SE. Software Architecture.

and how difficult)   Analyze architectural approaches   Brainstorm and prioritize scenarios   Analyze architectural approaches   Present results SE. Hans van Vliet. Steps in ATAM (phase 1 and 2)   Present method to stakeholders   Present business drivers (by project manager of system)   Present architecture (by lead architect)   Identify architectural approaches/styles   Generate quality attribute utility tree (+ priority. ©2008 76 . Software Architecture.

M) Performance Throughput 150 transactions/sec Training Utility Usability Normal operations Database vendor releases Maintainability new version SE.Example Utility tree Transaction response time (H. Software Architecture. ©2008 77 . Hans van Vliet.

Outputs of ATAM   Concise presentation of the architecture   Articulation of business goals   Quality requirements as a set of scenarios   Mapping of architectural decisions to quality requirements   Set of sensitivity points and tradeoff points   Set of risks. Hans van Vliet. Software Architecture. ©2008 78 . risk themes SE. nonrisks.

Software Architecture. ©2008 79 .Important concepts in ATAM   Sensitivity point: decision/property critical for certain quality attribute   Tradeoff point: decision/property that affects more than one quality attribute   Risk: decision/property that is a potential problem   These concepts are overlapping SE. Hans van Vliet.

why bother?   Architecture Design   Viewpoints and view models   Architectural styles   Architecture asssessment   Role of the software architect SE. Hans van Vliet. Software Architecture. ©2008 80 .Overview   What is it.

Role of the software architect   Key technical consultant   Make decisions   Coach of development team   Coordinate design   Implement key parts   Advocate software architecture SE. Software Architecture. Hans van Vliet. ©2008 81 .

©2008 82 .for whatever attribute seems important  To guard the architecture . Hans van Vliet.understand their wishes.Responsibilities for the Software Architect  To communicate with stakeholders .during construction SE. provide rationale  To abstract and model . Software Architecture. obtain priorities.provide views for stakeholders  To create the architecture .based on architecture styles/patterns  To assess quality .

in UML style diagrams)  List important quality attributes for the system  Discuss how they are guaranteed by the chosen architecture.  Identify risks and how to manage them  Construct Enterprise Functional Diagrams (EFDs) (See presentation by Sjaak on Dec.Software Architecture within ICT-E  Describe system context  Identify external parties on which you depend  Identify stakeholders  List views required to satisfy these stakeholders  Provide overall structure and views of the intended system (e. Hans van Vliet. Software Architecture.. ©2008 83 .g. 22) SE.

Paradigm and ArgoUML  Round-trip software architectures?  Apply architecture styles and patterns   Most important: Rationale SE. e. . Hans van Vliet.Vis. Software Architecture.Things to Remember for ICT-E  Sufficient level of detail!  Sufficiently high-level!  Security flaws!  Know your (end-)users!  Model your system in its context!  Use tools.g. ©2008 84 .

©2008 85 .Summary   ``new’’ and immature field   proliferation of terms: architecture . Hans van Vliet. Software Architecture.idiom   architectural styles and design pattern describe (how are things done) as well as prescribe (how should things be done)   tactics   stakeholder communication   early evaluation of a design   transferable abstraction pattern .framework .

IEEE Software.   Philippe B. 2000. Pattern-Oriented Software Architecture: A System of Patterns. November 1995. Part II: 2001.Further reading   Mary Shaw and David Garlan. Design Patterns: Elements of Reusable Object-Oriented Software..   Erich Gamma et al. Software Architecture.   Frank Buschmann et al.. 12(6):42-50. Sofware Architecture in Practice.   Len Bass et al.   C. Design & Use of Software Architectures. Applied Software Architecture. 1996. SE. Perspectives of an Emerging Discipline. Kruchten. ©2008 86 . Hans van Vliet. 1995. Hofmeister et al.   Jan Bosch. 2003 (2nd edition). The 4+1 view model of architecture. Software Architecture.. 1999. 1995.