Introduction to Software Architecture

1

Introduction◦ Background◦ What is software architecture?◦ What’s wrong with the diagram?◦ Software architecture definition

Why is Software Architecture Important?◦ Communication among stakeholders◦ Early design decisions◦ Transferable abstraction of a system

Architectural Structures and Views◦ Module◦ Connector-Component◦ Allocation

2

Think about a situation where we are trying to build a new dog house.

◦ we can build a new one simply by cutting the wood and driving a nail into the wood

3

How about a situation where we have to build a two-storied house?◦ We need

More workers More instruments

◦ We may need to draw a blue-print before constructing the house

4

What if we want to construct a high-rise building◦ Many specialists are involved◦ The high-rise building cannot be built without

careful planning and design Architectures are the key to the successful

construction of the building

planning design construction5

Analogy◦ As the size and complexity of software systems

increases, the design of overall system structure-software architecture- become more significant issues than the choice of algorithms and data structures of computation.

◦ Structural issues include The organization of a system as a composition of

components The protocols for communications The assignment of functionality to design elements Physical distribution, etc.

6

Controlprocess

(CP)

Noisemodel

(MODN)

Reverbmodel

(MODR)

Prop lossmodel

(MODP)

7

Many things are left unspecified:◦ What is the nature of the elements?◦ What are the responsibilities of the elements?◦ What is the significance of the connections?◦ What is the significance of the layout?

Box and arrow drawings alone are not architectures; rather, they are a starting point

All architectural descriptions require three fundamental things:◦ a drawing - illustrating major parts of systems ◦ a legend - explaining what the graphic representation◦ a prose - describing the drawing

8

9

Perry and Wolf, 1992A set of architectural (or design) elements that have a particular form. Perry and Wolf further distinguish between processing elements, data elements, and connecting elements.

Boehm et al., 1995A software system architecture comprises

A collection of software and system components, connections, and constraints A collection of system stakeholders' need statements A rationale which demonstrates that the components, connections, and constraints

define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.

Clements et al., 1997 The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.

10

Architecture defines major components Architecture defines component relationships

(structures) and interactions Architecture omits content information about

components that does not pertain to their interactions

Behavior of components is a part of architecture insofar as it can be discerned from the point of view of another component

Every system has an architecture (even a system composed of one component)

Architecture defines the rationale behind the components and the structure

Architecture definitions do not define what a component is

Architecture is not a single structure -- no single structure is the architecture

11

A unit of distribution, assembly, deployment, and replacement

Implementing a nontrivial functionality Defined by services it provides and

services it requires◦ Services reveal component’s behavior

only as far as required for assembly Meaningful in context of

◦ architecture◦ Component model and a framework

Not necessarily a single unit of code or a single binary

12

Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction

CODE

implementation

design

architecture

Architectural decisions are the most fundamental decisions and changing them will have significant ripple effects.

13

Customer Requirements Architecture

Architectural renderings begin to appear after requirements elicitation and analysis◦ typically we iterate between requirements

and analysis

14

User view of problem

Builder’s view of problem

Modules and connections

Algorithms & data

User Model

Requirements

Architecture

Code

ExecutableData layouts, memory maps

DesignMethods data structures

How to describe SA? Abstractly as box-and-line diagrams Accompanying prose

◦ Explain the meaning behind the symbols ◦ Provide some rationale for the specific choice of

components and interactionsEx)“Camelot is based on the client-server model and uses

remote procedure calls …”“We have chosen a distributed, object-oriented

approach to managing information”

Basic Web System

[Orfali 99]

Web ServerWeb Server

HTMLHTMLDocumentsDocuments

BrowserBrowser

Document

Request

applicationapplicationCGI

Web Server

DataBase

Browser

[Conallen 99]

Document

Request

ISAPINSAPI

Java Servlet

ISAPINSAPI

Java Servlet

ASPJSP

ASPJSP

ScriptedPage

ScriptedPage

ScriptedPage

ScriptedPage

ScriptedPage

ScriptedPage

ScriptedPage

HTMLPage

Common Architectural Styles

