Software Architecture

Software Architecture • Software Architecture - both a discipline of design, and a representation of design. Some key points from Perry and Wolf [PW92] are: • architecture is a discipline with standards, codified styles and education • architecture captures important high-level concepts in a system which must be preserved, and which make global assertions about the system • multiple views are needed to express an architecture • strong analogies are made between the notions of "style" in software and classical architecture Software Architecture

The Effects of Size Can be built by one person Requires - Minimal modeling - Simple process - Simple tools Built most efficiently and timely by a team Requires - Modeling - Well-defined process - Power tools Can only be built by many teams (i.e.companies) Requires - Extensive modeling - Complex “need to define” process - Multitude of tools Software Architecture

Software Architecture as a Maturing Discipline A key attribute of a mature engineering discipline is the routine use of existing solutions in the development of new systems. Designs are institutionalized by inclusion in handbooks, technical publications, and corporate standards. Corporate design standards usually limit usage, due to their proprietary nature and the scope of their intended application. These methods of dissemination lead to high levels of design reuse. Software Architecture

Classical Building Architecture Analogy • Points of commonality: • notations and representations (building: blueprints, physical models, perspective drawings; software: structural graphics, coupled with behavioral and informational views) • architectural styles (building: Romanesque, Gothic, Victorian; software: distributed, layered, client/server) • constraints (building: acoustics, air/water flow, lighting; software: throughput, timing, fault tolerance, ease of use) • standards/practices (building: building codes & inspections; software: interface standards & walk-throughs/reviews) Software Architecture

What is Software Architecture? • Software architecture encompasses the set of significant decisions about the organization of a software system • selection of the structural elements and their interfaces by which a system is composed • behavior as specified in collaborations among those elements • composition of these structural and behavioral elements into larger subsystem • architectural style that guides this organization Software Architecture

Chemical (Unit Process) Architecture Analogy Points of commonality • components (chemical: unit operations [e.g., heat exchanger]; software: architectural components [e.g., DBMS]) • connectors (chemical: pipes, conveyors; software: procedure calls, pipes) • architectural styles (chemical: operation [e.g., batch, continuous]; software: topological styles [e.g., pipe & filter, blackboard]) • constraints (chemical: precedence of elements in a process; software: precedence of elements in an execution sequence) • notation (chemical: process flowcharts; software: ADLs) • product (chemical: chemical plant; software: application system) Software Architecture

Fundamentals Architecture should establish a common vision of the project/product development. Acts as glue: Architecture Conceptual models of the application domain Relatively formal models that are the basis for implementation Software Architecture

Architectural Specification Goals • prescribe the architectural constraints - using the principle of least constraint. • separate esthetics from engineering - identify the decoration from the load bearing elements • provide multiple views of the structure - both context and components • determine dependencies among elements & check consistency • Want to avoid: • architectural erosions - violations of the architecture • architectural drift - insensitivity to the architecture • brittleness Software Architecture

Where it Fits . . . Software Architecture

S/W Architecture Terminology • Software Architecture is (a sampling of definitions)... • components + connectors; a family of architectures + constraints defines an architectural style or idiom (Garlan & Shaw [GS93]) • elements + form + rationale, where an element is composed of components and connectors (Perry & Wolf [PW92]) • fundamental structural attributes of a software system (Saunders et al [SHM]) • components + idioms/styles + common patterns of interaction between functional components; architecture identifies common design information that addresses the requirements of a family of similar products (Vestal [Ves93]) • elements + interfaces + connections + connection semantics (CFRP 3.2.1.2 [STARS93]) Software Architecture

Taxonomy of Styles • Shaw and Garlan[‘96] define architecture in terms of design elements and the constraints on the elements, but differ from Perry and Wolf in thatthe elements are: • components and connectors, described in some idiom specific manner. Idioms are represented as topologies of the component/connector vocabulary, along with constraints on how the topologies can be arranged. Shaw and Garlan have developed a taxonomy based on case studies of actual systems. The eventual goal is to develop a handbook for the selection and application of appropriate styles. Software Architecture

