Why Architecture?

The architecture is not the operational software. The architecture is not the operational software. Rather, it is a representation that enables a Rather, it is a representation that enables a software engineer to: software engineer to:

(1) analyze the effectiveness of the design in (1) analyze the effectiveness of the design in meeting its stated requirements, meeting its stated requirements,

(2) consider architectural alternatives at a stage (2) consider architectural alternatives at a stage when making design changes is still relatively easy, when making design changes is still relatively easy, and and

(3) reduce the risks associated with the (3) reduce the risks associated with the construction of the software.construction of the software.

Why is Architecture Important?• Representations of software architecture are an enabler for

communication between all parties (stakeholders) interested in the development of a computer-based system.

• The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.

• Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”.

Why is Architecture Important?• It is important to start reasoning about the system as

early as possible• The architectural specification helps us see a match

between the requirements a certain set of constraints before identifying concrete solutions

Architecture definition

Perry, Wolf:Perry, Wolf:

• ElementsElements

• processing elements (data transformer)processing elements (data transformer)

• data elements (data)data elements (data)

• connecting elements (glue that holds pieces connecting elements (glue that holds pieces together)together)

• FormForm

• weighted properties and relationshipsweighted properties and relationships

• constraints for choice of elements and constraints for choice of elements and placementplacement

• RationaleRationale

• motivation for choices

Architecture vs design

Architecture – concerned with the selection of architectural elements, their interactions, and the constraints on those elements and interactions to provide a framework in which to satisfy the requirements and serve as basis for the design

Design - concerned with the modularization and detailed interfaces and procedures, and the data types needed to support the architecture and to satisfy the requirements

Uses for Architectural specification

• Prescribe the architectural constraints to the desired level (specify the constraints and their generalization level instead of specific solutions)

• Separate aesthetics from engineering (load-bearing vs decoration)

• Express different aspects of the architecture in an appropriate manner

• Perform dependency and consistency analysis (requirements, architecture, design must be consistent, their interdependencies specified)

Architectural style

• Architecture can be thought of as a formal arrangement of architectural elements; a specific architecture

• Style – less constrained, less complete; a template architecture

Architectural erosion and drift

• Evolution and customization – major contributors to software cost

• Due to problems with architecture:

• erosion – violations of architectural constraints, leads to disasters

• drift – lack of coherence and clarity of form, leads to inadaptability

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.

Taxonomy of styles

Shaw & Garlan Taxonomy

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

Common Architectural 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

Common Architectural Styles

Distributed Processes and Client/ServersProcesses 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.

Common Architectural Styles

Model, View, ControllerTypical 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

Common Architectural Styles

ControlEquations

Inputs Outputs

ControlFeedback

(monitorpressure &temperature)

(set controlvalves andpumping rates)

Process control architecture

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

Combining styles

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.

Reference Architectures

• 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.

4+1 View of Architecture

The 4 Views

The logical view describes 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 view describes the design's concurrency and synchronization aspects. [Use UML Collaboration Diagram/ Sequence Diagram]

The development view describes the software's static organization in its development environment. [Use UML Component Diagram]

The physical view describes the mapping of the software onto the hardware and reflects its distributed aspect. [No UML Counterpart]

Logical View

Process View

Development View

Physical View

Some architecture description languages

• C2ADL (UCI, http://www.isr.uci.edu/architecture/ )

• xArch (UCI)

• xADL (UCI)

• ACME (CMU, http://www-2.cs.cmu.edu/~acme/ )

• Wright (CMU)

• adapting UML

• adapting other formal languages (e.g. Z)

Architectural Styles

• Data-centered architectures• Data flow architectures• Call and return architectures• Object-oriented architectures• Layered architectures

Each style describes a system category that encompasses: (1) a Each style describes a system category that encompasses: (1) a set of components (e.g., a database, computational modules) set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the semantic models that enable a designer to understand the overall properties of a system by analyzing the known overall properties of a system by analyzing the known properties of its constituent parts. properties of its constituent parts.

Data-Centered Architecture

Data Flow Architecture

Call and Return Architecture

Layered Architecture

Architectural Patterns

• Concurrency—applications must handle multiple tasks in a manner that simulates parallelism

• operating system process management pattern• task scheduler pattern

• Persistence—Data persists if it survives past the execution of the process that created it. Two patterns are common:

• a database management system pattern that applies the storage and retrieval capability of a DBMS to the application architecture

• an application level persistence pattern that builds persistence features into the application architecture

• Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment

• A broker acts as a ‘middle-man’ between the client component and a server component.

Place of architecture

• It is important to start reasoning about the system as early as possible

• The architectural specification helps us see a match between the requirements a certain set of constraints before identifying concrete solutions