Software Design and

Architecture
Lecture#9,10
 Review

•Intr odu ctio nto softwarearchite ctur e

•Archite ctur evs Design
•Archite ct’s responsibilities
•Archite ctur eBusinessCycle
 Outline

•Archite cturalR epr es entation

• Using UML
• UsingADL
 ArchitecturalRepresentations

•Software archite ctur e spe cifies a high level of

software syst em abstra ction by using
dec ompo sition,co mposition,archite ctur estyles,
and qualityattributes.
 ArchitecturalRepresentations
•Every s oftware archite cture must des cribe its
collec ti on of co mpo nents and the connectio nsand
intera ctionsamon gthes e co mpo nents.

•It must als o specify the deploy mentconfigurationof

all co mpo nentsand connectio ns.

•Additi onally, a s oftware archite cture desi gn must

confo rm to the proje ct'sfunctionaland nonfuncti onal
requir eme nts.
 ArchitecturalRepresentations–
Box diagrams
•Box-and-lin ediagramsare often used to des crib e
the business concepts and pro cess esduring the
analy sis phas e of the software developm ent
life cy cle.
 Box diagrams

•Thes e diagrams co m e with des criptions of

co mpon ents and connectors, as well as other
des crip tions that provid e co m m on natural
interpretatio ns.
Unified modeling language
 UML for SoftwareArchitecture

• The Unifie dModelingLangua ge(UML) is a graphical

languagefor
• visualizing ,
• spe c ifying ,
• co nstru c tingand
,
• do cu m e nting
the artifactsof a s oftware -inte nsive
syste m.

• UML offersa standardway to draw a syste m'sblue prints.

 ArchitectureView Models

• a m odelis a co mplet e,simplifieddes criptionof a

syst emfro m a particul arpersp ectiveor viewpoint.

•There is no single view that can pres ent all

asp ects of co mplexsoftwareto stakeholders!!!
 View Model

•View m odels provid e partial repr es entationsof

the software archite ctur eto spe cificstakeholders
such as
• the syste mus e rs,
• the analyst/ des igner,
• the de ve lope r /pr ogram mer,
• the syste minte grat or,and
• the syste mengineer.
 View Model

Software de signers can organize the

de scriptionof their architecturede cisions
in differentviews.
 The 4 +1 View Model
•The 4+1 view m odel was originallyintr oduce dby
Phili ppeKruchten(Kruchten,1995).

•The m odel providesfour ess entialviews:

• the lo gicalvie w,
• the proc e ssvie w,
• the phys ic alvie w,and
• the develop me ntvie w
• and fifth is the s cenarioview
 The 4+1 view model
• multiple-vie wmode lthat addre ss esdiffe re ntaspe c tsand co nce rns
of the sys te m.
• standardiz e sthe so ftware de s ign do c um ents and make s the
de s igneas yto unders tandby all stake holde rs.
 The Scenario View

•The s cenario view des cribesthe functionalityof the

syste m, i.e., how the us er empl oys the syste m and
how the syste mprovidess ervic esto the us ers.

•It helps desi gners to dis c over archite ctureele m ents

during the desi gn pro cess and to validate the
archite cturedesi gnafterward.

• The UMLuse cas e diagra mand otherve rbaldoc u me nts

 The Logical or ConceptualView

•The lo gical view is bas ed on applicationdo main

entities nec essary to imple m ent the fun ctional
require m ents.

•The lo gical view spe cifiessyst em dec ompo sition

into conceptual entities (such as objects) and
connections between them (such as
ass o ciations).
 The logical view

•The lo gicalview is typicall ysupp ort edby

• UML static diagrams includingclas s / objec tdiagrams
and
• UML dynamicdiagrams suc has the interac ti onove rall
diagram, se quencediagram, c o mmunicationdiagram,
statediagram,and activitydiagram.
 The Developmentor Module View

• The deve lopme ntview derives fr om the lo gical view and

des cribe sthe staticorganiz ati onof the syste mmodule s.

