CSci 597 Software Architecture: An Introduction Dr. Nenad Medvidovic Assistant Professor Center for Software Engineering Computer Science Department University

CSci 597

Software Architecture:An Introduction

Dr. Nenad Medvidovic

Assistant ProfessorCenter for Software EngineeringComputer Science Department

University of Southern California

Software Architecture

Topics to be Covered

• Motivation

• Introduction to Software Architectures

• Overview of Architectural Building Blocks

• Scope of Software Architectures

• Sources of Software Architectures

• “Architecting” Software Systems

• Summary

• Additional Resources


Motivation• Software systems are rapidly and continously growing in size and

complexity

• Techniques and tools for developing and maintaining such systems typically play catch-up

• To deal with this problem, many approaches exploit abstraction

– Ignore all but the details of the system most relevant to a task (e.g., developing the user interface or system-level testing

– This greatly simplifies the model of the system

– Apply techniques and tools on the simplified model

– Incrementally reintroduce information to complete the “picture”

• Software architecture is such an approach

– Applicable to the task of software design


What is Architecture?• A high-level model of a thing

– Describes critical aspects of the thing– Understandable to many stakeholders

• architects, engineers, workers, managers, customers

– 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?


What is Software Architecture?• A software system’s blueprint

– Its components– Their interactions– Their interconnections

• Informal descriptions– Boxes and lines– Informal prose

• A shared, semantically rich vocabulary– Remote procedure calls (RPCs)– Client-Server– Pipe and Filer– Layered– Distributed– Object-Oriented


From Requirements to Architecture

• From problem definition to requirements specification

– Determine exactly what the customer and user want

– Specifies what the software product is to do

• 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


Focus of Software Architectures

•Two primary foci

– System Structure

– Correspondence between requirements and implementation

•A framework for understanding system-level concerns

– Global rates of flow

– Communication patterns

– Execution Control Structure

– Scalability

– Paths of System Evolution

– Capacity

– Throughput

– Consistency

– Component Compatibility


Why Software Architecture?• A key to reducing development costs

– Component-based development philosophy– Explicit system structure

• A natural evolution of design abstractions– Structure and interaction details overshadow the choice of algorithms

and data structures in large/complex systems

• 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


Even Simple Software is Complex

• Source code level view of an application

aTruck aShip aAirplane theWarehouseCo llecti on

theVehicleCollection

UML-A Generated Dependency Class:theRouter Dependency (1.0)

theStorage

aVehicle


availableVehicleCollection

UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Genera ted As socia tion C lass: theVehicleC ollec tion Genera lization (1. 0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML-A Generated Association Class:theVehicleCollection Generalization (1.0)UML- A Generated Ass ociati on Cl ass:theVehi cleCo llection Generali zation (1.0 )UML-A Generated Association Class:theVehicleCollection Generalization (1.0)


availableGoods

aPort

aPortC ollec tion

aSurp lus aDifficiency

theTimeNeeded

theGoods

UML-A Generated Association Class:aWarehouse Association (0.5)


UML-A Generated Association Class:availableGoods Association (0.5)

aRouteCollection

UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)UML-A Generated Association Class:aRoute Association (0.25)

UML-A Generated Dependency Class:theRouter Dependency (0.5)UML-A Generated Dependency Class:theRouter Dependency (1.0)


theAWT

aVehiceDialog aWarehouseDialog aPortDialog aRouterDialog

aWarehouse

UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)

UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)

UML-A Generated Association Class:aDifficiency Association (1.0)U ML-A Generated Association Class:aD ifficiency A ssoci ation (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)U ML-A Generated Association Class:aD ifficiency A ssoci ation (1.0)UML-A Generated Association Class:aDifficiency Association (1.0)UML-A Genera ted Associ ation C lass:aSurp lus Associ ation (1.0)UML-A Generated Association Class:aSurplus Association (0.5)

UML-A Generated Associ ation Class:aRoute Association (0.5)

aLocation

UML-A Generated Association Class:aNavPoint Association (1.0)



UML-A Generated Association Class:aNavPoint Association (0.5)UML-A Generated Association Class:aNavPoint Association (0.5)

UML-A Generated Association Class:aWarehouse Association (0.5)aNavPoint


UML-A Generated Association Class:aWarehouse Association (0.5)UML-A Generated Association Class:aWarehouse Association (0.5)



UML-A Generated Association Class:aRoute Association (0.5)

aRoute

UML-A Genera ted Dependency C lass :aRou teCol lection Ass ociation (0. 25)



UML-A Generated Dependency Class:aRouteCollection Association (0.5)

UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)UML-A Generated Association Class:aNavPoint Association (1.0)



UML-A Generated Dependency Class:theRouter Association (0.25)


theCargoRouter

UML-A Generated Association Class:theRouter Association (0.25)

UML-A Genera ted As socia tion C lass: theWarehouseCo llection Dependency ( 0.25)



t heRou ter

UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)

UML-A Generated Association Class:theWarehouseCollection Dependency (0.5)

UML-A Genera ted Dependency Class :aRouteCollection Ass ociation (0.5)UML-A Generated Association Clas s:theWarehouseCollec tion Dependency (0.5)

UML-A Generated Association Class:theVehicleCollection Dependency (0.5)UML-A Generated Association Class:availableVehicleCollection Dependency (0.5)UML- A Generated Generaliz ation Class :avail ableVehicleCollection Dependenc y (1.0 )


