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

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

Documents

software architecture

picture software architecture

software product

task of software design

systemlevel testing

requirements specification

highlevel model

complexity techniques