• Module s suc h as name spaces ,class library, subs yste m,or

packages are buildingbloc ks that group class esfor further
deve lopme ntand imple mentati on.

• UML diagrams suc h as package diagrams and c o mponent

diagramsare oftenuse dto suppo rtthis view.
 The Process View
• The proc e ssvie w fo cus eson the dynamicas pe ctsof the syste m,
i.e .,its exe cu tio ntime behavior.

• This vie w maps functions ,ac tivities, and interac tionsonto

runti meimple me ntatio n.

• The proc e ss vie w takes care of the co ncurre ncy and

synchroni zation
i ss uesbetwe ensubs yste ms .

• The UML ac tivity diagra mand interac tionove rview diagra m

suppo rtthi svie w.
 The Physical View
• The physic a lviewdesc ribesinsta llation,co nfig uratio n,and deplo y me nt
of the so ftwareapplic atio n.

• It co nce rnsitse lfwithhow to delive rthe deplo y-a blesyste m .

• The physic alview sho wsthe mappingof so ftwareonto hardware .

• It is particularlyo f interestin dist ribu tedo r parallelsyst e ms .

• The UML deplo y me ntdiag ra m sand othe r do c ume ntationare ofte n

use dto suppo rtthis view.
 The User Interface View

•The Us er Interfac e(UI) view is an extend edview that

provides a clear us er- c omputerinterface view and
hide simple mentati ondetails.

•This view may be provided as a s eries of s cre en

snapshotsor a dynami c,intera ctiveprototypede m o.

•Any m odificationon this view will have directimpac t

on the s cenariosview.
 4+1 view model

The 4+1 view is an architecture

verification technique for studying and
docum entingsoftwarearchitecturede sign.
Architecture Description
language
 What is an ArchitectureDescription
Lan guag e?

•It is a m odellingnotationto supp ortarchite ctur e-

bas eddevelopm ent
• us e d to de fine and mode l syste marc hite ctureprior to
de tailedde s ignand imple mentation
 Many ADLs

• Architecture Description Languages (ADLs) can be used to

specify an architecture
• UML (OMG) - general-purpose
• SADL (SRI)
• Aesop (Carnegie Mellon University)
• Acme (CMU) – and interchange format
• Rapide (Stanford University)
• Wright (CMU)
• Darwin (Imperial College London)
 Parts of an ADL

• Architecture Style =
• {Component/Connector Vocabulary, Topology,Semantic Constraints}
• Components (locus of computation),
• filt er, data store, object, process, server

• Connectors (interactions between components),

• procedure call, RPC, pipe, TCP/IP

• Key issue - tool support

 Acme: a generic ADL

• n Developed by David Garlan and others (CMU) and

David Wile (USC)
• Simple, generic language for describing software
architectures and families of architectures
• Intended to be standard representation for tools
 Tools – ACME Studio

• ACME Studio - a viewer and editor for ACME

descriptions.
• Text and graphical views supported.
 Elements of Components and Connectors
view
•Com ponents model principal run-time elements that have a
set of ports
•Ports model component’s interfaces through which
component interacts with other components via connectors
•Connect ors model the pathways of communication between
components and have a set of roles
•R oles model the specifications of behavior requires of the
components that use a given connector
Example of Componentand Connector
(C&C) Model in Acme ADL

• Simple-cs system consist of a

single client and a single
server, interacting through
rpc based connector

• In this representation we can

analyze our C&C model to
see if there are any
unattached roles or ports,
name collisions and etc.
Modeling Architectural Properties in
Acme ADL
• Properties are name-value pairs
that can be associated with any
architectural element: component,
port, connector
• Sync-request port property
indicates if rpc-request port is
synchronous or asynchronous,
max-transactions-per-second and
max-clients-supported component
properties indicate maximum
properties of server component
and protocol property of rpc
connector indicates the name of
the communication protocol
 Summary

• Architectural Representation
• Using UML
• Using ADL