1. Software Architecture Alan Kelon Oliveira de Moraes akom@cin.ufpe.br Feb 12, 2006 – Recife

2. Motivation ● Size and complexity of software systems increases ● Problems of developing large-scale software systems ● Patterns have emerged informally over time ● People recognize the need for a more disciplined approach

3. History: Pre-1990 ● Dijkstra published the first paper to document the design of a software system using hierarchical layers [Dijkstra, 1968] ● The first reference to “Software Architecture” [NATO, 1969] ● Parnas described the use of modularization and information hiding [Parnas, 1972] ● Stevens et al introduced the notions of module coupling and cohesion [Stevens, 1974]

4. History: 1990-1998 ● Software Architecture as distinct discipline ● The 1990s is the decade of software architecture [Perry and Wolf, 1992] ● The first book on software architecture [Witt, 1994]. ● The first method of a SEI series was Software Architecture Analysis Method (SAAM) [Kazman et al., 1994]. ● The 4+1 Model View Is published as architecture method of RUP [Kruchten, 1995] ● Another book, The Art of System Architecting, nicely filled the gap between system and software [Rechtin, 1997] ● Software architecture really started to bloom!

5. History: 1990-2006 ● First IFIP Conference on Software Architecture (1999) ● Software Architecture has emerged as apropriate level to deal software quality [Dobrica et al., 2002] ● New methods such as SAAM [Kazman et al., 1994], BAPO [Obbink et al., 2000] and ATAM [Clements et al., 2002] emerged or consolidated ● From basic research to an essential element of software system design and construction [Shaw and Clements, 2006]

7. Definition ● Consist of two parts: Macroarchitecture and microarchitecture [Dobrica et al., 2002] ● [Perry and Wolf, 1992 ][Shaw and Garlan, 1996] The structure of components in a program or system, their interrelationships, and the principles and guides that control the design and evolution in time. ● See http://www.sei.cmu.edu/architecture/definitions.h tml for 60 more definitions...

8. Definition ● [Clements et al., 1998] The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

9. Software architecture ● Most definitions indicate that an architecture [Eeles] – is concerned with both structure and behavior – is concerned with significant decisions only – may conform to an architectural style – is influenced by its stakeholders and its environment, – embodies decisions based on rationale.

10. Roles of a SA ● Communication among stakeholders ● Early design decisions ● Reuse on several levels ● First approach to achieving quality attributes ● Basis for system analysis

11. An architecture defines structure ● Defines the composition of structural elements, their relationships, their interfaces, and their partitioning.

12. An architecture defines structure ● A structural element may be – a subsystem – a process – a library – a database – a computational node – a legacy system – an off-the-shelf product

13. An architecture defines behavior ● An architecture defines the interactions between these structural elements ● These interactions that provide the desired system behavior

14. An architecture focuses on significant elements ● It is not concerned with defining all of the structure and all of the behavior ● Significant elements are those that have a long and lasting effect, such as the major structural elements, those elements associated with essential behavior, and those elements that address significant qualities such as reliability and scalability ● An architecture is an abstraction of the system that helps an architect manage complexity.

15. Architecture vs. Design ● Architecture – Specify the properties of components and their interactions ● Design – Involves algorithm, data structures, and realization

16. An architecture embodies decisions based on rationale ● An important aspect of an architecture is not just the end result, the architecture itself, but the rationale for why it is the way it is. ● Document the decisions that have led to this architecture and the rationale for those decisions.

17. An architecture may conform to an architectural style ● Many systems have a similar solution structure – This similarity can be described as an architectural style, which can be thought of as a particular kind of pattern ● Problems in practice already solved ● Like a pattern, an architectural style represents a codification of experience, and it is good practice for architects to look for opportunities to reuse such experience.

18. A style consists of: ● a set of component types (e.g., process, procedure) that perform some function at runtime ● a topological layout of the components showing their runtime relationships ● a set of semantic constraints ● a set of connectors (e.g., data streams, sockets) that mediate communication among components

19. Styles [Garlan and Shaw, 1994] ● Pipes and Filters ● Data Abstraction and Object-Oriented Organization ● Event-based, Implicit Invocation ● Layered Systems ● Repositories ● Table Driven Interpreters ● Heterogeneous Style

20. ● Pipes and Filters ● Advantages – understand the overall input/output behavior – reuse – systems can be easily maintained ● Disadvantages – batch organization of processing – performance

