Software Architecture Agenda Why architect What is architecture

Software Architecture

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?

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

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" 1. Merriam-Webster's Collegiate Dictionary, Tenth

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" 1. Merriam-Webster's Collegiate Dictionary, Tenth Edition

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

Examples of Architecture Picture Section Class Layout Score

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Document the Architecture " Key characteristics: complete includes and navigable 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

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

1. Realize " the Architecture Turn the architecture into code

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