Architecture = Elements + Form + Rationale • Elements are: • components (data) • connections (bindings between components) • control and processing (threads of execution) • Connections are as important as components as they determine how the • pieces fit together, if at all. For example, can a procedure call a pipe, or a • pipe access a file, or call-backs occur between processes? • Form is: • properties - desired constraints on elements • relationships - placement of architectural elements • These are weighted to indicate importance (load bearing vs. decoration). • Rationale is the motivation for the choices made in defining the • architecture (especially as to how it satisfies the system requirements). Software Architecture

Shaw & Garlan Taxonomy Software Architecture

Common Architecture Styles • Data Flow style: • Batch Sequential - each step runs to completion; old style data processing architecture • Pipes and Filters - linked stream transformers Each filter is a stand-alone process that incrementally transforms its input streams into output streams. • Call and Return style: • Main program and subroutines - traditional functional decomposition, a controlling main program determines flow of control • Hierarchical layers - well defined interfaces and information hiding (e.g., kernels, shells) • Object-oriented systems - abstract data types with inheritance; objects only interact through defined interfaces Software Architecture

Common Architecture Styles • Independent Components style: • Communicating processes - asynchronous message passing • Event systems - implicit invocation; rather than invoking a procedure directly, a component generates a request for service event that is broadcast • Virtual Machines style: • Interpreters - input driven state machine • Rule-based systems - rule based interpreter • Data-centered systems: • Transactional Database Systems - central data repository/query driven • Blackboards - central shared representation/opportunistic execution Software Architecture

Common Architecture Styles • Distributed Processes and Client/Servers • Processes connected by a specific communication topology • (ring, star, etc.) along with protocols for communication. • Servers don't know their clients beforehand, while clients can • dynamically chose among servers. Client-server interactions can be • direct - where the client activates the server directly (for example by calling the server as a procedure) • polled - where the client indicates that it would like a service and the server periodically checks to see if any client requests are pending. • interrupt driven - where the server is dormant, and the client generates an event that eventually activates the server. Software Architecture

Common Architecture Styles • Model, View, Controller • Typical paradigm of user interface design. The underlying element is • modeled by some object. Various representations of this object are • presented through views. Alterations of the state of the object are achieved through controllers. • State Transition Systems • Standard design of many reactive systems. • Process Control Systems • Dynamic control via feedback loops. • Heterogeneous Software Architecture

Process Control Systems Architecture Control Equations Inputs Outputs (monitor pressure & temperature) (set control valves and pumping rates) Control Feedback Software Architecture

Combining Styles Systems are not usually developed according to a single, consistent idiom. Variations may occur at different levels of refinement/abstraction. Software Architecture

Reference Architectures Architectural idioms need not be constrained to usage within system development. They can also serve as tools for the analysis of system design. For example, a natural language processing system viewed through the interpreter and blackboard idioms. Software Architecture

4+1 View Model of Architecture • Organizes a description of software architecture using five concurrent views. • Architects capture their design decisions in four views and use the fifth to illustrate and validate the other four. Software Architecture

The 4 Views • The logical viewdescribes the design's object model when an object-oriented design method is used. To design an application that is very data-driven, you can use an alternative approach to develop some other form of logical view, such as an entity-relationship diagram. [Use UML Class Diagram] • The process viewdescribes the design's concurrency and synchronization aspects. [Use UML Collaboration Diagram/ Sequence Diagram] • The development viewdescribes the software's static organization in its development environment. [Use UML Component Diagram] • The physical viewdescribes the mapping of the software onto the hardware and reflects its distributed aspect. [No UML Counterpart] Software Architecture

Logical View Software Architecture

Process View Software Architecture

Development View Software Architecture

Physical View Software Architecture

Scenarios - Dimension 5 Software Architecture

Mappings Between Views Mapping from the logical to the process view Software Architecture

Software Architecture