Dataflow systems◦ Batch sequential◦ Pipes and filters

Call-and-return systems◦ Main program and subroutine◦ OO systems◦ Hierarchical layers

Independent components◦ Communicating process◦ Event systems

Virtual machines◦ Interpreters◦ Rule-based systems

Data-centered systems(Repositories)◦ Databases◦ Hypertext systems◦ Blackboards

A style Components + Connectors + Constraints

◦ Components : Computational components ◦ Connectors : Interactions among components◦ Constraints : How they can be combined

Questions What is the design vocabulary? What are the allowable structural patterns? What is the underlying computational model? What are the essential invariants of the style? What are some common examples of its use? What are the advantages and disadvantages of

using that style? What are some of the common specializations??

Pipe and Filter - 1

Pipe and Filter - 2 Components

◦ Filters Connectors

◦ Pipes Invariants

◦ Filters must be independent entities. Should not share state with other filters

◦ Filters do not know the identity of their upstream and downstream filters

CourseFilter15671

MainFilter MergeFilter

CourseFilter21701

Input File

Output File

Filter File Pipe

Main Program and Subroutines - 1

Main controllerMain controller

Sub 1Sub 2

Sub 3

comp

manager

memmem

Main Program and Subroutines - 2 System model

◦ Call and definition hierarchy ◦ Subsystems often defined via modularity

Components ◦ Procedures and explicitly visible data

Connectors◦ Procedure calls and explicit data sharing

Control◦ Single thread

ADT/Objects - 1

data

methods

data

methodsdata

methods

data

methods

data

methods data

methods

ADT/Objects - 2 Components

◦ Objects(Manager), Instance of ADT Connectors

◦ Function and Procedure calls Invariants

◦ An object is responsible for preserving the integrity of its representation

◦ The representation is hidden from other objects

ADT/Objects - 3 Advantage

◦ Possible to change the implementation without affecting those clients

◦ Allow designers to decompose problems into collections of interacting agents

Disadvantage◦ Must know the identity of that other object◦ Whenever the identity of an object changes it is

necessary to modify all other objects that explicitly invoke

Event Based, Implicit invocation - 1

AA

CC

trigger

announc

e

trigger

trigger

announce

announcee1

e2

DD

BB

Event Based, Implicit invocation - 2 Components

◦ Modules whose interfaces provide both a collection of procedures and a set of events

Connectors◦ Event registration and procedure invocation

Invariants◦ Announcers of events do not know which

components will be affected by those events

Event Based, Implicit invocation - 3 Reactive integration, Selective broadcast

◦ A component can announce one or more events◦ Other components can register an interest in an

event by associating a procedure with it◦ When the event is announced, the system itself

invokes all of the procedures that have been registered for the event

◦ An event announcement implicitly causes the invocation of procedures in other modules

Event Based, Implicit invocation - 3 Usages

◦ Programming environments to integrate tools◦ In database management systems

Ensure consistency constraints◦ In user interfaces to separate presentation of data

from applications that manage data◦ Syntax directed editors◦ Debugger

Layered Systems - 1

Kernel LayerKernel Layer

Resource Management LayerResource Management Layer

System Service LayerSystem Service Layer

Application LayerApplication Layer

Layered Systems - 2 Components

◦ Layers Each layer provides service to the layer above it and

serves as a client to the layer below Connectors

◦ Protocols Constraints

◦ Topological◦ Limit interaction to adjacent layers

Layered Systems - 3 Usage

◦ Communication layer OSI ISO model

◦ Database systems and Operating system Some of the X window system protocols

Repository - 1

RepositoryRepositoryRepositoryRepository

compcomp compcomp compcomp

compcomp compcomp compcomp

Repository – 2 Components

◦ Central data structure Represent the current state,

◦ A collection of independent components Operate on central data store

Repository - 3 Traditional Database

◦ The types of transactions in an input stream trigger selection of processes to execute

Blackboard◦ The current state of the central data structure is

the main trigger for selecting processes to execute

Repository - 4 Blackboard

◦ The knowledge source Separate, independent parcels of application-

dependent knowledge. Interaction among knowledge sources takes place