UML-A Generated Dependency Class:theRouter Association (0.5)UML-A Generated Dependency Class:theRouter Association (1.0)


UML-A Generated Dependency Class:theWarehouseCollection Dependency (1.0)

UML-A Generated Dependency Class:theRouter Association (1.0)UML-A Generated Dependency Class:theRouter Association (1.0)


Achitecture Alleviates the Complexity

• Architecture level view of the application

VehicleDel iveryPort

CargoRouter

RouterConn

GraphicsBinding : GraphicsBinding

GraphicsConn

Warehouse

ClockConn

Clock : Clock

10: notification9: notification

5: request

3: request4: request

2: notification

1: request

7: request

6: notification

8: request


Definitions of Software Architecture• Perry and Wolf

– Software Architecture = {Elements, Form, Rationale}

• Shaw and Garlan

– Software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on those patterns

• Kruchten

– Architecture deals with abstraction, decomposition, composition, style and aesthetics.

• Canonical Building Blocks

– Components, Connectors, Configurations

What How Why


Components

• A component is a unit of computation or a data store.

• Components are loci of computation and state.

– Clients

– Servers

– Databases

– Filters

– Layers

– Abstract Data Types (ADTs)

• A component may be simple or composite.

– Composite components describe a system.


Connectors• A connector is an architectural element that models:

– Interactions among components– Rules that govern those interactions

• Simple interactions

– Procedure calls– Shared variable access

• Complex and semantically rich interactions

– Client-Server Protocols– Database Access Protocols– Asynchronous Event Multicast– Piped Data Streams


Configurations/Topologies

• An architectural configuration or topology is a connected graph of components and connectors which describes architectural structure.

– Proper connectivity

– Concurrent and distributed properties

– Adherence to design heuristics and style rules

• Composite components are configurations.

C3 C4 C5

A

B C

D

C2C1

C7C6


Scope of Software Architectures• Every system has an architecture.• Details of the architecture are 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


Compiler Architecture

Lexer

Parser

Semantor

Optimizer

CodeGenerator

Lexer Parser Semantor

InternalRepresentation

OptimizerCode

Generator

Sequential Parallel


Compiler Architecture Pros and Cons• Sequential

+ Conceptual Simplicity

+ Architecture reflects control flow

- Performance

• Parallel

+ Performance

+ Adaptability

- Synchronization

- Coordination• Analysis and testing

+ = Pro, - = Con


Sources of Architecture (1)• Architecture comes from “black magic, people having ‘architectural visions’”

• 3 + 1 main sources of architecture

– Intuition

– Method

– Theft (i.e., reuse)

– Blind luck

• Their ratio varies according to:

– Architect’s experience

– System’s novelty

Theft MethodIntuition

Theft MethodIntuition


Sources of Architecture (2)

• Theft

– From previous similar systems– From literature

• Method

– Systematic and conscious– Possibly documented– Architecture is derived from requirements via transformations

and heuristics

• Intuition

– “The ability to conceive without conscious reasoning.”– Increased reliance on intuition increases the risk


Routine Design

• Method is critical

– “An architecture built with 50% theft and 50% intuition is doomed to fail.”

• Standardized methods

• Similarity to previous solutions

• Theft

• Cheaper, but not optimal

• Can be done by merely “good” designers

• Potential pitfall

– Over-reusing


Innovative Design

• Raw invention

• Intuition

• Derivation from abstract principles

• More optimal

• More expensive

• Must be done by “great” designers

• Potential pitfall

– Reinventing the wheel

– Single point of failure in staffing


Software “Architecting”

• The “architecting” problem lies in:

– Decomposition of a system into constituent elements

– Composition of (existing) elements into a system

• Two idealized approaches

– Top-Down• Decompose the large problem into sub-problems• Implement or reuse components that solve the sub-problems

– Bottom-Up• Implement new or reuse existing stand-alone components• Compose (a subset of) the components into a system

• A realistic approach will require both.


Issues in Decomposition (1)• How do we arrive at:

– Components?– Connectors?– Their Configuration?

• What is the adequate component granularity level?• What constraints on components are imposed by:

– Functional requirements– Non-functional requirements– Envisioned evolution patterns– System Scale– Computing Environment– Customers/Users

• What assumptions can components make about one another?


Issues in Decomposition (2)

• How do components interact?

• What are the connectors in the system?

• What is the role of the connectors?

– Mediation

– Coordination

– Communication

• What is the nature of the connectors?

– Type of interaction

– Degree of concurrency

– Degree of information exchange


Issues in Composition

• Where does one locate existing:

– Components?

– Connectors?

– Configurations?

• How do we determine which elements are needed?

– Both at development time and at reuse time

• What is the adequate element granularity level?

• How do we ensure effective composition of heterogeneous elements?

• How do we know that we have the needed system?


Summary (1)

• Software architecture has proven to be a key to:

– Controlling system development costs

– Ensuring critical system properties

– Highlighting major tradeoffs in development

– Enabling effective deployment, operation, and evolution

• Several architectural concepts are part of mainstream development

– Components

– Complex interactions (connectors)

– Styles and patterns


Summary (2)

• To effectively leverage architecture, know your:

– Requirements

– Constraints

– Domain

– Components

– Connectors

– Legacy and “off-the-shelf”

– Customers/Users

– Management

– Developers

Documents

CSci 597 Software Architecture: An Introduction Dr. Nenad Medvidovic Assistant Professor Center for Software Engineering Computer Science Department University