1. Software Architecture Motivation, Qualities and Development Cycle June 2001 Siegfried Reich SunTREC Salzburg siegfried.reich@salzburgresearch.at

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

4. 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. 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 the technology implementation plan (TIP)

6. 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 understood completely, hence involvement of stakeholders at early stages and reviews are essential.

7. 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. 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. 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. 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. 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 p 1 of module m 1 uses p 2 in module m 3 - does that imply that we need to change m 3 just because we modify p 1 ? Layering: the uses structure thus affects the layering of the modules.

12. 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. 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. 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. 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. 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. 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. 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. 19 The Architecture Development Process The technical architecting process The organisational architecting process: leading, communicating, consulting, etc. Architectural requirements Structuring (Analysis, Design) Evaluation (Implementation, Testing) cycle n+1 rework

20. 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. 21 Workflows and Phases Use Case driven Architecture centric An iteration in the elaboration phase Phases of a system's cycle (Unified Process, UP) Core Workflows Requirements Analysis Design Implementation Test

22. 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. 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. 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. 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. 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 Client computational component passive data component

27. 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 Report Update Tape Page passive data component

28. 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 Interpretation Engine Program Being Interpreted Internal State Program Instructions Selected Instruction Selected Data UpdatesData Output Input State Data

29. 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 2Sub 3

30. 30 Call-And-Return Architectures cont. The object-oriented style: access to objects' internal states via interfaces only ( achieve modifiability via encapsulation). Object

31. 31 Call-And-Return Architectures cont. Layered systems: higher layer builds on functionality provided by the lower layer Goals are modifiability and portability User InterfaceUseful SystemBasic UtilityCore