Software Architecture Radu Marinescu Timioara January 2002 1

Software Architecture Radu Marinescu Timişoara, January 2002 1

Outline n Part I – Introduction to Software Architecture n n n Context Definition Role Expected Benefits Part II – Pattern-Oriented Software Architecture n n System of Patterns Common Architectural Patterns (Styles) 2

Routine vs. Innovative Design n Routine Design n n solving familiar problems by reusing large portions of prior solutions capitalize on codified principles and experience Innovative Design n novel solutions to unfamiliar problems n Engineering = make routine design simpler! n Software design is far too innovative! n lack of capturing and organizing what is already known 3

The Problem n User Needs vs. Software Engineering Artifacts n n The gap between these two Shortage of intermediate abstractions Design Results vs. Design Reasons n What vs. Why n Existing notations address mostly the design results System Structure vs. Algorithms & Data Structures n n preeminence of structural issues in large-scale systems size and complexity increase 4

Structural Issues n Composition of components n Assignment of functionality to design elements n Protocols for communication, synchronization, data access n Scaling and performance n Dimensions of evolution 5

Typical Descriptions of Software Architectures n n Descriptions of the system often include a section on “The architecture of this system” Usually informal prose plus box-and-line diagrams Lots of appeal to intuition Little precision, rarely formal 6

Typical Descriptions of Software Architectures n “Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers” n n “We have chose a distributed, object-oriented approach to managing information. ” “The easiest way to make the canonical sequential compiler into a concurrent compiler is to pipeline the execution of the compiler phases over a number of processors” 7

The Paradox of Architectural Descriptions n The Paradox n n Descriptions of software architectures are informal … … yet they communicate effectively. 8

The Paradox Explained n Rich Vocabulary n evolving collection of idioms, patterns and styles of software n conveys a considerable semantic content system organisation n Framework for Understanding System-Level Concerns n skeleton around which the system properties can be fleshed out n expose the ability of the system to meet the system requirements 9

Definition of Software Architecture "Software Architecture involves the description of n elements from which systems are built, n interactions among those elements, n patterns that guide their composition and n constraints on these patterns“ Shaw, Garlan – “Software Architecture”, 1996 10

Definition of Software Architecture (2) “The software architecture of a program or computing system is the structure (or structures) of the system, which comprise n software components, n the externally visible properties of those components and n the relationships among them" Bass, Clements, Kazman – “Software Architecture in Practice”, 1998 11

Definition of Software Architecture (3) “ The initial design process of n identifying the subsystems and establishing a framework for subsystem control and communication is called architectural design n … and the output of this design process is a description of the software architecture. " Sommerville – “Software Engineering”, 2001 12

Software Architecture … is a high-level design that captures: n Components (allocation of functionality) n n Connections (communications) n n filters, objects, clients, servers, ADTs Procedure calls, pipes, event broadcast Constraints (the “-ilities”) n n non-functional system requirements Pre/post conditions 13

Architectural Impact of Non-Functional Requirements n Performance n n n Security n n Small number of subsystems large-grained components Reduce communication Layered structure Most critical layer in the inside High-level of security validation Maintainability n n n Easy to change Fine-grained, self-contained compon. Producers of data separated from consumers Avoid shared data structures 14

Role of Software Architecture 15

Architectures vs. Programs Different issues for architecture and programs: Architectures n n n Interaction among parts Structural properties Declarative Mostly static System-level performance Composition of subsystems Programs n n n Implementation of parts Computational properties Operational Mostly dynamic Algorithmic performance Copy code or call libraries 16

Expected Benefits of Software Architecture 1. Conceptual Integrity n n Appear as if from one mind Exhibit symmetry, consistency, predictability 2. Functional Completeness n n Meet customer’s functional requirements Base for later correctness checking 3. Operational Optimality n n Meet customer’s performance and sizing requirem. Fit into its environment n external interfaces and users 17

Expected Benefits of Software Architecture 4. Modularity n n n Self-contained, replaceable elements Facilitating change during and after development Facilitating parallel development 5. Robustness n n Failing in a way that permits ready recover Dealing intelligently with erroneous inputs 18

