1. Why Architecture? The architecture is not the operational software. Rather, it is a representation that enables a software engineer to: (1) analyze the effectiveness of the design in meeting its stated requirements, (2) consider architectural alternatives at a stage when making design changes is still relatively easy, and (3) reduce the risks associated with the construction of the software.

2. 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”.

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

4. Architecture definition Perry, Wolf: Elements Elements processing elements (data transformer) processing elements (data transformer) data elements (data) data elements (data) connecting elements (glue that holds pieces together) connecting elements (glue that holds pieces together) Form Form weighted properties and relationships weighted properties and relationships constraints for choice of elements and placement constraints for choice of elements and placement Rationale Rationale motivation for choices

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

6. 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)

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

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

9. Shaw and Garlan[‘96] define architecture in terms of design elements and the constraints on the elements, but differ from Perry and Wolf in that the 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

10. Shaw & Garlan Taxonomy

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

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

13. 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. Common Architectural Styles

14. 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 Common Architectural Styles

15. Control Equations Inputs Outputs Control Feedback (monitor pressure & temperature) (set control valves and pumping rates) Process control architecture

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

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

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

19. 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]

20. Logical View

21. Process View

22. Development View

23. Physical View

24. Some architecture description languages C2ADL (UCI, http://www.isr.uci.edu/architecture/ )http://www.isr.uci.edu/architecture/ xArch (UCI) xADL (UCI) ACME (CMU, http://www-2.cs.cmu.edu/~acme/ )http://www-2.cs.cmu.edu/~acme/ Wright (CMU) adapting UML adapting other formal languages (e.g. Z)

25. 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 set of components (e.g., a database, computational modules) that perform a function required by a system, (2) a set of connectors that enable “communication, coordination and cooperation” among components, (3) constraints that define how components can be integrated to form the system, and (4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

26. Data-Centered Architecture

27. Data Flow Architecture

28. Call and Return Architecture

29. Layered Architecture

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

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