solely through the blackboard◦ The blackboard data structure

Problem-solving state data Organized into an application-dependent hierarchy

◦ Control Driven by the state of the blackboard Knowledge sources respond opportunistically when

changes in the blackboard make them applicable

Blackboards - 1

Blackboard(shared data)

Blackboard(shared data)

ks ks ks

ks ks ks

ks

ksks

ks

Interpreters - 1

program being interpreted

interpreter control unit

Memory

data (program state)

interpreter execution unit

Interpretation Engine

instruction updatesdata

inputs

outputs

instruction

interpreter state

Interpreters - 2 System model

◦ Virtual machines Components

◦ One state machine and three memories Connectors

◦ Data access and procedure call Control

◦ Usually state transition for execution engine ◦ Input-driven for selection of what to interpret

Rule-based Systems - 1

MemoryMemory

rule scheduler

working memory

rule interpreter

Inference EngineInference Engine

rules and facts updatesdata

inputs

outputs

selected actionselected action

engine state

rules facts

knowledge base

Rule-based Systems - 2 System model

◦ Virtual machines Components

◦ One inference engine and three memories (knowledge base, working memory, and inference engine state)

Connectors ◦ Data access and production rule application

Control◦ Usually state transition for inference engine ◦ Goal-driven for selection of what to interpret

LexLex SynSyn SemSem OptOpt CodeCode

Text Code

Compiler construction - 1Compiler construction - 1

LexLex SynSyn SemSem OptOpt CodeCodeText Code

Sym tabSym tab

LexLex SynSyn SemSem OptOpt CodeCodeText Code

Sym tabSym tab

TreeTree

Compiler construction - 2Compiler construction - 2

LexLex

SynSyn

SemSem

OptOpt

CodeCode

OptOpt

SynSynEditEdit

TreeTree

Sym tabSym tab

Compiler construction - 3Compiler construction - 3

Contents The concept of software architecture Software architecture patterns Building software systems from parts Software Architecture Analysis Discussion

COTS(Commercial Off-The-Shelf) A part of a deployed system Purchased from a vendor Sold in binary form in identical copies Available to general public Example

◦ Windows NT, Netscape Communicator

Stages COTS Market

◦ Examine which products? Selected

◦ Which products are fit? Adapted

◦ Use which features Assembled

◦ Which design best reflects market factors? Refreshed

◦ Version, Upgrading

Problems Code size

◦ Each piece was huge by itself◦ (Ex) Tools had to include X, even if they didn’t

need it Performance

◦ Efficiency can be low Need to modify/understand reused parts in

significant ways◦ Event loop rewrite◦ Memory allocation

52

Architecture assures conceptual integrity while allowing change ◦ New requirements◦ Changed requirements ◦ Technology churn

Architecture supports system longevity

53

“Divide and conquer”◦ Decomposition into components◦ Hiding of implementation details

Separation of concerns ◦ Components (and layers) encapsulate

details◦ Different components can be implemented

by people with different expertise

54

Architecture iterations remove major risks

Architecture prototypes allow for collection of metrics ◦ Development cost metrics◦ Schedule metrics

55

Well componentized systems support better and easier ◦ Diagnostics ◦ Traceability◦ Error detection

Testing is use-case driven

56

Architecture defines rules of substitution

Component interfaces define substitution boundaries

Architecture enables different granularity of reuse ◦ Small-scale reuse at component level◦ Large-scale reuse

Subsystems Products Frameworks

57

architecture supports communication between stakeholders

Different views address different stakeholder concerns

architecture communicates key design decisions

architecture design rationale communicates the tradeoffs

58

Organizational structure aligned with architecture ◦ Development team(s)◦ Subcontractors

Components/subsystems used as units of ◦ Development◦ CM◦ Testing◦ Delivery and upgrade

Components/subsystems developed concurrently

59

Software Requirements and Specifications, Michael Jackson, 1995 Software

Software Architecture: Perspectives on an Emerging Discipline, Shaw & Garlan, 1996

Architecture in Practice, Bass, Clements, & Kazman, 1998