Software Architecture Motivation, Qualities and Development Cycle

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

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. 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. goals architecture system

4. Definition of "Architecture" • Following Bass(Bass, 1998) a software architecture is the structure of the system which comprises its • components, • the externallyvisible properties of these components and • their relationships.

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. 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. 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. The Architecture Cycle 2/2 REGNET Architecture Cycle • Customers and end users • Developing organisation • Content Group, EU • Technical Group Requirements architecture • Technical environment system Architects ("us") Architect • Architect's experience

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. 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. 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 p1 of module m1 uses p2 in module m3 - does that imply that we need to change m3 just because we modify p1? • Layering: the uses structure thus affects the layering of the modules.

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. 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. 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. Qualities 2/4 • System qualities notdiscernible 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. 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. 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. 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. The Architecture Development Process • The technical architecting process • The organisational architecting process: leading, communicating, consulting, etc. Architectural requirements Structuring (Analysis, Design) Evaluation (Implementation, Testing) rework cycle n+1

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

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

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

28. Interpretation Engine Style 3: Virtual Machine Architectures • Goal is to achieve portability • Interpreters, e.g., Java, as examples • Performance costs due to additional computation Program Data Program Being Interpreted Input Data Updates State Data Program Instructions Selected Instruction Internal State Output Selected Data

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

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

31. User Interface Useful System Basic Utility Core Call-And-Return Architectures cont. • Layered systems: higher layer builds on functionality provided by the lower layer • Goals are modifiability and portability