Architectural Design l l Establishing the overall structure

Architectural Design l l Establishing the overall structure of a software system Objectives • • • To introduce architectural design and to discuss its importance To explain why multiple models are required to document a software architecture To describe types of architectural model that may be used ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 1

What is Architecture? l A high-level model of a thing • • l l l Describes critical aspects of the thing Understandable to many stakeholders Allows evaluation of the thing’s properties before it is built Provides well understood tools and techniques for constructing the thing from its blueprint Which aspects of a software system are architecturally relevant? How should they be represented most effectively to enable stakeholders to understand, reason, and communicate about a system before it is built? What tools and techniques are useful for implementing an architecture in a manner that preserves its properties? ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 2

What is Software Architecture? l A software system’s blueprint • Its components • Their interactions • Their interconnections l Informal descriptions • Boxes and lines • Informal prose l A shared, semantically rich vocabulary • • • Remote procedure calls (RPCs) Client-Server Pipe and Filer Layered Distributed Object-Oriented ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 3

From Requirements to Architecture l From problem definition to requirements specification • Determine exactly what the customer and user want • Specifies what the software product is to do l From requirements specification to architecture • Decompose software into modules with interfaces • Specify high-level behavior, interactions, and non-functional properties • Consider key tradeoffs » » Schedule vs. Budget Cost vs. Robustness Fault Tolerance vs. Size Security vs. Speed • Maintain a record of design decisions and traceability • Specifies how the software product is to do its tasks ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 4

Another View: The Twin Peaks Model ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 5

Focus of Software Architectures l Two primary foci • System Structure, Behavior, Interactions, Topology, Data, and key Properties • Correspondence between requirements and implementation ©Medvidovic, Van Vliet, Mejia-Alvarez A framework for understanding system-level concerns l • • • Global rates of flow Communication patterns Execution Control Structure Scalability Paths of System Evolution Capacity Throughput Consistency Component Compatibility Slide 6

Why Software Architecture? l A key to reducing development costs • Component-based development philosophy • Explicit system structure l A natural evolution of design abstractions • Structure and interaction details overshadow the choice of algorithms and data structures in large/complex systems l Benefits of explicit architectures • • • A framework for satisfying requirements Technical basis for design Managerial basis for cost estimation & process management Effective basis for reuse Basis for consistency, dependency, and tradeoff analysis Avoidance of architectural erosion ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 7

What is the Problem? This is a simple software system! ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 8

The Usual Tool: Design Abstraction We have to do better! ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 9

Architectural Abstraction ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 10

What is Software Architecture? l Definition: • l l A software system’s architecture is the set of principal design decisions about the system Software architecture is the blueprint for a software system’s construction and evolution Design decisions encompass every facet of the system under development • • Structure Behavior Interaction Non-functional properties ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 11

Other Definitions of Software Architecture l Perry and Wolf • l Software Architecture = { Elements, Form, Rationale } what how why Shaw and Garlan • Software architecture [is a level of design that] involves » » l the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten • • Software architecture deals with the design and implementation of the highlevel structure of software. Architecture deals with abstraction, decomposition, style, and aesthetics. ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 12

Architectural design process l System structuring • • l Control modelling • l The system is decomposed into several principal sub-systems Communications between these sub-systems are identified A model of the control relationships between the different parts of the system is established Modular decomposition • The identified sub-systems are decomposed into modules ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 13

Key Architectural Concepts l Three canonical building blocks • • • l l components connectors configurations A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems A module is a system component that provides services to other components but would not normally be considered as a separate system ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 14

Components l l A component is a unit of computation or a data store Components are loci of computation and state • • • l clients servers databases filters layers ADTs A component may be simple or composite • • composite components describe a (sub)system an architecture consisting of composite components describes a system of systems ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 15

Components l l l Elements that encapsulate processing and data in a system’s architecture are referred to as software components Definition • A software component is an architectural entity that » encapsulates a subset of the system’s functionality and/or data » restricts access to that subset via an explicitly defined interface » has explicitly defined dependencies on its required execution context Components typically provide application-specific services ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 16

Software components l l l In most engineering disciplines, systems are designed by composing existing components that have been used in other systems Software engineering has been more focused on original development It is now recognized that to achieve • • • better software more quickly at lower cost we need to adopt a design process that is based on systematic reuse ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 17

Components l Components provide a service without regard to where the component is executing or its programming language • • l A component is an independent executable entity that can be made up of one or more executable objects The component interface is published and all interactions are through the published interface Components can range in size from simple functions to entire application systems ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 18

A software component: l l Implements some functionality Has explicit dependencies through provided and required interfaces Communicates through its interfaces only Has structure and behavior that conforms to a component model ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 19

LEGO analogy l l l Set of building blocks in different shapes and colors Can be combined in different ways Composition through small stubs in one and corresponding holes in another building block LEGO blocks are generic and easily composable LEGO can be combined with LEGO, not with e. g. MEGA Bloks ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 20

Component abstractions l Functional abstraction • l Casual groupings • l The component represents a data abstraction or class in an OO language Cluster abstractions • l The component is a collection of loosely related entities that might be data declarations, functions, etc. Data abstractions • l The component implements a single function such as a mathematical function The component is a group of related classes that work together System abstraction • The component is an entire self-contained system ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 21

Why CBSE? l CBSE increases quality, especially evolvability and maintainability l CBSE increases productivity l CBSE shortens development time ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 22

Hiding of component internals l l Black box: only specification is known Glass box: internals may be inspected, but not changed Grey box: part of the internals may be inspected, limited modification is allowed While box: component is open to inspection and modification ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 23

