Software Architecture

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 Picture Section Class Layout

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 • Elicit architectural requirements • Design the architecture • Document the architecture • Analyze the architecture • Realize the architecture • 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