1. Slide 1 Introduction to Software Architecture TV Prabhakar

2. Slide 2 Antecedents of Software Architecture

3. Slide 3 What is Software Architecture? 150+ definitions What are they? Both a process and a product

4. Slide 4

5. Slide 5

6. Slide 6

7. Slide 7

8. Slide 8

9. Slide 9

10. Slide 10 What type of requirements drive architectural design? Answer: Quality attribute requirements are the primary drivers for architecture design. Do you agree?

11. Slide 11

12. Slide 12

13. Slide 13 Architecture and Functionality Functionality is largely orthogonal to quality attribute requirements. Functionality is the ability of a system to do the work it was intended to do. Systems are decomposed into elements to achieve a variety of purposes other than function. –Architectural choices promote certain qualities as well as implement the desired functionality.

14. Slide 14 Effects of Architectural Decisions on Quality Attributes The degree to which a system meets it’s quality attribute requirements is dependent on architectural decisions. A change in structure improving one quality often affects the other qualities. Architecture is critical to the realization of quality attributes. These product qualities should be designed into the architecture. Architecture can only permit, not guarantee, any quality attribute.

15. Slide 15 Architecture-centric development? Architecture-centric development involves –Creating the business case for the system –Understanding the requirements –Creating or selecting the architecture –Documenting and communicating the architecture –Analyzing or evaluating the architecture –Implementing the system based on the architecture –Ensuring that the implementation conforms to the architecture –Maintaining the architecture The architecture must be both prescriptive and descriptive.

16. Slide 16

17. Slide 17

18. Slide 18

19. Slide 19

20. Slide 20

21. Slide 21

22. Slide 22 Attribute-Driven Design The Attribute-Driven Design (ADD) method, developed at the SEI, is an approach to defining a software architecture that bases the decomposition process on the quality attributes the software must fill. a recursive decomposition process where, at each stage in the decomposition, tactics and architectural patterns are chosen to satisfy a set of quality scenarios.

23. Slide 23

24. Slide 24 ADD Method's Inputs and Outputs Inputs –constraints –functional requirements –quality attribute requirements Outputs –first several levels of module decomposition –various other views of the system as appropriate –set of elements for functionality and the interactions among them

25. Slide 25 Architecture Documentation Architecture documentation is important if and only if communication of the architecture is important. –How can an architecture be used if it cannot be understood? –How can it be understood if it cannot be communicated? Documenting the architecture is the crowning step to creating it. Documentation speaks for the architect, today and 20 years from today.

26. Slide 26

27. Slide 27 Issues Addressed by an Architectural Design Gross decomposition of a system into interacting components –typically hierarchical –using rich abstractions for component interaction(or system “glue”) –often using common design idioms/styles Emergent system properties –performance, throughput, latencies –reliability, security, fault tolerance, evolvability Rationale and assignment of function to components –relates requirements and implementations Envelope of allowed change –“load-bearing walls”, limits of scalability and adaptation –design idioms and styles

28. Slide 28 Schools of Thought 4 + 1 View Zachmann Framework RM - ODP IEEE OMG TOGAF Product Lines

29. Slide 29 4 + 1 view Philips Kruchten, Rational Software, Architectural Blueprints - The 4+1 View Model of Software Archtecture, IEEE Software, 1995 –Use case view –Logical view –Process view –Implementation view –Deployment view

30. Slide 30 4+1 view

31. Slide 31 What do the views do? logical view is the object model of the design (when an object-oriented design method is used), process view captures the concurrency and synchronization aspects of the design, physical view which describes the mapping(s) of the software onto the hardware and reflects its distributed aspect, development view describes the static organization of the software in its development environment illustrated by a few selected use cases, or scenarios

32. Slide 32 Taxonomy of Styles Data Flow –Batch Sequential –Dataflow Network(pipes & filters) »acyclic, fanout, pipeline, Unix –Closed loop control Call-and-return –Main program/subroutines –Information hiding(ADT, Object naïve client/server)

33. Slide 33 Taxonomy.. Interacting Processes –LW processes, distributed objects –Event systems »implicit invocation, pure events Data-oriented repository –Transactional databases »True client/server »Blackboard »Modern compiler

34. Slide 34 Taxonomy.. Data-sharing –compound documents –Hypertext –Fortran COMMON –LW processes Hierarchical –Layered »Interpreter

35. Slide 35

36. Slide 36

37. Slide 37

38. Slide 38

39. Slide 39

40. Slide 40 Architectural Styles An architectural style consists of: –component/connector types, topology –constraints on the topology and behavior –an informal description of the costs and benefits of the style, e.g. “use the pipe and filter style when reuse is desired and performance is not a top priority”

41. Slide 41 Styles, Patterns and Idioms POSA, Buschmann etal GOF

42. Slide 42 References sei.cmu.edu IEEE OMG POSA GOF WWISA www.cetus-links.org Bredemeyer.com