Expected Benefits of Software Architecture 6. Economy n n n Take advantage of previous systems’ design and code Maximize commonality in the system Support future systems’ design and code 7. Understandability n Basis for agreements with customers and users Permit unambiguous interpretation by designers and n Conforming to standards n developers 19

Part II Pattern-Oriented Software Architecture 20

Properties of Patterns Address a recurring problem that arises in a specific context, and presents a solution to it n n Common vocabulary and understanding for design principles Document “distilled” design experience n n Identify and specify higher-level abstractions n n Provide a mean of reuse Help to build more complex and heterogeneous systems Support the construction of software with defined properties n By explicitly addressing non-functional requirements 21

Categories of Patterns n Architectural Pattern (Style) n n n Design Pattern n a fundamental structural organization schema predefined set of components-connections-constraints a scheme for refining subsystems or components or the relationships between them commonly-recurring structure of communicating components that solves a general design problem within a particular context Idiom n n low-level pattern specific to a programming language efficient implementation of particular aspect of components 22

System of Patterns Architectural Styles Refer to / Apply Design Patterns Implement using Programming Idioms & Styles fundamental structure High-Level Design communication mechanisms local design aspects Detailed Design efficient implem. Implementation 23

Architectural Design Activities n System Structuring n n n Control Modeling n n identify principal subsystems identify communications between subsystems establish the model of control between system parts Modular Decomposition n decompose subsystems into modules 24

Common Architectural Styles n System Structuring n n Control Modelling n n n Repositories (Blackboard) Layered Architecture Client-Server Call-and-Return Event-driven Systems Modular Decomposition n n Object-Oriented Data-Flow (Pipes-and-Filters) 25

Repositories – CASE Toolset Design Editor Program Editor Code Generator Project Repository Design Analyzer Report Generator 26

Repositories – Blackboard § Knowledge Sources (ks) § knowledge partitioned in independ. computations § respond to changes in blackboard § Blackboard § entire state of problem solution § means of interaction among “ks” to find the solution § Control § in model “ks” self-activated by changes in the blackboard 27

Repositories – Summary ü Efficient way to share large amounts of data ü Data producers and consumers are totally independent ü Subsystems don’t have to care about auxiliary responsibilities § e. g. backup, security, recovery from error Ò The common data-model is a compromise among subsystems impact on performance Ò Translations to a new model is very expensive Ò Repository forces a centralized policy on all subsystems Ò Repositories are hard to distribute physically 28

Layered Architecture 29

Layered Architecture – Summary 1. Changeable and portable architecture 2. Suitable for incremental development 1. Provide services as soon as a layer is implemented 3. Support reuse 4. Hard to achieve such a rigorous structuring 1. Hard to find the proper levels of abstraction 5. Reduces performance by increased communication 30

Client-Server – Example Client 1 Client 2 Client 3 Client 4 Wide-bandwidth network Video Server Picture Server Hypertext Server 31

Client-Server – Summary ü Architecture is distributed ü Easy to add and integrate new servers ü System can be reconfigured dynamically ü Servers are not aware of clients ü Neither identity nor number ü Each server can organize its own data-model ü better then the centralized data-model in Repository Ò Performance problems if large amounts of data are exchanged Ò Hard to find the proper levels of abstraction Ò Hard to anticipate problems with integrating data from a new server 32

Call-and-Return § Hierarchical decomposition § Single thread of control § Subroutines aggregated in modules § Hierarchical reasoning § correctness of a subroutine depends on the correctness of the called subroutines üControl flow is relatively simple to analyze ÒExceptions to normal operation awkward to handle 33

Event-Driven System § Components interface §set of incoming procedure calls (? ) §set of outgoing events (!) § Connections: § event-procedure bindings § components communicate by announcing events at “appropriate” times § when an event is announced the associated procedures are (implicitly) invoked § order of invocation is nondeterministic § Used for interactive systems 34

Event-Driven System – Summary ü Strong support for reuse § Just have to register component to the events of the system ü Implicit invocation eases system evolution ü Components may be replaced by other components without affecting the interfaces of other components in the system Ò Components release control over the system’s computations Ò Don’t know who and in which order other comp. will respond to it Ò Hard to reason about correctness Ò Meaning of a procedure that announces events depends on the context of its bindings 35