Development process in CBSE l Two separate development processes: • • l Development of components Development of systems out of components Separate process to assess components ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 24

CBSE system development process l l l l Requirements: also considers availability of components (as in COTS) Analysis and design: very similar to what we normally do Implementation: less coding, focus on selection of components, provision of glue code Integration: largely automated Testing: verification of components is necessary Release: as in classical approaches Maintenance: replace components ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 25

Component assessment l Find components l Verify components l Store components in repository ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 26

Component development process l Components are intended for reuse l l l Managing requirements is more difficult More effort required to develop reusable components More effort in documentation for consumers ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 27

Component development process l l l Requirements: combination of top-down (from system) and bottom-up (generality) Analysis and design: generality is an issue, assumptions about system (use) must be made Implementation: largely determined by component technology Testing: extensive (no assumptions of usage!), and well-documented Release: not only executables, also metadata ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 28

Software Connector l l Architectural element that models • Interactions among components • Rules that govern those interactions Simple interactions • Procedure calls • Shared variable access Complex & semantically rich interactions • Client-server protocols • Database access protocols • Asynchronous event multicast Each connector provides • Interaction duct(s) • Transfer of control and/or data ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 29

Where are Connectors in Software Systems? ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 30 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Benefits of First-Class Connectors l l l Separate computation from interaction Minimize component interdependencies Support software evolution • l l At component-, connector-, & system-level Potential for supporting dynamism Facilitate heterogeneity Become points of distribution Aid system analysis & testing ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 31

An Example of Explicit Connectors Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 32

An Example of Explicit Connectors Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 33

Software Connector Roles l l Communication Coordination Conversion Facilitation ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 34

Connector Types l l l l Procedure call Data access Event Stream Linkage Distributor Arbitrator Adaptor ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 35

A Framework for Classifying Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 36 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Procedure Call Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 37 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Event Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 38 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Data Access Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 39 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Linkage Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 40 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Stream Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 41 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Arbitrator Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 42 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Adaptor Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 43 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Distributor Connectors ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 44 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

How Does One Select a Connector? l l Determine a system’s interconnection and interaction needs • Software interconnection models can help Determine roles to be fulfilled by the system’s connectors • Communication, coordination, conversion, facilitation For each connector • Determine its appropriate type(s) • Determine its dimensions of interest • Select appropriate values for each dimension For multi-type, i. e. , composite connectors • Determine the atomic connector compatibilities ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 45

Configurations/Topologies l An architectural configuration or topology is a connected graph of components and connectors that describes architectural structure • • • l proper connectivity concurrent and distributed properties adherence to design heuristics and style rules Composite components are configurations ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 46

Scope of Software Architectures l l l Every system has an architecture. Details of the architecture a reflection of system requirements and trade-offs made to satisfy them Possible decision factors • • Performance Compatibility with legacy software Planning for reuse Distribution profile » Current and Future • Safety, Security, Fault tolerance requirements • Evolvability Needs » Changes to processing algorithms » Changes to data representation » Modifications to the structure/functionality ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 47

Example Architecture – Compiler Sequential ©Medvidovic, Van Vliet, Mejia-Alvarez Parallel Slide 48

CASE toolset architecture ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 49

Version management system ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 50

Packing robot control system ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 51

Film and picture library ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 52

Architecture in Action: Product Line l Motivating example • A consumer is interested in a 35 -inch HDTV with a built-in DVD player for the North American market. Such a device might contain upwards of a million lines of embedded software. This particular television/DVD player will be very similar to a 35 -inch HDTV without the DVD player, and also to a 35 -inch HDTV with a built-in DVD player for the European market, where the TV must be able to handle PAL or SECAM encoded broadcasts, rather than North America’s NTSC format. These closely related televisions will similarly each have a million or more lines of code embedded within them. ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 53

Growing Sophistication of Consumer Devices ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 54

Families of Related Products ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 55

The Necessity and Benefit of PLs l l Building each of these TVs from scratch would likely put Philips out of business Reusing structure, behaviors, and component implementations is increasingly important to successful business practice • • • l It simplifies the software development task It reduces the development time and cost it improves the overall system reliability Recognizing and exploiting commonality and variability across products ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 56

Reuse as the Big Win l Architecture: reuse of • • • Ideas Knowledge Patterns engineering guidance Well-worn experience ©Medvidovic, Van Vliet, Mejia-Alvarez l Product families: reuse of • • Structure Behaviors Implementations Test suites… Slide 57

Added Benefit – Product Populations ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 58

The Centerpiece – Architecture ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 59

Analogies to Software Architecture l Hardware architecture • • l small number of design elements scale by replication of (canonical) design elements Network architecture • • focus on topology only a few topologies considered » e. g. , star, ring, grid l Building architecture • • multiple views styles ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 60

Architectural models l l Different architectural models may be produced during the design process Each model presents different perspectives on the architecture • • Static structural model that shows the major system components Dynamic process model that shows the process structure of the system Interface model that defines sub-system interfaces Deployment model shows the relationship between system elements and hosts ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 61

An Example Static Model Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 62

An example Deployment Model Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 63

Key points l l l The software architect is responsible for deriving a structural system model, a control model and a sub-system decomposition model Large systems rarely conform to a single architectural model Key architectural concepts are components, connectors, and configurations ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 64

Bibliography l The material of this class come from the Software Engineering class of Ian Sommerville, Nenad Medvidovic, and Han Vliet. ©Medvidovic, Van Vliet, Mejia-Alvarez Slide 65