21. An architecture balances stakeholder needs ● Created to ultimately address a set of stakeholder needs – The end user is concerned with intuitive and correct behavior, performance, reliability, usability, availability, and security. – The system administrator is concerned with intuitive behavior, administration, and tools to aid monitoring. – The marketer is concerned with competitive features, time to market, positioning with other products, and cost. – The customer is concerned with cost, stability, and schedule. – The developer is concerned with clear requirements, and a simple and consistent design approach. – The project manager is concerned with predictability in the tracking of the project, schedule, productive use of resources, and budget. – The maintainer is concerned with a comprehensible, consistent, and documented design approach, and the ease with which modifications can be made.

22. ● Software architecture as a bridge [Garlan, 2000]

23. An architecture influences team structure ● Conway’s Law (1968) – Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. – If you have four groups working on a compiler, you'll get a 4-pass compiler. ● Ovaska et al., 2003 – Architecture as a Coordination Tool in Multi-site Software Development

24. Characteristics of a software architect ● He is a technical leader – The architect role may be fulfilled by a team ● Understands the software development process ● Has knowledge of the business domain ● Has technology knowledge – However, architects do not need to be technology experts

25. Characteristics of a software architect ● Has design skills ● Has programming skills ● Is a good communicator ● Is a negotiator ● Makes decisions

26. Architectual Design Activities

27. Attribute-Based Design RiSE’s Seminars Bass’s book :: Chapter 07 Eduardo Cruz

28. Summary Designing the Architecture (Chapter 7)  Evolutionary Delivery Life Cycle  When Can I begin Designing?  How to identify the architectural drivers?  Attribute-Driven Design

29. Evolutionary Delivery Life Cycle Software Concept Preliminary Requirements Analysis Design of Architecture and System Core Develop a Version Incorporate Customer Feedback Elicit Customer Feedback Deliver the Version Deliver Final Version

30. Evolutionary Delivery Life Cycle Goal  To get user and customer feedback Microsoft strategy  Skeletal system Early Low-fidelity Updates Designing the Architecture :: Chapter 7

31. How to identify the architectural drivers? Designing the Architecture :: Chapter 7 To priorize business goals {few} To put these business goals into quality scenarios or use cases  Scenary’s template To choose the most importants  Impact on the architecture

32. Attribute-Driven Design Designing the Architecture :: Chapter 7 Approach to define a software architecture that bases the decomposition process on the quality attributes the software has to fulfill Recursive decomposition process Use  Tatics  Architectural Patterns Systematic approach

33. Attribute-Driven Design (cont.) Designing the Architecture :: Chapter 7 To satisfy quality attributes and functional requirements RUP’s extension  High-level design  Detailed design and implementation ADD  Detailed {high-level} + Rational Input  Functional requirements  Constraints  Quality attributes scenarios

34. ADD Steps (p. 157) 1. Choose the module to decompose  Module: the system  Inputs: requirements, quality attributes, constraints  Quality attributes scenarios 2. Refine the module  Choose the architectural drivers from the set of concrete quality scenarios and functional requirements  Choose an architectural pattern that satisfies the architectural drivers  Instantiate modules and allocate functionality from the use cases  Define interfaces of the child modules  Verify and refine use cases and quality scenaries 3. Repeat the steps above for every module that needs further decomposition

35. ADD Steps Choose the module to decompose  System  Subsystem  Submodules Choose the architectural drivers  Combination of functional and quality requirements that “shape” the architecture or the particular module under considerations  It is not always a top-down process Prototype  Decomposition criterias Based on architectural drivers Requirements priorization System Subsystem

36. ADD Steps (cont.) Choose an Architectural Pattern  Goal: To establish an overall architectural pattern consisting of module types  Quality attributes -> Tatics -> Patterns Instantiate Modules and Allocate Functionality using Multiple Views  Instantiate module Use of responsability  Allocate functionality Based on Use cases  Represent the architecture with views (flexibility) Iterative process One view is normally sufficient  Module decomposition  Concurrency  Deployment  Others aspects can be used

37. ADD Steps (cont.) Define Interfaces of the Child Modules  Documentation aspects Verify and Refine Use cases and Quality Scenarios as Constraints for the Child Modules  Functional requirements Requirements + use cases -> module  Constraints The decomposition satisfies the constraint The constraint is satisfied by a single child module The constraint is satisfied by multiple child module

38. ADD Steps (cont.)  Quality scenarios A quality scenario may be completely satisfied by the decomposition without any additional impact A quality scenario may be satisfied by the current decomposition with constraints on child modules The decomposition may be neutral with respect to a quality scenario A quality scenario may not be satisfiable with the current decompostion  Result Child module  Responsability  Use cases  Interfaces  Quality scenario  Constraints

39. References L. Bass, P. C. Clements, R. Kazman. Software Architecture in Practice. Second Edition, Addison- Wesley, 2003.