Software Architecture Alan Kelon Oliveira de Moraes Feb 12, 2006 – Recife

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

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]

History: ● 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!

History: ● 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]

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 tml for 60 more definitions...

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.

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.

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

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

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

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

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.

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

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.

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.

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

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

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

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.

● Software architecture as a bridge [Garlan, 2000]

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

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

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

Architectual Design Activities

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

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

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

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

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

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

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

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

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

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

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

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

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