Software Architecture Alan Kelon Oliveira de Moraes akomcin

Software Architecture Alan Kelon Oliveira de Moraes akom@cin. ufpe. br 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: 1990 -1998 ● Software Architecture as distinct discipline ● The 1990 s 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: 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]

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. . .

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 Ri. SE’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 Deliver Final Preliminary Version Requirements Analysis Design of Architecture and System Core Develop a Version Deliver the Incorporate Customer Elicit Feedback Customer Feedback Version

Designing the Architecture : : Chapter 7 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? 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

Designing the Architecture : : Chapter 7 Attribute-Driven Design 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

Designing the Architecture : : Chapter 7 Attribute-Driven Design (cont. ) 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. 2. Choose the module to decompose Module: the system Inputs: requirements, quality attributes, constraints Quality attributes scenarios Refine the module Choose the architectural drivers from the set of concrete quality scenarios and functional requirements 3. 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 Repeat the steps above for every module that needs further decomposition

ADD Steps Choose the module to decompose System Subsystem Submodules Subsystem 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

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 Allocate functionality Use of responsability 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.