Object-Oriented Systems §Object as managers § preserve integrity of resources, i. e. data representation §Encapsulation §Hides representation from other objects §Inheritance § set an hierarchy among related abstractions § Dynamic binding § determine actual operation to call at runtime 36

OO Sytems – Summary ü Change implementation without affecting clients ü Decompose problems in collections of collaborating agents ü Objects are representations of real-world entities ü Structure of the system is easy to understand Ò Dependence on the identity and interface of the other objects Ò interface changes affects all the clients of a given service Ò Control-flow is hard to analyze Ò Sequence diagrams are very useful 37

Pipes and Filters §Filter § incrementally transform some flow of data at inputs to data at outputs § share no state with other filters § don’t depend on the upstream and downstream filters §Pipe § Move data from a filter output to a filter input § form graphs of data transmission 38

Pipes and Filters – Summary 1. Understand behavior as a composition of the behavior of individual filters 2. Support for filter reuse 3. Systems are easy to maintain and enhance 1. By changing or adding new filters 4. Support concurrent execution 5. Not good for interactive applications 6. Filters need a common format for data transfer 7. Each filter must parse and unparse the data stream overhead 39

Part III The Model-View-Controller An In-Depth Analysis 40

Interactive Systems n n the challenge is to separate the functional core from the user interface Functional Core is stable n n based on the functional requirements User Interface is permanently subject to adaption and change 41

Summary n Model n n View n n contains core functionality and data display information to the user Controller n handle user input n User Interface (UI) = View (V) + Controller (C) n Change propagation mechanism n ensure consistency between Model (M) and User Interface (UI) 42

Problem n UI very prone to change requests: n n n Portability Adaption Different look-and-feels for same functionality UI of long-lived systems moving target Functionality core tightly coupled to the UI, makes the flexibility of the UI n n expensive and error-prone 43

Forces … that “shape” the solution: 1. Same information, different presentations n e. g. different charts 2. Data manipulation reflected instantly in display and application behavior 3. Easy UI changes n 4. even possible at run-time (e. g. look-and-feel) “Look-and-feel" standards should not affect code of the core functionality 44

Solution Divide application in three parts: n Model (Processing) n n View (Output) n n encapsulate data and functionality (core) independent of output representation and/or input behavior notifies all the views when the data has changed display info to the user, getting data from the model permit multiple views of the same data set creates and initializes its associated controller Controller (Input) n n n associated with a particular view receive input as events translate events to service requests for the model or view 45

Structure 46

Change Propagation Mechanism 47

Initialization 48

Implementation Details 1. Design the Model component n 2. Implement the change propagation mechanism n 3. Separate user interaction from core functionality Based on the Observer pattern Design and implement the Views n n n Common base class “View” Redefine initialize() and draw() in subclasses Draw() called on update() n n n Fetch data from the Model Optimize frequent fetches: view controls redraw or perform not when further events also require it. Initialize() n n Subscribe to the change-propagation mechanism Set up relation to the Controller make. Controller() 49

Implementation Details (2) 4. Design and implement the Controllers n User input comes as events handle. Event(Event) n if no event processing handle. Event is a NOP method n Tight coupling between the Model and the Controller n Decouple using the Command design pattern n Model command supplier n Controller command Invoker 5. Design the View-Controller Relation n apply the Factory Method design pattern 50

Implementation Details (3) 51

Variants – Document-View n n Relaxes separation between view and controller Combine responsibilities of view and controller Document = Model View = Controller + View n n the whole user-interface Used in MFC 52

Benefits ü Multiple views of the same model ü views are synchronized ü “Pluggable” views and controllers ü Exchangeability of “look-and-feel” ü Framework potential 53

Liabilities Ò Potential for excessive number Ò Not all views need updates Ò Inefficiency of data access Ò Request of unchanged data ü caching of data of updates in view Ò Close coupling of V & C to the model Ò Model changes break V & C code ü Use the Command pattern for decoupling Ò Increased complexity 54