1. Software Architecture

2. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting? " What's involved in creating architectural documents?

3. Why Architect? " to build a better dog house " to handle large, complex tasks " to coordinate work " to communicate ideas and design " to validate against goals " to resolve conflicting goals " to reduce costs " to improve delivery times " products or product lines

4. Architecture: Definitions " "the art or science of building" " "formation or construction as or as if as the result of conscious act" " "a unifying or coherent form or structure" " "a method or style of building" " "the manner in which the components of a computer or computer system are organized and integrated" Merriam-Webster's Collegiate Dictionary, Tenth Edition

5. Develop: Definitions " "to set forth or make clear by degrees or in detail" " "to work out the possibilities of" " "to make available or usable" " "to cause to unfold gradually" " "to expand by a process of growth" " "to come into being gradually" Merriam-Webster's Collegiate Dictionary, Tenth Edition

6. What is Architecture? " Form – structure, organization " Function – behavior, use " Style – appearance, elegance, way of doing things (tao)

7. Examples of Architecture Score Layout SectionPicture Class

8. Influences on Architecture " Environment/Context – Relationship to surroundings, orientation, and climate " History – Changes in technology, materials, and ideals of beauty over time " Technology – Current know-how

9. Uses of Architecture " Means of communicating design information amongst stakeholders " Embodiment of early design decisions " Reusable entity

10. What Does an Architect Do? " leads – champions, coordinates, interfaces, aligns with business strategies " provides vision " translates " designs " criticizes " consults

11. Guiding Principles " integrity " simplicity " loose coupling/separation of concerns " high cohesion " abstraction " postponement of decisions

12. Creating Architectural Documents " Source " "Architecture-Based Development", Len Bass & Rick Kazman, Carnegie Mellon University, 1999 " Iterative process, involving both construction and validation " Six-step process

13. Architectural Document Creation Process Summary 1 Elicit architectural requirements 2 Design the architecture 3 Document the architecture 4 Analyze the architecture 5 Realize the architecture 6 Maintain the architecture

14. Elicit Architectural Requirements " functional requirements " non-functional requirements or qualities – such as: " modifiability " performance " security " reliability – includes priorities, relative importance, etc.

15. Design the Architecture " make design decisions based on: " knowledge of architectural styles " design patterns " use of of particular tools " reason about decisions by " considering architectural structures * and views " validate the design by " determining if scenarios are achievable

16. Architectural Structures components, connectors, and properties Based on: Architectural Blueprints -- The “4+1” View Model of Software Architecture, P. Kruchten, IEEE Software V12N6, 1995 view: perspective; part of or combination of parts of structures – functional structure/logical view – concurrency structure/process view – physical structure/physical view – code structure/development view – developmental structure (not in Kruchten) – Kruchten includes “scenarios”

17. Functional Structure " decomposition of functionality – system’s services to clients – identification of common mechanisms and design elements " identification of connections " represented in UML by class diagrams

18. Concurrency Structure " processes, threads, distribution, messages " some non-functional requirements handled – performance, availability, security, reliability " how functionality maps to processes/threads – major tasks use inter-process communication (IPC) " no assumptions about collocation – minor tasks may use shared memory " can be used to estimate message flows and loads

19. Physical Structure " mapping software to hardware " primarily non-functional requirements – e.g., availability, reliability (fault tolerance), performance (throughput), scalability " several different configurations possible

20. Code Structure " key code abstractions (e.g., packages, classes) " addresses: " software reuse, portability " software management (work allocation, monitoring, etc.) " software development issues " software module organization " often, layered subsystem

21. Scenarios " walk-through scripts " sequences of interactions among objects and among processes " instances of use cases (what a system does from the standpoint of an external observer) " intentionally redundant with other views: " to help discover architectural elements " to validate and illustrate architecture

22. Document the Architecture " Key characteristics: – complete and navigable – includes infrastructure – enough use cases to help understand how system will implement functionality – includes constraints on communications, resource management, time management, etc. – publicly available to everyone concerned

23. Analyze the Architecture " Review by concerned parties " Intent is to: – detect problems early – improve the architecture

24. Realize the Architecture " Turn the architecture into code

25. Maintain the Architecture " Keep the architecture on track over time