Software Architecture

SOFTWAREARCHITECTUREVTUEDUSATNOTESACADEMICYEAR20092010
CHAYAPATHYVENKATARAMANRVCE,SRIRAMGOVINDARAJANPESIT,SHASHIDHARAHS
,MSRITBANGALORE
Total pages :124 memory : 2130 KB

TEXT BOOKS:
1. Software Architecture in Practice Len Bass, Paul Clements, Rick
Kazman, 2 Edition, Pearson Education, 2003.
2. Pattern-Oriented Software Architecture, A System of Patterns - Volume
1 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad,
Michael Stal, , John Wiley and Sons, 2006.
3. Mary Shaw and David Garlan: Software Architecture- Perspectives on
an Emerging Discipline, Prentice-Hall of India, 2007.

REFERENCE BOOK:
1. Design Patterns- Elements of Reusable Object-Oriented Software E.
Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley. 1995. Web
site for Patterns: http://www.hillside.net/patterns/

INSTRUCTIONSTOSTUDENTSWHILEREFERINGTOTHENOTES
1. STUDENTSAREREQUIREDTOUNDERSTANDANDANALYSETHESENTENCESWRITTEN
INCAPITALLETTERSANDTYPEDINBOLDITALICS.
2. CASESTUDIESARETOBEREWORKEDFORUNDERSTANDINGCONCEPTS
3. ALL ARCHITECTURAL PATTERNS ARE TO BE PREPARED FROM THE TEXT
Pattern- Oriented Software Architecture, A System of Patterns -
Volume 1 Frank Buschmann, Regine Meunier, Hans Rohnert,
Peter Sommerlad, Michael Stal, , J ohn Wiley and Sons, 2006.

4. ALL ARCHITECTURAL STYLES ARE TO BE PREPARED FROM THE TEXT

5. Mary Shaw and David Garlan: Software Architecture-
Perspectives on an Emerging Discipline, Prentice- Hall of I ndia,
2007

6. OTHER THAN ARCHITECTURAL PATTERNS AND ARCHITECTURAL
STYLES ALL THE REMAINING CONCEPTS ARE TO BE PREPARED FROM
Software Architecture in Practice Len Bass, Paul Clements,
Rick Kazman, 2 Edition, Pearson Education, 2003.

,MSRITBANGALORE
PARTA
UNIT1
BASICSOFSOFTWAREARCHITECTURE:
Allbasicpointstypedincapitallettersareexplainedindetailinthe8units.8unitsare
groupedaccordingtoVTUsyllabus.
DEFINATION:
THESOFTWAREARCHITECTUREISTHESTRUCTURTEOFSTRUCTURESOFASYSTEMWHICH
COMPRISESOFEXTERNALLYVISIBLEPROPERTIESOFELEMENTSANDTHEIRRELATIONSHIPS
SOFTWAREPROCESSESANDABC(ARCHITECTURALBUSSINESSCYCLE)
1.CREATINGBUSSINESSCASE
2.UNDERSTANDINGTHEREQUIREMENTS
3.CREATINGARCHITECTURE
4.DOCUMENTATIONANDCOMMUNICATION
5.ANALYSINGARCHITECTURE
6.GENERALIMPLEMENTATIONCONFERMINGTOARCHITECTURE
ARCHITECTSHOULDHAVE(PROCESSRECOMMENDATIONS)
1.FUNCTIONALREQUIREMENTS
2.ONESTATICANDONEDYNAMICVIEW
3.QUANTITATIVEATTRIBUTES(THROUGHPUT)
4.INCREMENTALIMPLEMENTATION
5.TIMEBUDGETS
STRUCTURALRULES
,MSRITBANGALORE
1.WELLDEFINEDMODULES(FUNCTIONALRESPONSIBILITIES)
2.WELLDEFINEDINTERFACES
3.QUALITYATTRIBUTES
4.DONOTDEPENDUPONVERSIONS
5.EVERYTASKFORAPERTICULARPROCESSORSHOULDBEEASILYMODIFIABLE.
IMPLICATIONSOFTHEDEFINATIONINDETAIL:
1.ARCHITECTUREDEFINESSOFTWAREELEMENTS
2.SYSTEMCOMPRISESOPFMORETHANONESTRUCTURE
3.THEBEHAVIOROFEACHELEMENTISPARTOFARCHITECTURE.
4.ARCHITECTUREISAHIGHLEVELDESIGN
VASASHIPDESIGN
1.1620,SWEDEN
2.70METERLONG,CARRIES300SOLDIERS,64HEAVYGUNSMOUNTEDON
GUNDECKS
3.DESIGNERDIED,NOWRITTENDOCUMENTS
4.POORREQUIREMENTSANDEXTENSION.
5.1628SHIPDROWNED.
Moraloftheshipdesign:poorrequirementsandextensibility,allqualityattributesare
explainedinunit3
ArchitecturalPatterns,ReferenceModels,andReferenceArchitectures
FowlerinhisAnalysisofPatterns(1996),definesPatternsasanideathathasbeenusefulin
one practical context and will probably be useful in others Architectural Patterns are the
highestlevelpatterns,whichspecifyfundamentalstructureofanapplication
ArchitecturalPatternsarecomposedofasetofcomponenttypes(e.g.,Process,procedure)
that perform some function at runtime. The components are arranged in a specific
topological layout showing their runtime relationships. It also includesrules and guidelines
for organizing the relationships between them. Patterns also specify a set of connectors
,MSRITBANGALORE
(e.g., Data streams, sockets) that mediate communication among components. An
architecturalpatternisgenericanddomainneutral.
The clientserver pattern is an example of architectural pattern, which has two element
types (Client and Server). Their relationship is a protocol that the server uses to
communicate with each of its clients. The semantic constraint is that the clients dont
communicatedirectlywitheachother.Notethatfunctionalityisexcludedhere.
The characteristics of all architectural patterns are that they exhibit known quality
attributes. Some patterns solve performance problems, others apply to highsecurity
systems, orhighavailability goals. An architectural pattern is basically reuse of experience.
What makes it a pattern is the fact that it is recurring. If a design solution in its essential
distilled form is found in multiple systems and is a successful design, then this solution
becomesapattern
ExamplesofArchitecturalpatternincludeLayer,PipeandFilterandClientServerPattern.
ReferenceModels
Areferencemodelisapreengineeredandintegratedorganizationalviews.Theyarisefrom
experience, and are thus a characteristic of mature domains. For example, an operating
system has certain major subsystems like file system, a memory manager, a process
scheduler,anetworkinterface,andaninterprocesscommunicationsubsystem.
A reference model specifies the division of functionality into elements, together with data
flow between them. Note that this is not the same as the pattern, which is a way to
enable that particular flow. So what you have is a standard decomposition of a known
problemintopartsthatcooperativelysolvetheproblem.
For example, the Compiler reference model includes a description of parts and data flow
betweenthem.
Client l la ay ye er rN N
l la ay ye er rN N 1 1
L La ay ye er r1 1
Layerpattern
Client
Client
Client
Server
ClientServer
Pattern
,MSRITBANGALORE
ApopularexampleofareferencemodelistheOSIReferenceModelshownbelow
A reference model is used to clarify things within an environment or a problem space by

providing a description of the problem and highlighting the major concerns of the
stakeholders
A reference model creates standards for both the elements in the model and their
relationships to one another. It also helps break down a large problem space into smaller
problemsthatcanbeunderstood,tackled,andrefined.
A reference model helps improve communication by creating a model of the entities with
clearroles,andtheirrelationships
ReferenceArchitectures
Reference architectureisareferencemodelmapped onto software elements and thedata
flows between them. It is a proven template solution for architecture for a particular
domain.Italsoprovidesacommonvocabularywithwhichtodiscussimplementations,often
withtheaimtostresscommonality.
In a Reference Architecture, the software elements cooperatively implement the
functionalitydefinedinthereferencemodel.Thatis,itmapsthefunctionalityofareference
modelontosystemdecomposition.Thismappingmaynotbeonetoone.Thatisanelement
mayimplementapartofafunctionorseveralfunctions.
An example Reference architecture might map the compiler reference model onto pipe
andfilterarchitecturepattern.Notethatthisisstillnotasoftwarearchitecture,becauseit
istoogeneric,neverthelessitsastart.
,MSRITBANGALORE
CharacteristicsofaGoodReferenceArchitectures
A reference architecture is a description of a solution that solves a specific recurring
problem. Organizations adopt certain reference architecture as an accepted approach to
solving a specific problem within a domain. This will be used repeatedly, in numerous
projectstosolvesimilarproblems.
A reference architecture is a proven approach to solving the specific problem, that is,
successfullyusedinpreviousprojectsandapplications.Manyofthereferencearchitectures
in use within organization that have been recognized from successful implementations,
documentedforeasyreuse.
Areferencearchitectureneedstobewelldescribedifitstobeuseful.Itneedstoassistwith
decisionmakingbyarchitects,projectmanagersanddevelopers.Thereferencearchitecture
needstodescribewhatproblemissolves,whenitshouldbeusedandhowitshouldused.It
alsoshouldincludestandardsthatneedtobeimplementedaspartofthesolution.
ReferenceArchitectureBenefits
A reference architecture provides a common domainspecific language for the various
stakeholders. Within an organization that adopts a reference architecture it provides
consistency of implementation of technology to solve problems. They also supports
enterprisearchitectureandITgovernancebyencouragingadherencetocommonstandards
and patterns. Another important benefit is it encourages adoption of common asset reuse
approaches.Thisisaccommodatedbydocumentingexistingwellprovendesigns.Reference
architecturesareespeciallyusefulastheyhelpbuildcomplexsystems.
Importance of Software Architectures:
There are fundamentally three reasons for software architecture's importance:
1. Communication among stakeholders. Software architecture represents a common
abstraction of a system that can be used as a basis for mutual understanding,
negotiation, consensus, and communication.
2. Early design decisions. Software architecture manifests the earliest design decisions
about a system, and these early bindings carry weight far out of proportion to their
individual gravity with respect to the system's remaining development, its
deployment, and its maintenance life. It is also the earliest point at which design
decisions governing the system to be built can be analyzed.
3. Transferable abstraction of a system. Software architecture constitutes a relatively
small, intellectually graspable model for how a system is structured and how its
elements work together, and this model is transferable across systems
1. Communication among stakeholders
a. Each stakeholder of a software system is concerned with different system
characteristics that are affected by the architecture.
,MSRITBANGALORE
b. Architecture provides a common language in which different concerns can be
expressed, negotiated, and resolved at a level that is intellectually manageable
even for large, complex systems
2. Architecture manifests the earliest set of design decisions
The early decisions are the most difficult to get correct and the hardest to change later
in the development process, and they have the most far-reaching effects.
a. The Architecture Defines Constraints on Implementation
An implementation exhibits architecture if it conforms to the structural design
decisions described by the architecture.
Resource allocation decisions also constrain implementations.
The constraints permit a separation of concerns that allows management
decisions to make the best use of personnel and computational capacity.
b. The Architecture Dictates Organizational Structure
The structure dictated by architecture on the system becomes engraved in the
structure of the development project. Because the system architecture includes
the highest-level decomposition of the system, it is typically used as the basis
for the work breakdown structure, which in turn dictates units of planning,
scheduling, and budget; inter team communication channels; configuration
control and file system organization; integration and test plans and procedures;
and even minutiae such as how the project intranet is organized and how many
team picnics there are
A side effect of establishing the work breakdown structure is to freeze some
aspects of the software architecture. A group that is responsible for one of the
subsystems will resist having its responsibilities distributed across other
groups.
c. The Architecture Inhibits or Enables a System's Quality Attributes
Whether a system will be able to exhibit its desired quality attributes is
substantially determined by its architecture.
If high performance is the criteria, the time-based behavior of elements
must be managed as well as the frequency and volume of inter-element
communication.
If modifiability is important, responsibilities are assigned to elements such
that changes to the system do not have far-reaching consequences.
If security is the issue, inter-element communication must be protected and
managed and information access by the components.
If scalability is needed in the system, the use of resources is carefully
localized to facilitate the introduction of higher-capacity replacements.
If the project needs to deliver incremental subsets of the system, inter-
component usage must be carefully managed.
If the elements of the system are required to be re-usable in other systems,
restrict inter-element coupling so that when an element is extracted, it does
,MSRITBANGALORE
not come out with too many attachments to its current environment to be
useful.
d. Predicting System Qualities by Studying the Architecture
It is possible to make quality predictions about a system based solely on an
evaluation of its architecture.
Architecture evaluation techniques such as the Architecture Tradeoff Analysis
Method support top-down insight into the attributes of software product
quality that is made possible by software architectures.
e. The Architecture Makes It Easier to Reason about and Manage Change
Software systems change over their lifetimes. They do so often and often with
difficulty.
Every architecture partitions possible changes into three categories: local,
nonlocal, and architectural.
A local change can be accomplished by modifying a single element.
A nonlocal change requires multiple element modifications but leaves the
underlying architectural approach intact.
An architectural change affects the fundamental ways in which the elements
interact with each other.
So an effective architecture is one in which the most likely changes are also
the easiest to make.
Reasoning about the architecture can provide the insight necessary to make
decisions about proposed changes.

f. The Architecture Helps in Evolutionary Prototyping
Once an architecture has been defined, it can be analyzed and prototyped as a
skeletal system. This helps in two ways:
The system is executable early in the product's life cycle. Its fidelity increases
as prototype parts are replaced by complete versions of the software.
A special case of having the system executable early is that potential
performance problems can be identified early in the product's life cycle.
Each of these benefits reduces the risk in the project.
g. The Architecture Enables More Accurate Cost and Schedule Estimates
Cost and schedule estimates are an important management tool to enable the
manager to acquire the necessary resources and to understand whether a
project is in trouble. Cost estimations based on an understanding of the system
pieces are, inherently, more accurate than those based on overall system
knowledge.
Each team will be able to make more accurate estimates for its piece than a
project manager will and will feel more ownership in making the estimates
come true.
,MSRITBANGALORE
3. Architecture as a transferable, re-usable model
The earlier in the life cycle re-use is applied, the greater the benefit that can be
achieved. While code re-use is beneficial, re-use at the architectural level
provides tremendous leverage for systems with similar requirements.
a. Software Product Lines Share a Common Architecture
A software product line or family is a set of software-intensive systems
sharing a common, managed set of features that satisfy the specific needs of a
particular market segment or mission and that are developed from a common
set of core assets in a prescribed way.
Chief among these core assets is the architecture that was designed to handle
the needs of the entire family.
Similar to other capital investments, the architecture for a product line
becomes a developing organization's core asset.
b. Systems Can Be Built Using Large, Externally Developed
Elements
One key aspect of architecture is its organization of element structure,
interfaces, and operating concepts.
The most significant principle of this organization is interchangeability.
When the components that are candidates for importation and re-use are
distinct subsystems that have been built with conflicting architectural
assumptions, unanticipated complications can increase the effort required to
integrate their functions.
c. It Pays to Restrict the Vocabulary of Design Alternatives
As useful architectural patterns and design patterns are collected, it becomes
clear that computer programs can be combined in more or less infinite ways.
Voluntarily restricting ourselves to a relatively small number of choices when
it comes to program cooperation and interaction has tremendous benefits.
d. An Architecture Permits Template-Based Development
An architecture embodies design decisions about how elements interact that,
while reflected in each element's implementation, can be localized and written
just once.
Templates can be used to capture in one place the inter-element interaction
mechanisms.
,MSRITBANGALORE
e. An Architecture Can Be the Basis for Training
The architecture, including a description of how elements interact to carry out
the required behavior, can serve as the introduction to the system for new
project members.
UNIT2
ArchitecturalStyle
An architectural style consists of a set of component types (e.g., process, procedure,
objects, and servers), a set of connectors (e.g., data streams, sockets) that mediate
communicationamongcomponents.Italsoincludesasetofconfigurationrules.Thiscould
,MSRITBANGALORE
be in the form of some topological constraints that determine allowed compositions of
elements.Forexample,acomponentmaybeconnectedtoatmosttwoothercomponents.
Overall,theyprovideaframeworkonwhichtobasedesign.
LISTOFARCHITECTURALSTYLES
1.PIPEANDFILTER
2.DATAABSTRACTIONANDOBJECTORIENTATION
3.EVENTBASEDIMPLICITINVOCATION
4.LAYEREDSYSTEMS5.INTERPRETERS
6.BLACKBOARDANDREPOSITORY
7.PROCESSCONTROL
8.HETROGENEOUSARCHITECTURES
1.PIPEANDFILTER
NODESREPRESENTCOMPONENTS
ARCSCONNECTORS
VOCABULARYOFCOMPONENTSANDCONNECTORSWITHCONSTRAINTS
MARYSHAWGARLAN
CONSTRAINTSAREMAINLYWITHLOGICONWHICHAPPLICATIONWORKS.
BOUNDARIESOFSTYLESOVERLAP
COMPONENTSARECOMPUTINGELEMENTSFILTERS
CONDUITSFORSTREAMS
CONNECTORS
INVARIENTS
1.FILTERSAREINDEPENDENTENTITIES
2.FILTERSDONOTKNOWTHEIDENTITIESOFUPSTERAMANDDOWNSTREAMFILTERS.
INVARIENTSOFPIPES
1.DEGENERATE:PROCESSESINONESHOTANDDATAISHANDLEDASASINGLEENTITY
,MSRITBANGALORE
(BATCHSEQUENTIAL)ANDPROGRAMSAREWRITTENINUNIX.
2.UNIXPROVIDESRUNTIMEMECHANISMSFORIMPLEMENTINGPIPES.
TRADITIONALCOMPILERSAREPIPESANDFILTERS
1.LEXICALANALYSIS
2.PARSING
3.SEMANTICANALYSIS
4.CODEGENERATION
ADVANTAGES:
1.DESIGNERUNDERSTANDSOVERALLINPUTANDOUTPUTPROPERTIES.
2.SUPPORTSREUSE.
3.EASYENHANCEMENTOFSYSTEM.
4.SUPPORTSTHROUGHPUTANDDEADLOCKANALYSIS.
5.SUPPORTSCONCURRENTEXECUTION.
DISADVANTAGES:
1.OFTENLEADSTOBATCHSEQUENTIALPROCESS(OPPOSITEOFINCREMENTALPROCESS).
2.NOTGOODATINTERACTIVEAPPLICATIONS.
3.PROBLEMOFHANDLINGINCREMENTALUPDATES.
4.DIFFICULTYINMAINTAININGCORRESPONDANCEBETWEENTWOSEPARATEBUTRELATED
STREAMS.
5.PARSINGANDUNPARSINGISREQUIREDFORFILTERSSOTHATWRITINGCODEFOR
FILTERSISDIFFICULT.
DATAABSTRACTIONANDOBJECTORIENTATION
1.DATAREPRESENTATIONSANDOPERATIONSAREEMBEDDEDINOBJECTS.
2.OBJECTSARECOMPONENTSWHICHPRESERVESINTEGRITYOFREPRESENTATION.
3.OBJECTSINTERACTTHROUGHFUNCTIONINVOCATIONS.
4.REPRESENTATIONSAREHIDDENFROMOTHEROBJECTS.
INVARIANTS:
1.OBJECTSTOBECONCURRENTTASKS
2.OBJECTSHAVEMULTIPLEINHERITANCES.ADVANTAGES:
1.IMPLEMENTATIONCANBECHANGEDWITHOUTAFFECTINGOTHEROBJECTS.
2.DECOMPOSITIONOFPROBLEMISEASY.
,MSRITBANGALORE
DISADVANTAGES:
1.FORONEOBJECTTOINTERACTWITHANOTHEROBJECTTHEYSHOULDKNOWTHEOBJECT
IDENTITIES.
2.IFTHEOBJECTIDENTITYCHANGES?
Eventbased,ImplicitInvocationArchitecturalStyle
This is one of the more broadly accepted architectural styles. This architectural style is
characterized by the style of communication between components. Rather than invoking a
procedure directly or sending a message a component announces, or broadcasts, one or
moreevents.Thecomponentsinthisstyleareindependentreactiveobjects(orprocesses).
These components have interfaces that provide a collection of procedures/methods and a
set of events that it may announce. Some objects register interest in certain events and
other objects that would signal those events. The automatic method invocation acts as
connectors, by providing the binding between event announcements and
procedure/method calls. The topologies are arbitrary in this style, with implicit
dependenciesarisingfromeventannouncementsandregistrations.
An example of this style can be seen in some Integrated Development Environment (IDE)
wheretheEditorannouncesithasfinishededitingamodule,andthecompilerregistersfor
suchannouncementsandautomaticallyrecompilesmodule.Anotherexampleinthesame
context is where the Debugger announces it has reached a breakpoint, editor registers
interestinsuchannouncementsandautomaticallyscrollstorelevantsourceline.
Thereareseveraladvantagesassociatedwiththisstyle.Itprovidesstrongsupportforreuse,
becausenewcomponentscanbepluggedintothesystembyregisteringitforevents.Italso
affords easy maintenance, because we can add and replace components with minimum
affectonothercomponentsinthesystem.
Thereareafewdisadvantageswiththissystem.Firstamongthemisthelossofcontrol.For
example, when a component announces an event, it has no idea what components will
respondtoit.Itcannotrelyontheorderthatthesecomponentswillbeinvoked.Norcanit
tellwhentheyarefinished.Thenondeterministicnatureoftheexecutionsequencemakes
ensuringcorrectnessdifficult,becauseitdependsoncontextinwhichinvoked.Alsoyoucan
have unpredictable interactions. Another issue is that exchange of data can require use of
globalvariablesorsharedrepository.Thismeansthatthetaskofresourcemanagementcan
becomeachallenge.
LayeredSystems
Layeredsystemshaveahierarchicalsystemorganization.Wecanthinkofalayeredsystem
as a multilevel clientserver. Each layer acts as a server, i.e., service provider to layers
above.Italsoactsasaclient,.i.e.,itisaserviceconsumeroflayer(s)below.
,MSRITBANGALORE
Eachlayerexposesaninterface(e.g.,APIorprotocol)tobeusedbylayeraboveit.
ApopularexampleofalayeredsystemistheOSISevenLayermodelshownbelow
Thegenericstructureofalayeredsystemlookslikethis:
Heretheclienttothesystemortheusercaninteractonlywiththetopmostlayer.Request
from the client/user travels down each layer, till reaches the bottommost layer. where
somefunctionisperformed,andtheresultsoftheserviceorfunctionbubblesupinreverse
order.
,MSRITBANGALORE
The advantages of the layered system are that it breaks down complex problem into
incremental steps. Since interaction between layers is restricted to its adjacent layer,
systems that use the layered style are usually easy to Modify. Also, because the style
enforcesstandardlayerinterfaces,reusabilityoflayersisenhanced.
The disadvantages of the layered system are that it is not suitable for all systems. It is not
always easy to decompose a system into clean layers. Another issue is because
communication can take place only between adjacent layers, data has to flow through
severallayerscausingperformanceissues.
,MSRITBANGALORE
DatacenteredSystems
Adatacenteredsystemisoneinwhichalldataismaintainedinacentralstore,sometimes
calledarepository,andthereexistsacollectionofexternal,independentcomponentsthat
operateonthedatainthestore.
Therearetwosubcategoriesunderthisstyle.
FirstistheTraditionaldatabase,sometimescalledrepositories.Herethedataispassiveand
independent components control the manipulations of the data store. Here, types of
transactionstriggerselectionofprocessestoexecute
Anothersubcategory is called Blackboard. Here the data is quasiactive, i.e., the data store
informstheclientsthatinterestedinchanges.Thecurrentstateofthecentraldatastructure
triggerscomputationsintheindependentcomponents.
Blackboard
TheblackboardarchitecturalstyleoriginatesinworkintheArtificialIntelligencecommunity.
Hearsay II, the first continuous speech understanding systems developed in the 1970s by
Erman,HayesRoth,Lesser,andRajReddyatCarnegieMellonUniversityusedthisstylefirst.
We can understand the working of this style by imagining a group of specialists work
cooperatively to solve a problem, using a blackboard as the workplace for developing the
solution. The problem and initial data are written on the blackboard. The specialists watch
the blackboard, and when a specialist finds sufficient information on the board to make a
contribution,herecordshiscontributionontheblackboard.
This style is useful in an immature domain in which no closed approach to a solution is
knownorfeasible,andtosolveitrequiresmultipledistinctkindsofexpertise.Sincethereis
no deterministic algorithm, there are always many options for execution sequence. Also
thereisagreatdealofuncertainty.i.e.,thedomainsuffersfromerrorandvariabilityinboth
inputdataandknowledge.BlackboardstylecanbeusedwhereBesteffortorapproximate
solutionisgoodenough,becausethisisbetterthannosolution.
Since this style will likely be used in an immature domain, experimentation in algorithm
necessary.Thatmeansthatallthemoduleswithinthesystemshouldbeexchangeable.
The solution this style proposes is to have a collection of independent program working
cooperativelyonacommondatastructure.Eachprogramisaspecialistthatsolvesapartof
theproblem.Theydonotinteractwitheachother.Anothercharacteristicisthatthereisno
predetermined sequence of operation. At any point of time, the current state of data
determines what happens. There will be a central control component that evaluates state
andcoordinatesthespecialistmodules.
,MSRITBANGALORE
We have to view each step as a problemsolving process, where partial solutions are
constantly combined, changed or rejected. The solution space is organized into levels of
abstraction.
StructureinBlackboardStyle
There are three components: Blackboard data structure, Knowledge sources, and Central
Control.
The Blackboard data structure stores the entire state of problem solution. The data
structure is hierarchical and nonhomogeneous. The knowledge sources are separate,
independent subsystems thatsolvespecific aspectsof theoverallproblem. The knowledge
sources do not communicate directly. They can only read and write from the blackboard.
TheControlcomponentrunsaloopthatmonitorschangeontheblackboarddatastructure
and decides what to do using some strategy to make knowledge sources respond
opportunistically.
Benefits
Thisstylesmajorbenefitisthatitallowsforexperimentation.Itallowsdifferentalgorithms
to be tried, and, different control heuristics to be used. The positive side effect of the
knowledgesourcesnotcommunicatingdirectlyisthatthisstylesupportschangeabilityand
maintainabilityverywell.
Disadvantages
Sincethestyleisnondeterministicinnature,thesystembecomesdifficulttotest.Also,the
style does not guarantee a good solution. Often in implementations there is difficulty of
establishingagoodcontrolstrategy.Also,thestyleisbasicallyisnotveryefficientbecause
there are a lot of computational overheads. The development effort needed is also very
high,whichismainlyduetotheillstructuredproblemdomains.
,MSRITBANGALORE
CASE STUDY
1. KWIC :
Reasons for using kwic are
MOTIVATIONFORCHANGE
1.CHANGEINALGORITHM
2.CHANGEINDATAREPRESENTATION
3.ENHANCEMENTTOFUNCTION
4.PERFORMANCESPACEANDTIME
5.REUSE
KEYWORDINCONTEXT(KWIC)
examplecomponentschosenare
INPUT
CIRCULARSHIFT
ALPHABETIZER
OUTPUT
exampleconnectorschosenare
DMA
SUBPROGRAMCALL
SYSTEMI/O
Thearchitecturalstylesusedare
A.MAINPGM/SUBROUTINEWITHSHAREDDATA
1.FUNCTIONALDECOMPOSITIONWITHSHAREDACCESSTODATA
2.DECOMPOSITIONTHATHIDESDESIGNDECISIONS
REUSEDIFFICULT
B.ABSTRACTDATATYPE
DECOMPOSITIONEACHMODULEPROVIDESANINTERFACEWHICHPERMITSOTHER
COMPONENTSTOACCESSDATABYINVOKINGPROCEDURESINTHATINTERFACE
NOTSUITEDFORFUNCTIONALENHANEMENTSCHARACTER
CIRCULARSHIFT
ALPHABETICSHIFTIMPLICITINVOCATION
ACCESSDATAASALISTORSET
,MSRITBANGALORE
COMPUTATIONSAREINVOKEDIMPLICITLY(SELECTIVEBROADCAST)
DIFFICULTYINCONTROL
C.IMPLICITINVOCATION
COMPONENTANNOUNCESONEORMOREEVENTS,
OTHERCOMPONENTSREGISTERSBYASSOCIATINGAPROCEDUREWITHIT.
WHENEVENTISANNOUNCEDALLTHEPROCEDURESTHATWEREREGISTEREDAREINVOKED
D.PIPEANDFILTER
MODIFICATIONDIFFICULT
2.INSTRUMENTATIONSOFTWARE
A.OBJECTORIENTEDMODEL
OBJECTSWHICHARECHOSENAREASFOLLOWS
OSCILLOSCOPEOBJECT
WAVEFORM
MAXMINWAVEFORM
XYWAVEFORM
DISADVANTAGEISDIFFICULTYINFUNCTIONALITYPARTITIONING
LAYERED
Layerswhicharechosenareasfollows
HARDWARE
DIGITIZATION
VISIUALISATION
UI
MANIPULATION
DISADVANTAGEISBOUNDARIESOFABSTRACTIONDIFFICULT
PIPEANDFILTER
INCREMENTALTRANSFORMATIONOFDATACONTROLBYEACHFILTER
DISADVANTAGEISPOORPERFORMANCE
,MSRITBANGALORE
MODIFIEDPIPEANDCONTROL
INDIVIDUALFILTERINPUTCONTROL
componentmaybeconnectedtoatmosttwoothercomponents.Overall,theyprovidea
frameworkonwhichtobasedesign.
Interpreters:
In interpreter organization a virtual machine is produced in software. It includes
pseudoprogram and interpreter engine.
Pseudoprogram has:
Program itself
Interpreters analog of its execution state
Interpretation engine is characterized by
Definition of the interpreter
Current state of its execution
The following diagram shows the different components and connectors of an Interpreter
Architectural Style:

It is commonly used to build virtual machines that close the gap between the computing
engine expected by the semantics of program and the computing engine available in
hardware.
,MSRITBANGALORE
Process Control:
Unlike other models, Process control is characterized by both kinds of components involved
and relations that hold among them.
Continuous processes convert input materials to products with specific requirements by
performing operations on the input and intermediate products.
It has related terminologies which we call Process Control Paradigms:
Process variables: The values of the measurable properties of the system state
Controlled variables: the process variables that measure the output materials
Input variable: Process variable that measures the input
Manipulated variable: process variable whose value can be changed by the controller
Set point: the desired value for a controlled variable
Open-loop system:
If the input materials are pure, process is fully defined and the operations are completely
repeatable, then the process can run without surveillance.
Consider the following example where there is a hot-air furnace that uses a constant burner
setting to raise the temperature that passes through the furnace.

Closed Loop system:
Open loop assumptions are rarely valid in real world. More often the properties are monitored
and their values are used to control the process. Such systems are called closed-loop systems.
A home thermostat is a common example. The air temperature at the thermostat is measured
and the furnace is turned on or off as necessary to maintain the desired temperature.
,MSRITBANGALORE

There are two categories of closed-loop control:
Feedback Control - Adjusts the process according to the measurement of controlled variable

The important components are process variables, a sensor to obtain the controlled variable
from the physical output, the set point and a control algorithm.
Feed forward Control
Anticipates future effects on the controlled variable by measuring other process variables
whose values may be more timely
,MSRITBANGALORE

The components are essentially the same as in feedback controller except that the sensor
obtains the values of input or intermediate variables.
A software paradigm for Process Control
We think of software as algorithmic
Outputs are solely based on inputs
This model does not allow for external perturbations
This normal software model corresponds to open-loop systems
When operating condition of software systems are non predictable, pure algorithmic
model breaks down
When the execution of a software is affected by external disturbances, a control
paradigm should be considered
Process-control model can be used as architectural style for the software that controls the
continuous process.
Essential parts of that loop would be
Computational Elements: separate the process of interest from the control policy
Process definition: mechanism for manipulating variables
Control algorithm: to decide how to manipulate variables and models how
process variables reflect true state
Data Elements: updated process variables and sensors
Process variables: inputs, controlled and manipulated variables
Set point: reference value of controlled variable
Sensors: to obtain the value of process variables
The control loop paradigm
collects the information about actual and intended states of the process
Tunes process variables to drive the actual state towards intended state
The two computational elements separate issues about functionality from issues about
responses to external disturbances
,MSRITBANGALORE
We can bundle process and process variables ie. Process definition with process
variables and sensor will form one subsystem
Control algorithm and set point will form second subsystem
Other Architectures
Distributed processes
DS have created a number of organizations for multiprocessor systems
Some are characterized by their topological features such as ring and star
Others are characterized in terms of inter-process protocols used for
communication
Client server is the common distributed architecture
Sever provides services to other processes
Server does not know in advance the number or identities of the clients
But clients know the identity of server
Main program/subroutine organizations
Primary organization of the system mirrors the programming language in
which it is written
For languages without support for modularization, this often results in systems
organized around main program and a set of subroutines
Main program acts as driver for subroutine providing control loop to sequence
through in an order
Domain-specific architectures
These are reference architectures for specific domains
They provide organizational structures tailored to a family of applications such
as avionics, vehicle management systems
It is possible to increase the descriptive power of the system by these domain
specific architectures
Sometimes an executable system can be automatically or semi automatically
generated by these descriptions
State transition systems
A common organization for many reactive systems
They are defined in terms of a set of states and transitions
Heterogeneous Architectures
While it is important to understand nature of individual styles, most systems use combination
of architectural styles. There are three ways to combine styles:
One way is through hierarchy.
A component organized in on architectural style may have an internal structure
developed completely using other style Unix pipes
Even connectors too can be hierarchically decomposed
Second way is to allow single component to use mixture of connectors repository through
interpreter style, other components through pipes
Third way elaborate one level in different architectural style.
,MSRITBANGALORE
MobileRobotics
Mobile robotics refers to any system that controls a manned or partially manned vehicle,
like,Car,submarine,spacevehicle,etc.Thesoftwaretocontroltherobotwillgetinputfrom
externalsensorsandwillcontroltheactuators,usuallyinrealtime,tocontrolthemotionof
therobotorsometoolsthatispartoftherobot.Animportanthigherlevelfunctionwillbe
toplanthefuturepathoftherobot.
There arevariouscomplicatingfactorsin theperformanceofthe tasks,like theremight be
obstaclesmayblockthepath,orthesensorinputmightbeimperfect.Therobotmightrun
outofpowerorfuel.Itmightbedifficulttoassuretheaccuracyinmovement,probablydue
to some slippage of the wheels, etc. Some robots might to have to perform manipulation
withhazardousmaterial.Unpredictableeventsmightleadtoneedforrapidresponse.
Before evaluating the solutions that use different architectural style, let us specify the
criteriabywhichtoevaluatethem.
Requirement #1: The architecture must accommodate deliberative and reactive behavior.
Therobothastocoordinatetheactionsitdeliberatelyundertakestoachieveitsdesignated
objective(e.g.,collectasampleofrocks)withthereactionsforcedonitbytheenvironment
(e.g.,avoidanobstacle).
Requirement #2: The architecture must allow for uncertainty. Never will all the
circumstances of the robot's operation be fully predictable. The architecture must provide
the framework in which the robot can act even when faced with incomplete or unreliable
information(e.g.,contradictorysensorreadings).
Requirement #3: The architecture must account for the dangers inherent in the robot's
operation and its environment. By incorporating consideration of fault tolerance (R3a),
safety (R3b), and performance (R3c) attributes, the architecture must help in maintaining
theintegrityoftherobot,itsoperators,anditsenvironment.Problemslikereducedpower
supply,dangerousvapors,orunexpectedlyopeningdoorsshouldnotspelldisaster.
Requirement #4: The architecture must give the designer flexibility. Application
development for mobile robots frequently requires experimentation and reconfiguration.
Moreover,changesintasksmayrequireregularmodification.
One thing to note of course is that the priority of these requirements will vary with the
complexity of task and the unpredictability of its environment. For example, if the robot is
tooperateinMars,faulttolerancebecomesveryimportant.
ThefirstsolutionwewilllookatusestheControlLoopparadigm.
,MSRITBANGALORE
The first requirement we will use evaluate the solution is the need for deliberate and
reactive behavior. The simplicity of the paradigm makes it a good solution for handling
deliberate behavior. By the same token, the simplistic nature of the solution makes it very
unsuitable in unpredictable environment. The control loop paradigm makes an implicit
assumption that the continuous changes in environment require continuous reaction. But
robots would face discrete events. So, it is very difficult with this paradigm to switch
betweenbehaviormodesofhandlingdeliberateandreactivebehavior.
The next requirement is the allowance for uncertainty. In this paradigm uncertainty is
resolved by reducing unknowns through iteration, which is basically a trial and error
process.Ifmoresophisticatedstepsareneeded,thisarchitectureoffersnoframework.
The third requirement has to do with handling dangers in the operations and in the
environment. The control loop style fares well in this criterion. Fault tolerance and safety
areenhancedbythesimplicityofthearchitecture.
The last requirement of flexibility is also met by this style. Major components, like the
supervisor,sensors,andactuatorsareseparatedandcanbereplacedindependently.More
refinedtuningmusttakeplaceinsidethemodules.
To summarize, this architectural style might be appropriate for simple robotics, as it can
handle only a small number of external events. Clearly this is not really for complex
decompositionoftasks.
,MSRITBANGALORE
ThenextstylewewilllookatistheLayeredarchitecture,whichhasbeenusedasthebasis
forarchitectureofTerregatorandNeptunemobilerobots.
Let uslook atthe different layershere.Thefirst layerperforms therobot control routines,
which includes moving the motors, and other tools. This layer will read the sensor inputs
that will sense the relevant facets of the environment, like temperature, vision, etc. The
second layer will perform the function of sensor interpretation, which is analysis of data
from the various sensors. The third layer is the sensor integration layer, which performs
combined analysis of different sensor inputs. The next layer above is concerned with
maintainingtherobot'smodeloftheworld.Layerfivemanagesthenavigationoftherobot.
Layersixwillscheduletherobot'sactions.Layersevenwillplananddealwithproblemsand
replanning.Thetoplevelprovidesuserinterfaceandoverallsupervisoryfunctions.
Evaluationofthearchitecturalstyle:
Thefirstcriteriawewilllookatarethesupportfordeliberateandnondeliberateorreactive
behavior. Thisstyle sidesteps some of the problemsencountered with thecontrol loop, by
defining more components to which the required tasks can be delegated. It also indicates
the concerns that must be addressed (e.g., sensor integration). It also defines abstraction
levels(e.g.,robotcontrolvs.navigation)toguidethedesign.Buttheproblemisthatlayers
suggestthatservicesandrequestsarepassedbetweenadjacentcomponents,whicharenot
practical.Datarequiringfast reactionmay have tobe sentdirectly from thesensorsto the
,MSRITBANGALORE
problemhandling agent at level 7, and the corresponding commands may have to skip
levels to reach the motors in time. Another problem is that the layered architecture does
notseparatethetwoabstractionhierarchiesthatactuallyexistinthearchitecture.Wehave
the data hierarchy is from layer 1 through 4, with raw sensor input, interpreted and
integrated results, and finally the world model is built. The control hierarchy starts at the
topmostlayerandgoesdownthroughlayers7,6,5,andthendirectlytolayer1.
The second requirement of resolution of uncertainty is handled very well here. The
abstraction layer addresses the need for managing uncertainty. What is uncertain at a
lowest level may become clear in the higher layers. The conflicting sensor data can
introduceambiguity,but,thecontextembodiedintheworldmodelcanresolveit.
The third requirement of Fault Tolerance is addressed partly by this architecture. The
abstractionlayeraddressestheneedforfaulttoleranceandpassivesafety,whenyoustrive
not to do something. Data and commands are analyzed from different perspectives. This
style particularly allows us to incorporate many checks andbalances, which is essential for
satisfying this requirement. But, active safety poses a problem. When you have to do
somethingratherthanavoiddoingsomethingwouldrequirethecommunicationpatternbe
shortcircuited, which would violate the constraint in the layered architectural style of
allowingonlyadjacentlayerstocommunicatewitheachother.
The last requirement of flexibility is not met here, because of the tight coupling between
layers.Itisdifficulttomakereplacementandadditionofcomponentsduetothat.Another
issueisthattherelationshipsbetweenthelayersarecomplex.
In sum, positive aspect is that the abstraction levels defined by the layered architecture
provide a framework for organizing components. The framework succeeds because it is
precise about the rolesof the different layers. But, there are major drawbacks in this, too.
The model breaks down when taken to the greater level of detail demanded by an actual
implementation. Also, the communication patterns in a robot are not likely to follow the
orderlyschemeimpliedbythearchitecture.
,MSRITBANGALORE
The next architectural style we will evaluate is the Task Control Architecture (TCA) which
uses implicit invocation. Taskspecific modules communicate through API library that
accessesageneralpurposereusablecentralcontrolmodule.Controliscentralizedbutdata
andproblemsolvingisdistributed.
TCA is based on a hierarchy of tasks called task trees, which are directed at one or more
tasks registered to handle them. The parent tasks will initiate subtasks, which will be the
childtasks.Thetasktreesalsoallowsforspecifyingtemporaldependenciesbetweentasks,
allowingselectiveconcurrency.Ifanexceptionoccurs,thendynamicreconfigurationoftask
treescanbedoneatruntime.
Threeimportantfeaturesofthisstylemakeitidealforthisdomain.Certainconditionscause
the execution of an associated exception handler. Exceptions override the currently
executingtaskinthesubtlerthatcausestheexception.Theyquicklychangetheprocessing
mode of the robot and are thus better suited for managing spontaneous events (such as a
dangerous change in terrain) than the feedback loop or the long communication paths of
thepurelayeredarchitecture.
AnotherfeatureiscalledWiretapping,whichallowsforinterceptionmessages.Forexample,
amodulewiretapcertainmessagestoperformsafetychecksofoutgoingcommands.
ThethirdfeatureiscalledMonitors,whichallowsmodulestoreadinformationandexecute
actionsifthedatafulfillacertaincriterion.Thisfeatureallowsforhavingspecialistmodules
that will handle faulttolerance in the system that will supervise the system. For example,
one module can monitor the battery levels, and if it falls below a threshold, it can take
correctiveaction,likeissuingorderstogotobasestationtochargethebatteries.
Let us now look at how this architectural style performs in the four criteria we had seen
earlier.
The first requirement was deliberative and reactive behavior. The separation of action and
reaction in the task trees by providing for explicit support for exceptions provides strong
supportforthisrequirement.TCAexceptionhandlingallowserrorrecoveryalgorithmstobe
added without modifying/complicating the original algorithms (i.e., provides program
extensibilitythroughincremental,modularadjustments).TheothertwofeaturesoftheTCA,
wiretappingandmonitors,helpsinhavingdedicatedmodulesthatcanhandleemergencies.
Another strong characteristic of this style is that the style provides explicit support for
concurrency. But, in practice the parallelism might be limited by the capabilities of the
centralserver.Anothernegativeistherelianceonacentralcontrolpointcanbeaweakness.
Although the second requirement of dealing with uncertainty is not supported explicitly in
themodel.But,itispossibletodothisthroughtasktreesandexceptions.
The third requirement has to do with handling dangers in the operations and in the
environment.Exceptions,wiretappingandmonitorsworkstowardsperformance,safetyand
,MSRITBANGALORE
fault tolerance. Also, fault tolerance by redundancy is achieved by allowing multiple
handlersforsamesignalconcurrently.
The last requirement of flexibility is well supported by implicit invocation, which allows
incrementaldevelopmentandreplacementofcomponents.Itisusuallysufficienttoregister
new handlers, exceptions, wiretapping and monitors with central control, and the existing
componentsarenotaffected.
So, what we find is that the TCA architecture, along with implicit invocation offers a
comprehensive set offeatures forcoordinatingtasksofrobot based on both expected and
unexpected events. It allows modules to focus on independent separate tasks. TCA also
provides better support for autonomous behavior of parts than layered architecture.
Although the implementation of this style is not very straightforward, it is certainly
appropriateforcomplexroboticprojects
,MSRITBANGALORE
ThelastarchitecturalstylewewillevaluateistheBlackboardarchitecturestyle,whichwas
used in the Navlab project (computercontrolled vehicles for automated and assisted
driving).
ThevariouscomponentsinthesystemaretheCaption,whichactsastheoverallsupervisor.
Then you have the map navigator, which performs highlevel path planning. There is also
the Lookout for monitoring the environment. The Pilot acts as the lowlevel path planner
and motion controller. Lastly, there is the Perception subsystem which gets input from
multiplesensorsandintegratesitintoacoherentinterpretation.
Firstrequirementistheneedtohandlebothdeliberateandreactivebehavior.Components
interactviasharedrepository,somultipleagentscandealwithsameevent.So,wecanhave
one agent that deals with deliberate behavior. At the same time the Lookout can at the
same time be monitoring the environment, and can initiate reactive behavior, when the
statechanges.Onedifficultywiththisarchitectureisthatallcontrolflowhastobecoerced
tofitthedatabasemechanism,evenundercircumstanceswheredirectinteractionbetween
componentswouldbemorenatural.
Theallowanceforuncertaintycanbehandleddirectlybytheblackboard,whichcanresolve
conflictsanduncertainty.
,MSRITBANGALORE

Case Study Cruise Control
Booch and Others defined the problem as:
A Cruise-control System that exists to maintain the speed of the car, even over varying terrain
The hardware is as follows:

Problems with the original definition:
Does not clearly state the rules for deriving outputs from inputs
Boochs dataflow diagram fails to answer some questions
Problem statement says o/p is a value for throttle setting
Actually, It is change in the throttle setting
Current speed is not explicit in the statement
If it is addressed, then throttle setting is appropriate
Also specifies, millisecond clock
Used only to determine the current speed
Number of clock pulses between wheel pulses are counted
Problem is over specified in this respect
A slower clock is sufficient and requires less computing
Further, there is no need to use single clock for the entire system
Modified Definition is as follows:
Whenever the system is active, determine the desired speed, and control the engine
throttle setting to maintain that speed
Control Loop architecture is appropriate when the software is embedded in a physical system
that involves continuing behavior especially when the system is subject to external
perturbations.
These conditions hold in the case of cruise control the system is supposed to maintain the
constant speed in automobile despite variation s in terrain, vehicle load, air resistance etc.
Here, Computational Elements
,MSRITBANGALORE
Process definition: The process receives the throttle setting and control the
speed of the vehicle
Control Algorithm: Models the current speed from wheel pulses, compares it
with the desired speed and changes the throttle setting.
Data Elements:
Controlled Variable current speed
Manipulated Variable throttle setting
Set point desired speed
Sensor
The restated control task divides the problem into two sub problems:
Interface with the driver
Control Loop
First task :
model current speed from wheel pulses. The model could fail if the wheels spin
If the pulses are taken from the drive wheel and is spinning, the cruise control would
keep the wheel spinning, even if the vehicle stops moving.
If the pulses are taken from nondrive wheel, and if drive wheel is spinning, the
controller will act as if the current speed is too slow and continually increase the
throttle setting.
Further, there is no a full control authority over the process
In this case, the only manipulated variable is throttle. If the automobile is
coasting faster than the desired speed, the controller is powerless.
The control Architecture:

The controller receives two inputs
,MSRITBANGALORE
Active/inactive toggle: indicates whether the controller is in charge of throttle
Desired speed: needs to be valid only when the vehicle is under automatic
control
All these should be either state or continuously updated data, so that all lines represent
data flow
Controller is implemented as a continuously evaluating function
Several implementations are possible simple on/off control, proportional control etc
The set-point calculation has two parts:
Determining whether or not the automatic system is active
Determining the desires speed for use by controller
Some inputs in the defn capture state and others capture events.
However, to work with the automatic controller, everything it depends on should be
same
Therefore, transitions are used between states.

The above figure shows the state machine for activation.
System is completely off when engine is off
There are 3 inactive states and 1 active state
No set-point is established in the first inactive state
Set-point is to be remembered in the remaining two
The active/inactive toggle input of the control system is set to active when this state
machine is in active state
Steps to determine the desired speed
Only current value of the desired speed is needed
Whenever the system of off, set-point is undefined
Whenever the system is switched on
Set-point will take the value from current speed modeled by wheel pulses
Driver also has a control that inc/decr set-point value by a set amount
Event Effect on desired speed
,MSRITBANGALORE
Engine/system off Set to undefined
System on Set current speed using esti. from wheel pulses
Increase speed Incr. desired speed by constant
Decrease speed Decr. Desired speed by a constant
This is the event table for determining the set point.
Complete Cruise Control System

All the objects of Boochs design have clear roles
The shift raises a number of questions which were slighted in the early design
The separation of process from control concerns led to explicit choice of control
discipline
The limitations also became clear possible inaccuracies in the current speed model
and incomplete control at higher speed.
,MSRITBANGALORE
UNIT3
UnderstandingQualityAttributes
Qualitymustbeconsideredatallphasesofdesign,implementation,anddeployment
Architectureiscriticaltotherealizationofmanyofthequalitiesofinterestinasystem,and
thesequalitiesshouldbedesignedinandevaluatedatthearchitecturallevel
Somequalitiesarenotarchitecturallysensitiveandattemptingtoachievethesequalitiesor
analyzeforthemthrougharchitecturalmeansisnotfruitful
Qualityattributesexistwithincomplexsystemsandtheirsatisfactioncanneverbeachieved
inisolation.
Qualityattributes
Qualityofthesystem
Businessquality
Qualityofarchitectureitself
qualitiesdiscernablebyobservingthesystemexecution
Availability
Performance
Security
Usability
functionality
qualitiesnotdiscernableatruntime:
Modifiability
Portability
Reusability
Integrabilityandtestability
,MSRITBANGALORE
Groupsofqualityattributediscussion
,MSRITBANGALORE
Allqualityattributesareanalyzedunderthefollowinggroupings
Source,stimulus,artifact,environment,responseandmeasureasindicatedbelow
Availability
Availabilitydealswiththefollowing
1.Failuresandfaults
2.Meantimetofailure,repair
3.Downtime
Source:internal,external
Stimulus:Faults:Omission,Crash,timing,responseandmeasureasindicatedbelow
Artifact:processors,channels,storage
Environment:normal,degraded
Response:logging,notification,switchingtobackup,restart,shutdown
Measure:availability,repairtime,requireduptime
,MSRITBANGALORE
Performance
Performancedealswiththefollowing
1.Eventarrivalpatterns
periodic
Stochasticandorsporadic(inrandomandorrecurring)
2.Eventservicing
3.latency
4.jitter
5.Throughput
Systemsperformancecanbesimulatedbyastochasticqueuingmodelofthesystem
Analyzeperformanceatthearchitecturallevelby:
Lookingatthearrivalratesanddistributionsofservicerequests
Processingtimes
Queuingsizes
Latency
Frequentlycompromisedastheotherqualitieshaveemergedasimportantcompetitors
Source:external,internal
Stimulus:eventarrivalpattern
Artifact:systemservices
Environment:normal,overload
Response:changeinmode?
Measure:latency,deadline,throughput,jitter,missrate,dataloss
Security
,MSRITBANGALORE
Securitydealswiththefollowing
1.Attackorthreat
2.Confidentiality
3.integrity
4.Assurance
5.Availability
Source:user/system,identified?
Stimulus:displayinfo,changeinfo,accessservices,denyservices
Artifact:services,data
Environment:online/offline,connected?
Response:logging,blockaccess,notification
Measure:time,probabilityofdetection,recovery
Modifiability
Itdealswithchangestakingplaceintheapplication
Source:developer,administrator,user
Stimulus:add/delete/modifyfunctionorquality
Artifact:UI,platform,environment
Environment:design,compile,build,run
Response:makechangeandtestit
Measure:effort,time,cost
Testability
Testabilitydealswiththefollowing
1.Probabilityoffaultdiscovery
2.Needtocontrolcomponents
,MSRITBANGALORE
3.Needtoobservecomponentfailure
Source:developer,tester,user
Stimulus:milestonecompleted
Artifact:design,codecomponent,system
Environment:design,development,compile,deployment,run
Response:canbecontrolledandobserved
Measure:coverage,probability,time
Usability
Usabilitydealswiththefollowing
1.Learning
2.Usingefficiently
3.Minimizingerrors
4.Adaptingtouserneeds
5.Increasingconfidenceandsatisfaction
Source:enduser
Stimulus:wishtolearn/use/minimizeerrors/adapt/feelcomfortable
Artifact:system
Environment:configurationorruntime
Response:provideabilityoranticipate
Measure:tasktime,numberoferrors,usersatisfaction
SUMMARYOEQUALITYATTRIBUTES:
AvailabilityUnexpectedevents,nonoccurrenceofexpectedevents.
ModifiabilityRequesttoadd/delete/change/varyfunctionality,platformquality
attributesorcapacity
Performanceperiodic,stochasticorsporadic
,MSRITBANGALORE
Securitytriestodisplay,modify,change/deleteinformation,accessorreduceavailability
tosystemservices
TestabilityCompletionofphaseofsystemdevelopment
UsabilityWantstolearnsystemfeatures,useasystemefficiently,minimizetheimpactof
errors,adaptthesystem,feelcomfortable.
BusinessQualities
BusinessQualitiesdealswiththefollowing
1.Timetomarket
2.Costandbenefit
3.Projectedlifetime
4.Targetmarket
5.Rolloutschedule
6.Integrationwithlegacy
7.ArchitecturalQualities
BusinessQualities
The business qualities are usually considerations of cost, schedule, market and marketing.
Like the System Quality attributes they are also ambiguous. So, we need scenarios like we
sawwithsystemqualities,toguideinthedesignprocess.
The various business qualities we will look at are: Time to market, Cost and benefit,
Projected lifetime of the system, Targeted market, Rollout schedule, and Integration with
legacysystems.
Timetomarketbecomesveryimportantwhenthereisseverecompetitivepressureorifthe
window of opportunity for introduction of system or product to the market is short. This
wouldresultinpressuretobuycommercialofftheshelf(COTS)productsorreuseelements
frompreviousprojects.Goodarchitecturecanenabletheabilitytoinsertordeployasubset
ofthesystembyusingtherightlevelsofabstractionindefiningtheelementsofthesystem.
Balancing cost and benefit is something architecture has to do. For example, architecture
relying on outofhouse technology will be more expensive. Similarly, highly flexible
architecture will bemore expensive to buildthan rigid architecture. But thebenefitwillbe
thatitwillbelesscostlytomaintainandmodify.
,MSRITBANGALORE
If a project has a long projected time, then the qualities of portability, scalability,
modifiability becomes very important. To assure these, one has to build extra layers for
these.Thiswouldincreasestimetomarket,butitwillbeworthit.
Targetedmarketwillhaveaheavyinfluenceonarchitecture.Inthecaseofgeneralpurpose
software, it will be the platform and feature set that will determine the size of potential
market, and portability and functionality is key here. If the effort is to attract large market
with collection of related products, then it would beneficial to design a productline
approach. In this the core system will be common, this will usually have to be designed
portable to different platform (hardware or operating system). Around the core layers of
specificsoftwarecanbeconstructed.
Rolloutschedulewillneedtobeconsideredifthesystemisplannedtobereleasedwithjust
the core functionality and more features will be released in different phases. So, flexibility
andcustomizabilitybecomesimportant.
Integrationwithlegacysystemscouldbeofhighmarketingimportance.So,architecturehas
to define appropriate integration mechanisms, and the constraints imposed by these have
tobeanalyzed.
,MSRITBANGALORE
QualitiesoftheArchitecture
These qualities are related directly to the architecture itself. Conceptual integrity is an
architecturalqualitythatreferstotheunderlyingthemeorvisionthatunifiesthedesignof
thesystematalllevels.
Architecture should also ensure correctness and completeness. This is essential to confirm
that all the functional requirements of the system are met, and quality attributes are
achievedasplanned.
Buildability is an architectural quality that allows a system to be completed by available
teams in a timely manner and also ensures that the system is open to certain changes as
development progresses. Architecture can help achieve buildability by paying attention to
how the system is decomposed into modules, and limiting dependencies between the
modules. The architect then has to assign these modules to appropriate development
teams. Limiting dependencies between the modules limits the dependencies between the
developmentteams,whichwillmaximizedevelopmentparallelism.
,MSRITBANGALORE

Security Tactics:
Tactics for achieving security can be divided into those concerned with resisting attacks,
those concerned with detecting attacks, and those concerned with recovering from attacks.

Resisting Attacks
Tactics for achieving security can be divided into those concerned with resisting
attacks, those concerned with detecting attacks, and those concerned with recovering
from attacks.
Authenticate users. Authentication is ensuring that a user or remote computer is
actually who it purports to be.
Passwords, one-time passwords, digital certificates, and biometric
identifications
Authorize users. Authorization is ensuring that an authenticated user has the rights to
access and modify either data or services.
Classes of users can be defined by user groups, by user roles, or by lists of
individuals.
Maintain data confidentiality. Data should be protected from unauthorized access.
encryption
Maintain integrity. Data should be delivered as intended
checksums or hash results
Limit exposure. Attacks typically depend on exploiting a single weakness to attack all
data and services on a host.
The architect can design the allocation of services to hosts so that limited
services are available on each host.
Limit access. Firewalls restrict access based on message source or destination port.
One configuration used in this case is the so-called demilitarized zone (DMZ).

Detecting an Attack
usually through an intrusion detection system
work by comparing network traffic patterns to a database.
Frequently, the packets must be filtered in order to make comparisons.
,MSRITBANGALORE
Recovering from Attacks
can be divided into those concerned with restoring state and those concerned with attacker
identification
The tactics used in restoring the system or data to a correct state overlap with those used for
availability
Special attention is paid to maintaining redundant copies of system administrative data such
as passwords, access control lists, domain name services, and user profile data.
The tactic for identifying an attacker is to maintain an audit trail.
An audit trail is a copy of each transaction applied to the data in the system together with
identifying information.
AchievingQualities:Tactics
An architectural tactic is a design decision that affects how well a software architecture
addressesaparticularqualityattribute.
A system design is a collection of decisions. Some ensure achievement of the
system functionality. A tactic is a design decision that influences the control of
a quality attribute response.
TacticsforAvailability
,MSRITBANGALORE
Availability is concerned with system failure and its consequences. The areas
of concern here are: detection of system failure, frequency of failure,
consequences of failure, how long a system is allowed to be out of operation
while handling failure, how failures can be prevented.
Availability: Fault Detection Tactics
Ping/Echo
Onecomponentissuesapingandexpectstoreceivebackanechowithinapredefinedtime.
If the echo is not received, it is assumed that the pinged component has failed and
corrective action has to be initiated. Positives of this tactic are that there is limited
interference of regular activities at the respondent side. An added bonus is that it
determines not just reachability, but also the roundtrip delay through the associated
networkpath.
Heartbeat
Inthistacticasubsystememitsasignal(theheartbeat)withafixedfrequencytoalistener.
Ifasignalisomitted,thenthesubsystemisassumedtohavefailedandcorrectiveactionwill
beinitiated.Theheartbeatsignalcancarrysomedata,too.So,thesubsystemwillsendout
datatobeprocessedwiththeheartbeatmessageatpredeterminedintervals.
Exceptions
Whenafaultisdiscoveredtherelevantsubsystemwouldraiseanexception.Thefaultscan
bedividebyzero,busandaddressfaults,illegalprograminstructions.
,MSRITBANGALORE
Availability: Tactics for Fault Recovery::Preparation and Repair
Voting
Accordingtothistactic,anumberofmoduleswillcomputethesamefunctionthatissentto
avoter.Ifnotallanswersareidentical,thenafaulthasoccurred.Thesystemmayalsotake
themajorityoftheanswersastherightanswer.
Thesedifferentmodulescanberunningondifferenthardware,couldhavebeendeveloped
byseparateimplementationteamstoachievetrueredundancy.Atypicalimplementationis
having threeversions of the modules.Thissystem is known asTripleModularRedundancy
(TMR).ManyspaceshipsandsatellitesystemsoftenuseTMR.SomeECC memoryalsouses
thistactic.
Active redundancy (hot restart)

All of the nodes (active or redundant spare) in a protection group receive and
process identical inputs in parallel, allowing the redundant spare(s) to maintain
synchronousstatewiththeactivenode(s).Recoveryandrepaircanoccurintime
measuredinmilliseconds.
Passive redundancy (warm restart)

In this tactic only the active node process input traffic, with the redundant spare(s)
receiving periodic state updates. Upon failure the system must ensure that the backup is
sufficiently fresh before resuming services.
,MSRITBANGALORE
Spare
A standby spare computing platform is configured to replace many different
failed components. The spare must be rebooted to the proper software
configurationandhaveitsstateinitializedwhenafailureoccurs.
Availability: Tactics for Fault Recovery:: Reintroduction

Shadow operation
Apreviouslyfailedcomponentmayberuninshadowmodeforashortperiodoftimeto
makesureitmimicsthebehavioroftheworkingcomponentsbeforerestoringittoservice
State resynchronization
This is an example of a Refinement tactic. On reintroduction, components must
have their states upgraded before returning them to service. As a refinement to
the Active Redundancy tactic, the State Resynchronization occurs organically, as
the active and standby components each receive and process identical inputs in
parallel. As a refinement to the Passive Redundancy (warm sparing) tactic, State
Resynchronizationisbasedsolelyonperiodicstateinformationtransmittedfrom
theactivecomponentstothestandbycomponents.
Checkpoint/rollback
Acheckpointistherecordingofaconsistentstatecreatedeitherperiodicallyorinresponse
tospecificevents.Whenafaultoccursthesystemcanberolledbacktothatstate.
,MSRITBANGALORE
Availability: Tactics for Fault Prevention

Removal from service
The removal of a component from service to undergo activities can sometimes mitigate
potential system failures. An example might be taking a component of a system out of
serviceandresettingthecomponentinordertoscrublatentfaultssuchasmemoryleaksor
fragmentation. This prevents accumulation of faults become serviceaffecting, resulting in
systemfailure.
Transactions
Transactionsarethebundlingofseveralsequentialstepsinwhichtheentirebundlecanbe
undoneatonce.
Processmonitor
This tacticenvisages a dedicated module thatmonitors for a fault ina process and deletes
thenonperformingprocessandcreatinganewinstanceofit.
,MSRITBANGALORE
Modifiability Tactics
Maintenance generally presents the major cost factor of the lifecycle of software systems.
Maintainability is the capability of the software product to be modified. The modifications
may include corrections, improvements or adaptations of the software to changes in
environment, and in requirements and functional specification. The ease with which a
softwaresystemcanaccommodatechangesiscontrolledbyModifiabilitytactics.
Modifiabilitytactics:Localizechanges
Maintainsemanticcoherence
This refers to the relationships among responsibilities in a module. This tactic makes sure
that all the responsibilities in a module are related and work together without excessive
reliance on other modules. A related subtactic is to abstract the common services. This is
relevant because modifications to a module that provide common services will need to be
madeonlyonceratherthanineachmodulewheretheservicesareused.
Anticipateexpectedchanges
Considering the set of envisioned changes when doing decomposition facilitated the
evaluationofassignmentofresponsibilitiestothesubsystems,withtheaimtominimizethe
effects of the changes. This tactic is especially difficult in practice because it is nearly
impossible to anticipate all possible changes that can be made during the lifetime of a
system.
Generalizethemodule
,MSRITBANGALORE
The goal of this tactic is for a module to compute a broader range of functions based on
input.Themoregeneralamodule,themorelikelythatrequestedchangescanbemadeby
adjustingtheinputlanguageratherthanbymodifyingthemodule.
Restrictchangeswithinreason
Thistacticappliesspeciallytoproductlinearchitectures,wherevariationcanhappenalong
manydifferentdimensions,somuchsothatitbecomesimpractical.So,thearchitecthasto
use good judgment and restrict changes within reason. For example, a variation point in a
product line may be allowing for a change of processor. In this case, a tactic might be to
restrictprocessorchangestomembersofthesamefamily.
Modifiabilitytactics:PreventRippleEffects
Hideinformation
Decomposition of the responsibilities for an entity into smaller pieces and choosing which
information to make private and which to make public is very critical in preventing ripple
effects. The tactic 'anticipate expected changes' is related to this, because the anticipated
changeswillhavetobeencapsulated.
Maintainexistinginterfaces
If other modules depend on the name and signature of an interface of a module,
maintaining this interface and its syntax allows other modules to remain unchanged.
Patterns toimplementthistacticinclude adding interfacesor adapterto modules. When a
moduleprovidessomenewserviceafteramodification,addnewinterfacestoexposethese
services while maintaining the old interfaces. Another pattern when other modules are
dependentonlyonthesignatureofthechangedmoduleisprovidingastub.
This tactic is going to work only if there is a syntactical relationship. If there is a semantic
dependency, quality of data or service dependency, resource usage/ or ownership
dependency,thesebreakdown.
Restrictcommunicationpaths
,MSRITBANGALORE
In any system if there are multiple data producers or multiple data consumers, the
dependencies will cause ripples when modifications have to be made. This tactic
recommendsrestrictthemoduleswithwhichagivenmodulesharesdata.
Useanintermediary
This tactic recommends us to insert an intermediary between dependent modules that
managesactivitiesassociatedwiththedependency.Forexample,ifthelocationofamodule
needs to be changed, the intermediary used will be a name server, so that the runtime
locationofthemodulecanbechangeddynamically
Modifiabilitytactics:DeferBindingTime
Thistacticallowschangeintimetodeploy,andalsoallowsnondeveloperstomakechanges
tothesystem.Deferringbindingtimewillofcoursecomeatthecostofrequiringadditional
infrastructuretosupportthelatebinding.
The tactic of Runtime registration supports plugandplay operation, but at an additional

overheadtomanagetheregistration.Amoreconstrainedvariantofthistacticistodothese
publish/subscriberegistrationatloadtimeinsteadofatruntime.
AfrequentlyusedmethodistouseConfigurationfiles,whichwillsetparametersatstartup
that will change the behavior of the system. Polymorphism allows late binding of method
calls. Component replacement allows load time binding. To allow runtime binding of
independentprocesses,adherencetodefinedprotocolsservesastherighttactic.
,MSRITBANGALORE
Performance tactics
The goal of performance tactics is to generate a response to an arriving event

within some time constraint. The arriving event can be a single event or a
stream of events. The event can be a message, expiration of a time interval,
detection of a state change, etc. Performance tactics control the time within
which a response is generated. Latency is the time between the arrival of an
event and the generation of a response.
There are two basic contributors to latency. The first contributor is resource consumption.
TheresourcesincludeCPU,persistentdatastores,networkcommunicationbandwidth,and
randomaccessmemory.Eventsgothroughaprocessingsequencewhichcontributestothe
overalllatencyoftheresponse.Thesecondcontributorisblockedtime.Thiscouldbedueto
contention for resources by competing subsystems. Another possibility of downtime, even
whenthereisnocontentionwhenresourcesgoofflineorthereissomefailureinthesystem
thatcausestheresourcestobecomeunavailable.Anothercauseforlatencycouldbedueto
dependencyonothercomputationbyothermodules.
Performance tactics come in three different categories. First category deals with resource
demandwhoseaimistoreduceresourcesrequiredtoprocessaneventstream.Thesecond
categorydealswithresourcemanagement,whoseeffortistoreducethenumberofevents
processed. The last category entails resource arbitration, which strives to control use of
resources.
,MSRITBANGALORE
PerformanceTactics:ResourceDemand
Thefollowingtwotacticsattemptstoreduceresourcesrequiredtoprocessaneventstream.
Herearethetactics.
Increasecomputationalefficiency
This can be done by improving algorithm efficiency at critical places or trade one resource
foranother.
Reducecomputationaloverhead
Anexampleofthistacticistoeliminateintermediaries,whichwillreducelatency.Notethe
conflictbetweenmodifiabilityandperformance.
Thefollowingtwotacticsattemptstoreducethenumberofeventsprocessed.
Manageeventrate
If the system was overengineered, then it might be possible to reduce event rate. An
examplemightbetoreducethefrequencyatwhichenvironmentalvariablesaremonitored.
Controlfrequencyofsampling
Anexampleofthisistosamplequeuedrequestsatlowerfrequency,whichwillresultinless
resourcesconsumed,butmightcausesomerequeststobelost.
Thefollowingtwotacticsattemptstocontroluseofresources
Boundexecutiontimes
Thisisnotaverygeneraltactic.Therecouldsomespecialcaseswhereitmightbepossible
tolimithowmuchexecutiontimeisusedtorespondtoanevent.
Boundqueuelengths
Liketheprevioustacticundersomespecialcircumstancesitmightbepossibletocontrolthe
maximumnumberofqueuearrivalstosaveonresources.
,MSRITBANGALORE
PerformanceTactics:ResourceManagement
If the demand for resources isnt controllable, they might be managed by these tactics to
manageresourcesmoreefficiently
Introduceconcurrency
Blockedtimecanbereducedifrequestscanbeprocessedinparallel.
Maintainmultiplecopiesofeitherdataorcomputations
Cachingisatacticinwhichdataisreplicatedthatwillresultinlesscontentiononresources.
Butthistacticwillnecessitatetacticstoperformsynchronizationofcopies.
Increaseavailableresources
Add additional or faster processors, memory, or faster networks can reduce latency. Of
course,thecostofincreasingresourceshastobeoffsetbythebenefitstheyprovide.
PerformanceTactics:ResourceArbitration
When there is contention for a resource, the resource must be scheduled. Competing
criteria for scheduling include optimal resource usage, request importance, minimizing the
number of resources used, minimizing latency, maximizing throughput, and preventing
starvationtoensurefairness.
Wewilllookatsomecommonschedulingstrategies
1.FIFO:Firstin/Firstoutisatacticthatcanbeusedifallrequestsareequal
2. Fixedpriority scheduling: Fixedpriority scheduling assigns each source of resource
requests a particular priority and assigns the resources in that priority order. The priority
mightbebasedonsemanticimportance,whereprioritiesareassignedtorequestcategories
statically.Anotherwaytodothisiscalleddeadlinemonotonic.Underthispolicytaskswith
shorterdeadlinesareassignedhigherpriori.Ratemonotonicpolicyisanothervariantwhere
taskswithshorterperiodsareassignedhigherpriority.
,MSRITBANGALORE
3. Dynamic priority scheduling: There are a couple of ways to perform dynamic priority
scheduling.Theroundrobinisafairschedulingmethod.Anotherwaytodoschedulingisto
giveprocessclosesttoitsdeadlineishighestpriority(earliestdeadlinefirst).
4.Staticscheduling:Inthisschedulewithpreemptionpointsandsequencearedetermined
offline.
,MSRITBANGALORE

Testability Tactics
The goal of tactics for testability is to allow for easier testing when an increment of software
development is completed.

since testing consumes such a high percentage of system development cost, anything
the architect can do to reduce this cost will yield a significant benefit.
Executing the test procedures requires some software to provide input to the software
being tested and to capture the output. This is called a test harness.
We discuss two categories of tactics for testing:
providing input and capturing output, and internal monitoring.
Input/Output
There are three tactics for managing input and output for testing.
Record/playback. Record/playback refers to both capturing information
crossing an interface and using it as input into the test harness.
information crossing an interface during normal operation is saved in some
repository and represents output from one component and input to another.
Separate interface from implementation. Separating the interface from the
implementation allows substitution of implementations for various testing
purposes.
Stubbing implementations allows the remainder of the system to be tested in
the absence of the component being stubbed.
Specialize access routes/interfaces. Having specialized testing interfaces
allows the capturing or specification of variable values for a component
through a test harness as well as independently from its normal execution.
Internal Monitoring
Built-in monitors. The component can maintain state, performance load, capacity,
security, or other information accessible through an interface.
Can be permanent interface to components or introduced temporarily
common technique is to record events when monitoring states have been activated.

Usability Tactics:
,MSRITBANGALORE
Two types of tactics support usability
runtime, includes those that support the user during system execution.
iterative nature of user interface design that supports the interface developer at
design time.

Runtime Tactics
During execution, the usability is enhanced by
the feedback to user about the system
Allowing user to issue commands: cancel, undo, aggr
According to Researchers in Human computer interaction:
User Initiative
System Initiatives
Mixed Initiatives
Our Usability scenario always combines first two to give last type of interaction
User Initiative the architect designs response similar to other functionality.
Must enumerate the responsibilities of the system in response
The user issues a cancel command
System must be listening to it
Command should be killed
Resources should be freed
Collaborating components must be informed to take necessary action
System Initiative rely upon a model
About the user
Task being undertaken by the user, or
System state itself
The system initiative tactics are those that identify the models the system uses to
predict either its own behavior or the user's intention.
this information will enable an architect to more easily tailor and modify those
models.
Tailoring and modification can be either dynamically based on past user behavior or
offline during development.
Maintain a model of the task. In this case, the model maintained is that of the task.
The task model is used to determine context
Maintain a model of the user. In this case, the model maintained is of the user.
It determines the user's knowledge of the system, the user's behavior in terms
of expected response time,
Maintain a model of the system. In this case, the model maintained is that of the
system.
It determines the expected system behavior

,MSRITBANGALORE
Design-time Tactics
User interfaces are typically revised frequently during the testing process.
the usability engineer will give the developers revisions to the current user interface
design and the developers will implement them.
This leads to a tactic that is a refinement of the modifiability tactic of semantic
coherence
Separate the user interface from the rest of the application.
Localizing expected changes is the rationale for semantic coherence.
the user interface is expected to change frequently both during the
development and after deployment
The software architecture patterns developed to implement this tactic and to
support the modification of the user interface are:
Model-View-Controller
Presentation-Abstraction-Control
Seeheim
Arch/Slinky
Relationship of Tactics to Architectural Patterns
An architect usually chooses a pattern or a collection of patterns designed to realize one or
more tactics. However, each pattern implements multiple tactics, whether desired or not.
Example: Active Object design pattern: The Active Object design pattern decouples method
execution from method invocation to enhance concurrency and simplify synchronized access
to objects that reside in their own thread of control.
The pattern consists of six elements:
a proxy, which provides an interface that allows clients to invoke publicly
accessible methods on an active object
a method request, which defines an interface for executing the methods of an
active object
an activation list, which maintains a buffer of pending method requests
scheduler, which decides what method requests to execute next
a servant, which defines the behavior and state modeled as an active object
future, which allows the client to obtain the result of the method invocation
The motivation for this pattern is to enhance concurrencya performance goal. Thus, its
main purpose is to implement the "introduce concurrency" performance tactic.
There are other tactics this pattern involves, however.
Information hiding (modifiability). Each element chooses the responsibilities
it will achieve and hides their achievement behind an interface.
Intermediary (modifiability). The proxy acts as an intermediary that will
buffer changes to the method invocation
Scheduling policy (performance). The scheduler implements some scheduling
policy.
,MSRITBANGALORE
The analysis process involves understanding all of the tactics, and the design process
involves making a judicious choice
UNIT4
LayersArchitecturalPattern
In the layer architecture, Application is decomposed into groups of subtasks in which each
groupofsubtasksisataparticularlevelofabstraction.

Context
The context in which one might consider this pattern is a large system that
requires decomposition. One way to decompose a system is to segment it into
collaborating objects. In large systems a first-cut rough model might produce
hundreds or thousands of potential objects. Additional refactoring typically
leads to object groupings that provide related types of services. When these
groups are properly segmented, and their interfaces consolidated, the result is
a layered architecture.
ProblemDescription
The dominant characteristic is a mix of high and low level issues, where high level
operationsrelyonlowerlevelones.Thereisalsonecessityforbidirectionalcommunication
flows.Portabilitybetweenplatformsisdesirable.Theexternalboundariesofthesystemare
specified,usuallyintermsoffunctionalInterfacesthatsystemmustadhereto.Alsobecause
ofthecomplexityofthehigherleveltasks,mappingofhighleveltasksontoplatformisnot
straightforward.
ForcestoBalance
There are always several forces to balance for the architect in this context. A force to
balance is that late changes to subsystems should not ripple through the system. The
interfaces should be stable, and probably some standards have to be followed. Another
forcetobalanceisthatsomesubsystemsshouldbeexchangeable.Theremightalsobethe
need to allow alternative implementations. The possibility of platform change (Operating
,MSRITBANGALORE
System or Hardware) might be there. Some systems might require runtime changes by
reconfiguration. Also, it may be necessary to build other systems that have same lowlevel
issues.
Whiledecomposingthesystemintolayers,similarresponsibilitiesshouldbegrouped.Atthe
same time each component should be coherent. If one component implements divergent
issues, its integrity is lost. So, an important force to balance is to resolve this potential
conflict between grouping and coherence. In many domains, there will be no standard
component granularity. Components will have to undergo iterative decomposition till we
havesimplecomponents.Anotherimportantforcetobalancewhendecidingonthenumber
of layers is that crossing component boundaries degrades performance. From the
development task point of view, the architect will have to subdivide the work among a
team.
Solution
The solution is to structure the system as a series of layers. We start at the lowest level
(layer1).Then,workourwayuptheabstractionladder,puttinglayerJonlayerJ1untilwe
reachthetoplayer,whichtheuserofthesystemwillinteractwithusually.
We have to ensure that most services provided by layer J are composed of services from
layerJ1.OfcourselayerJsservicesmaydependonotherserviceswithinLayerJ.
,MSRITBANGALORE
Dynamics
Scenario I (top-down requests)

Inthisscenario,clientoruserissuesrequesttolayerN.LayerNcallslayerN1for
supportingsubtasks.LayerN1providesthese,andalsocallslayerN2,andsoon
untillayer1isreached.Lowestlevelservicesareperformed.Ifnecessary,replies
arepassedbackupthechain.
Note that the layer J is at a higher level of abstraction than Layer J1. Map high
levelserviceontomoreprimitiveones.So,foreachrequestreceivedfromabove,
typicallyseveralrequestsaremadetolayersbelow.

Scenario II (only partial flow down)
Sometimes, a layer may be able to service the request, without making requests
lower down. An example is when you have a caching layer, requests sometimes
need not be sent down to layer 1. The issue in this case is the need in these
cachinglayerstomaintainstateinformation.
,MSRITBANGALORE
ScenarioIII(bottomupnotifications)
In this scenario, a chain of events start at the bottom most layer. An example might be in
the case of a device driver in layer 1 detects input. The device driver translates this into
internalformat,andnotifieslayer2,whichstartsinterpretingit,andnotifieslayer3.Process
continuesuptohighestlayer.
Variation in this scenario is when incoming notifications may be condensed into a bulk
notification.
ScenarioIV(onlypartialflowup)
Thisiswhenalayermaybeabletohandleanotificationwithoutforwardingit.
ScenarioV(communications)
ThisscenarioariseswhentwostacksofNlayers.Thelayersaretypicallyknownasprotocol
stacks. Here the top layer on one stack issues a request to send data. Subsequent layers
performtheirservicesandpassonthedata,untilithitslayer1.Dataistransmitted,andthe
reverseprocedureoccursonthereceivingside.
Implementation
1.Definetheabstractioncriterion
The criteria used might be the conceptual distance from platform or the degree of
conceptualcomplexity.Butusuallyitisamixofcriteria,suchasdistancefromhardwareat
lowerlevels,andconceptualcomplexityathigherlevels
2.Determinethenumberofabstractionlevels
Typically each abstraction level corresponds to one layer. But not in all cases would this
mapping from levels to layers be obvious. At this stage, we should also think about
tradeoffs.Toomanylayersmayimposeunnecessaryoverhead,andtoofewlayerscanresult
inpoorstructure.
3.Namelayers,andassigntaskstothem
,MSRITBANGALORE
Ifwetakethetopdownapproach,thentaskofthehighestlayeristheoverallsystemtask,
as perceived by the client. All other layers are helpers to higher layers. If we take the
bottomup approach, we need to think of lower layers as providing an infrastructure on
whichhigherlayerscanbuild.Designingfrombottomuprequiresexperienceandforesight
to find the right abstractions for the lower layers,so that they will adequately support the
higherlayers.
4.Specifytheservices
Layersmustbestrictlyseparated;thatis,nocomponentmaybespreadoverseverallayers.
Generally locate more services in higher layers and fewer services in lower ones. This
preventsdevelopersfromhavingtolearnalargenumberofsimilarprimitives.
5.Refinethelayering
Wehavetoiteratesteps14afewtimes.Thisisbecauseusuallyitisnotpossibletodefine
abstractioncriterionwithoutthinkingoflayersandservices.Similarly,itisusuallywrongto
define components and services first, and then impose layered structure. The natural
solutionistoiteratethefirstfourstepstoachievegoodlayering.
6.Specifyaninterfaceforeachlayer
IfwetaketheBlackboxapproach,thenlayerJshouldhavea"flatinterface"thatoffersall
itsservicestoLayerJ+1.Ifwetakethewhiteboxapproach,thenlayerJ+1seestheinternals
ofLayerJ.
The recommended approach is blackbox approach because it supports system evolution
better than other approaches. Exceptions can be made for efficiency, but these are very
seldomrequiredortrulyappropriate.
7.Structureindividuallayers
Whenanindividuallayeriscomplex,itshouldbebrokenintowelldefinedcomponents
,MSRITBANGALORE
8.Specifycommunicationbetweenlayers
Most often used method of communication is the push model, where the required
information passed by layer J+1 to layer J in the service request/method call. Alternative
methodistousethepullmodel,wherelowerlayerrequestsinformationfromupperonceit
has been invoked. Thedisadvantage is that it introduces additional dependenciesbetween
layers,butitcanbesolvedbyusingcallbacks.
9.Decoupleadjacentlayers
Systems that use topdown invocation sequences use top down coupling, where upper
layersknowabout, andcall, lower layers, andthe lower layer is unawareof theidentity of
its users. Here return values are sufficient to transport the results in the reverse direction.
For bottomup communication callbacks can be used to preserve the oneway coupling.
Thisismosteffectivewhenalimitedeventvocabularyisusedinthecallbacks.Wherelots
ofcommunicationisbottomup,wemayneedtohavetwowaycoupling.
One design principle to remember at this stage is to code against interfaces rather than
implementations.
10.Designerrorhandlingstrategy
Error handling is often problematic in layered systems due processing time and
programmingeffort.Anerror handledin layerwhere itoccurred,orforwardedto the next
higher layer. If it is forwarded then the error information must be transformed into
something meaningful. The recommended principle is to try to handle errors at lowest
possiblelevel.
Variants
Relaxedlayeredsystem
Inthisvariant,eachlayermayuseservicesofalllayersbelow,notjustadjacentlayers.You
might have some layers that are partially opaque. The major gain is in flexibility,
performance.Butthepriceispaidinlossofmaintainability.
,MSRITBANGALORE
This is generally found in infrastructure systems (Operating Systems or frameworks) which
generallyrequirelittlemaintenancebutrequireshighperformance.
Layeringthroughinheritance
This variant found in OO systems. Here lower layers are base classes, and higher layers
inherit from lower layers. S, this allows for selective modification of lower layers. But the
major problem is that this variant closely ties layers together, which has severe
repercussionsinmodifiability.
Consequences
Advantages
Reuseoflayers:Ifabstractionsandinterfacesarewelldefinedreusabilityisenhanced.Black
boxreusedramaticallyreducesdevelopmenteffortandnumberofdefects
Support for Standardization: Clearly defined and commonly accepted levels of abstraction
enablestandardization.Thisallowsfortheusethirdpartylibrariesandframeworks.
Dependencies are kept local: Layer pattern generally minimizes ripple, as changes are
confined to one layer as long as interfaces are not changed. This also supports portability
(byreplacinglowestlevelcomponents).Thelimitationintherangeofinteractionsbetween
componentssimplifiescorrectnessreasoningandalsoenhancestestability
Exchangeability:Differentimplementationsofalayercanbeexchangedaslongasinterfaces
arethesame.
Disadvantages
Cascadesofchangingbehavior:Ifthebehaviorofalayerchangesdramatically(e.g.,replace
10MBPSEthernetlayerwith155MBPSATM)thismayhavelargerippleeffectthroughthe
architecture.
Lower efficiency: System performance may suffer from unnecessary layering overhead, as
multipletransformationsareperformedondataasitpassesthrougheachlayer.
Difficulty in establishing correct granularity of layers: It is not always easy to structure in
cleanlayersasitmaybedifficulttofindtherightlevelsofabstraction.
PipesandFiltersArchitecturalPatterns
,MSRITBANGALORE
LiketheLayerspattern,PipesandFilterspatternallowsforasystematicdecompositionofa
system that needs to process a stream of data. The solution is split into several sequential
steps.Thefiltercomponentimplementsonestepoftheprocess.Pipescarrydatabetween
adjacentfilters.
ForcestoBalance
There are several forces to balance when designing a system using this pattern. The
processing of data elements can be broken down into a sequence of individual
transformations.Smallprocessingstepsareeasiertoreuseindifferentcontextsthanlarger
components. But this might impact performance. It is also important to ensure that non
adjacent processing steps do not share information. Another aspect that will need to be
accommodatedisthatdifferentsourcesofinputdatamightexist.Wealsoneedtobeable
to present or store final results in various ways. We need to avoid explicit storage of
intermediateresultsinfilesasthiswillclutterdirectoriesandiserrorprone.Forthesakeof
improvingperformancewemaynotwanttoruleoutmultiprocessingstepsprobablytorun
some filters concurrently. We should also be able to enhance the system by exchanging
processingstepsandrecombiningsteps.
Solution
The Pipes and Filters pattern divides the task at hand into several sequential processing
steps,eachofwhichisconnectedbyadataflow.Thisisdoneinsuchawaythattheoutput
ofastepisinputtothenextprocessingstep.Eachoftheseprocessingstepsisimplemented
by a filter component. A filter consumes and delivers data incrementally to achieve low
latency and enable real parallel processing. Input to the system is a data source, such as a
file. The output of the system flows into a data sink, such as a file or display device. Pipes
connecttheinput,allthefiltersinthesystem,andfinallytheoutput.Thissequenceoffilters
combinedbypipesiscalledaprocessingpipeline.
Structure
Filters
The filters are the processing units of the pipeline. Some filters might be performing some
conversion task, such as converting Extended Binary Coded Decimal Interchange Code
(EBCDIC) to ASCII. Other filters might be involved in providing some enrichment service,
suchasaddinginformationtoincomingmessages.Stillothersmightbeperformingfiltering,
suchasdiscardingmessagesthatmatchaspecificcriterion.Therecouldbefiltersthatdoes
batchingwork,suchasaggregatingmultipleincomingmessagesandsendingthemtogether
in a single outgoing message. Some filters might get inputs from multiple filters and they
,MSRITBANGALORE
may perform consolidation, such as combining the data elements of multiple related
messagesintoasingleoutgoingmessagetothedownstreamfilter.
Filtersshoulduselittlelocalcontextinprocessingstreamsanditshouldnotpreservestate
informationbetweeninstantiations.
Filterscanbeclassifiedasactiveorpassive.Anactivefilterhasacontrolloopthatrunsinits
ownprocessorthread,andperpetuallyreadsdatafromitsinpipe,processesit,thenwrites
ittoitsoutpipe.Ifthereisnodataintheinpipe,thentheactivefilterentersawaitstate.A
passivefilter,whenactivated,readsasinglemessagefromitsinpipe,processesit,andthen
writes the result to its out pipe. There are two types of passive filters. A data driven filter
(also calledthepush variant) is activatedwhen another filterwritesdataintoits inpipe. A
demand driven filter(also called the pull variant) isactivated when another filter attempts
toreadfromitsemptyoutpipe.
Pipes
Apipetransfersdatafromadatasourcetoadatasink.Pipescanbebetween:
two threads of a single process (e.g., Java IO Streams) where the stream may contain
referencestosharedlanguageobjects.Pipescanalsobebetweentwoprocessesonasingle
hostcomputer(e.g.,UnixNamedPipes).Herethestreammaycontainreferencestoshared
operatingsystemobjects(e.g.,files).Insomesystems,pipescanbebetweentwoprocesses
in adistributedsystem (e.g.,Internet Sockets) where thestreamcontentsnormally limited
torawbytes.
DataSource
Thedatasourceprovidesinputtothesystem,asasequenceorstreamofdata.Thiscanbe
byactivelypushingthedatavaluestothefirstfilter,orbepassiveandletthefirstfilterpull
data.
DataSink
TheresultsfromthelastfilterinthesystemprovidesthefinaloutputtotheDataSink.Just
like the Data Source, the Data Sink can be active or passive. Either the last filter can push
dataontotheDataSinkortheDatasinkcanactivelypullresultsoutofthelastfilter.
Implementation
The first step in implementation will be to divide the functionality of the problem into a
sequence of processing steps. We have to define the type and format of the data to be
passed along each pipe. It might be better to have some uniform format for all the filters.
This is recommended if high flexibility is desired, although it might be inefficient, because
wewillneedsomefiltercomponentstomakethedatatransformations.
,MSRITBANGALORE
Thenextstepistodeterminehowtoimplementeachpipeconnection.wecandothiseither
as direct call or utilize a separate pipe mechanism. Passive filters can be implemented as
functions to provide pull activation. If push activation is needed, then the filters can be
implemented as procedures. Active filters can be implemented as processes or threads in
the pipeline program. The next step is to design errorhandling in the system. Decisions
havetobetakenabouthowtohandletheerrors,andhowtorecoverfromtheerrors.The
laststepistoconfigurethepipesandfilterssystemandinitiatetheprocessing.
Benefits
Reuse of filter elements is a major benefit. Filters that implement simple transformations
typicallyencapsulatefewerassumptionsabouttheproblemtheyaresolvingthanfiltersthat
implement complex transformations. The ease of filter recombination encourages filter
reuse.
ImprovedperformanceisachievedbecauseaPipesandFilterssolutionprocessesmessages
assoonastheyarereceived,therebyreducinglatency.
Efficiency can be achieved by parallel processing. Since active filters run in separate
processesorthreads,pipesandfilterssystemscantakeadvantageofamultiprocessor
Intermediate files is not necessary, but during debugging phase this might be necessary,
whichthispatternaccommodates.
Flexibility is attained by filter exchange as it is easy to exchange one filter element for
anotherwiththesameinterfacesandfunctionality.
Also,modifiabilityisimprovedaswecanchangethefilterconfigurationdynamically.
Wealsogetflexibilitybyreconfiguringapipelinetoincludenewfiltersorperhapstousethe
samefiltersinadifferentsequence.
Flexibility of exchange and recombination and ease of reuse enables the rapid creation of
prototypesystems
Liabilities
Designing filters typically requires expert domain knowledge. It also requires several good
examples to generalize from. The challenge of identifying reusable transformations makes
filterdevelopmentanevenmoredifficultendeavor.Designingthesystemwillbecomplex.
Assessing the state of the system is complex. The Pipes and Filters pattern distributes the
state of the computation across several components. This distribution makes querying the
state a complex operation. We can over come this by sharing state information but it is
,MSRITBANGALORE
expensive or inflexible, because each filter should have the information encoded,
transmitted,andatthereceiversenditshouldbethendecoded.
Efficiency gain by parallel processing can sometimes be an illusion due to several reasons.
Sometimes, the costs of data transfer can be high, compared to cost of computation by a
monolithic component. Also, when filters operate at different speeds, synchronization of
filters via pipes may stop and start filters often, especially when a pipe has only a small
buffer.Alsocontextswitchinginasingleprocessormachineisexpensive.Insomesystems,
there could be just one nonincremental filter, such as the Unix sort, that can become the
bottleneckofasystem.
There is also the data transformation overhead. The use of a single data channel between
filters often means that lot of transformation of data must occur, e.g., translation of
numbersbetweenbinaryandcharacterformats
Error handling is especially difficult because filters have no knowledge of the context that
they operate in. It is often difficult to detect errors in pipesandfilters systems. Also,
recovering from errors is even more difficult, so often the whole system might have to be
restarted.
MaintainabilityeffortisalsoincreasedbecauseaPipesandFiltersconfigurationusuallyhas
more components than a monolithic implementation. Each component adds maintenance
effort,systemmanagementeffort,andopportunitiesforfailure.
,MSRITBANGALORE
BlackboardArchitecturalPattern
Definition:
The Blackboard architectural pattern is useful for problems for which no deterministic
solution strategies are known. In Blackboard several specialized subsystems assemble their
knowledge to build a possibly partial or approximate solution.
Example:
Consider a software system for speech recognition. The input to the system is speech
recorded as a waveform.
The system not only accepts single words, but also whole sentences that are restricted
to the syntax and vocabulary needed for a specific application.
The desired output is a machine representation of the corresponding English phrases.
The transformations involved require acoustic- phonetic, linguistic and statistical
expertise
For example. one procedure divides the waveform into segments, another procedure
checks the syntax of candidate phrases

The input is the waveform at the bottom, and the output consists of the phrase 'are any by
Feigenbaum'.
Context:
An immature domain in which no closed approach to a solution is known or feasible.

Problem:
The Blackboard pattern tackles problems that do not have a feasible deterministic
solution for the transformation of raw data into high-level data structures
Example domains: Vision, image recognition, speech recognition and surveillance
,MSRITBANGALORE
Problem is, when decomposed, they span into several domains
The solutions to the partial problems require different representations and paradigms
In many cases no predetermined strategy exists for how the 'partial problem solvers
should combine their knowledge.
You may also have to work with uncertain or approximate knowledge.
Each transformation step can also generate several alternative solutions.
It is often enough to find an optimal solution for most cases, and a suboptimal
solution, or no solution, for the rest.
The limitations of a Blackboard system therefore have to be documented carefully and results
should be verified.
Artificial Intelligence systems have been used with some success for such problems.

This type of expert system structure is inadequate for a speech recognition system for 3
reasons:
All partial problems are solved using the same knowledge representation. But
components of speech recognition process differ widely.
The expert system structure provides only one inference engine to control the
application of knowledge. Different partial problems with different representations
require separate inference engines.
In a 'classical' expert system, control is implicit in the structure of the knowledge
base.
Solution:
The idea behind the Blackboard architecture is a collection of independent programs
that work cooperatively on a common data structure.
Each program is specialized for solving a particular part of the overall task.
These specialized programs are independent of each other.
They do not call each other, nor is there a predetermined sequence for their activation.
the direction taken by the system is mainly determined by the current state of
progress.
A central control component evaluates the current state of processing and coordinates
the specialized programs. This data-directed control regime is referred to as
opportunistic problem solving.
During the problem-solving process the system works with partial solutions that are
combined, changed or rejected.
The set of all possible solutions is called the solution space, and is organized into
levels of abstraction.
Lowest level: Internal representation of input
Highest level: potential solution of the task
Structure:
,MSRITBANGALORE
Divide your system into a component called blackboard, a collection of knowledge
sources, and a control component.
1. BLACKBOARD:
The blackboard is the central data store.
Elements of the solution space and control data are stored here.
Vocabulary - the set of all data elements that can appear on the blackboard.
The blackboard provides an interface that enables all knowledge sources to read from
and write to it.
All elements of the solution space can appear on the blackboard.
hypothesis or blackboard entry - solutions that are constructed during the problem
solving process and put on the blackboard
A hypothesis usually has several attributes such as abstraction level, that is, its
conceptual distance from the input.
In our example:
The solution space for the speech recognition example consists of acoustic-phonetic
and linguistic speech fragments.
The levels of abstraction are signal parameters, acoustic-phonetic segments, phones,
syllables, words, and phrases.
The blackboard can be viewed as a three-dimensional problem space with the time
line for speech on the X-axis, increasing levels of abstraction on the Y-axis and
alternative solutions on the Z-axis.
2. Knowledge Sources
Knowledge sources are separate, independent subsystems that solve specific aspects
of the overall problem.
None of them can solve the task of the system alone - a solution can only be built by
integrating the results of several knowledge sources.
In our example, we specify solutions for the following partial problems: defining
acoustic-phonetic segments, and creating phones, syllables, words and phrases.
For each of these partial problem we define one or several knowledge sources.
Knowledge sources do not communicate directly.
They therefore have to understand the vocabulary of the blackboard.
Often a knowledge source operates on two levels of abstraction forward and
backward reasoning
Knowledge sources are split into a condition-part and an action-part.
The condition part evaluates the current state of the solution process.
The action-part produces a result that may cause a change to the blackboard's
contents.

,MSRITBANGALORE
3. Control Component:
The control component runs a loop that monitors the changes on the blackboard and
decides what action to take next.
It schedules knowledge source evaluations and activations according to a knowledge
application strategy.
The strategy may rely on control knowledge sources.
These special knowledge sources do not contribute directly to solutions on the
blackboard, but perform calculations on which control decisions are made.
Relationship between three components:

Courtesy: Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sornmerlad, Michael
Stal, Pattern Oriented Architecture: A system of Patterns, Volume 1, Wiley Publications

,MSRITBANGALORE

Dynamics:

Implementation
Step1: Define the Problem
Specify the domain of the problem and the general fields of knowledge necessary to
find a solution.
Scrutinize the input to the system. Determine any special properties of the input such
as noise content or variations on a theme
Define the output of the system.
Detail how the user interacts with the system.
Step2: Define the solution space for the problem
We distinguish intermediate and top-level solutions on one hand, and partial and
complete solutions on the other.
So perform following steps:
Specify exactly what constitutes a top-level solution.
List the different abstraction levels of solutions.
Organize solutions into one or more abstraction hierarchies.
Step3: Divide the solution process into steps:
,MSRITBANGALORE
Define how solutions are transformed into higher-level solutions.
Describe how to predict hypotheses at the same abstraction level.
Detail how to verify predicted hypotheses by finding support for them in other levels.
Specify the kind of knowledge that can be used to exclude parts of the solution space.
Step4: Divide the knowledge into specialized knowledge sources with certain subtasks.
These subtasks often correspond to areas of specialization.
There may be some subtasks for which the system defers to human specialists for
decisions about dubious cases, or even to replace a missing knowledge source.
Examples of knowledge sources are segmentation, phone creation, syllable creation,
word creation, phrase creation, word prediction and word verification.
Step5: Define the vocabulary of the blackboard.
Elaborate your first definition of the solution space and the abstraction levels of your
solutions.
Find a representation for solutions that allows all knowledge sources to read from and
contribute to the blackboard.
If necessary, provide components that translate between blackboard entries and the
internal representations within knowledge sources.
Step6: Specify the control of the system
The Control component implements an opportunistic problem-solving strategy that
determines which knowledge sources are allowed to make changes to the blackboard.
The aim of this strategy is to construct a hypothesis that is acceptable as a result.
The credibility of a hypothesis is the likelihood that it is correct.
We estimate the credibility of a hypothesis by considering all plausible alternatives to it,
and the degree of support each alternative receives from the input data.
Step 7: Implement the knowledge sources.
Split the knowledge sources into condition-parts and action-parts according to the
needs of the Control component.
To maintain the independency and exchangeability of knowledge sources, do not
make any assumptions about other knowledge sources or the Control component.
We can implement different knowledge sources in the same system using different
technologies.
Consequences - Advantages
The Blackboard approach to problem decomposition and knowledge application
helps to resolve most of the forces listed in the problem section:
Experimentation. In domains in which no closed approach exists and a
complete search of the solution space is not feasible, the Blackboard pattern
makes experimentation with different algorithms possible
,MSRITBANGALORE
Support for changeability and maintainability. because the individual
knowledge sources, the control algorithm and the central data structure are
strictly separated.
Reusable knowledge sources.
Consequences - Liabilities
Difficulty of testing. Since the computations of a Blackboard system do not follow a
deterministic algorithm, its results are often not reproducible.
No good solution is guaranteed. Usually Blackboard systems can solve only a certain
percentage of their given tasks correctly.
Low Efficiency. Blackboard systems suffer from computational overheads in rejecting
wrong hypotheses.
High development effort. Most Blackboard systems take years to evolve.

,MSRITBANGALORE

PART B

UNIT 5
Distributed Systems Broker Architecture
There are two major trends in recent developments in hardware technology:
Computer systems with multiple CPUs are entering even small offices, notably
multiprocessing systems running operating systems such as IBM OS/2 Warp,
Microsoft Windows NT, or UNIX
Local area networks connecting hundreds of heterogeneous computers have become
commonplace.
Advantages
Economics better price/performance ratio
Performance and Scalability The n/w is the computer
Inherent distribution
Reliability
Drawbacks:
Distributed systems need radically different software than do centralized systems
OMG and companies such as Microsoft developed their own technologies
Types of Patterns
The Pipes and Filters pattern
Provides a structure for systems that process a stream of data.
Processing Step is encapsulated in filters and data is passes via pipes between
adjacent filters
The Microkernel pattern
,MSRITBANGALORE
Applies to software systems that must be able to adapt to changing system
requirements.
Separates a minimal functional core from extended functionality and
customer-specific parts.
The Broker pattern
can be used to structure distributed software systems with decoupled
components that interact by remote service invocations.
A broker component is responsible for coordinating communication, such as
forwarding requests, as well as for transmitting results and exceptions.
Three groups of users are benefited
Already working with a broker system and need to know architecture
Those who wish to build the lean version of the broker
Those who want to build full fledged broker system
Broker Definition
The Broker architectural pattern can be used to structure distributed software systems with
decoupled components that interact by remote service invocations. A broker component is
responsible for coordinating communication, such as forwarding requests as well as for
transmitting results and exceptions.
Example:
Suppose we are developing a city information system (CIS) designed to run on a wide area
network. Some computers in the network host one or more services that maintain information
about events, restaurants, hotels, historical monuments or public transportation. Computer
terminals are connected to the network. Tourists throughout the city can retrieve information
in which they are interested from the terminals using a World Wide Web IWWW) browser.
This front-end software supports the on-line retrieval of information from the appropriate
servers and its display on the screen. The data is distributed across the network and is not all
maintained in the terminals.
We expect the system to change and grow continuously, so the individual services
should be decoupled from each other.
The terminal software should be able to access services without having to know their
location.
One solution is to install a separate network that connects all terminals and servers
Intranet
Disadvantages
Not every Information provider wants to connect to a closed intranet
Available services should be accessed from all over the world
Context: Environment is a distributed and possibly heterogeneous system with independent
cooperating components.
,MSRITBANGALORE
Problem: It is a good idea to build a system as a set of decoupled interoperating components.
However, some means of inter-process communication is required. If the components handle
this by themselves, leads to dependencies and limitations. Example, system depending on
communicating mechanism used, clients need to know the location of server and limitation of
solution in one prog. language
Services for adding, removing, exchanging, activating and locating components are
also needed.
Applications that use these services should not depend on system-specific details to
guarantee portability and interoperability
From a developer's viewpoint, there should essentially be no difference between
developing software for centralized systems and developing for distributed ones.
An application that uses an object should only see the interface offered by the object.
It should not need to know anything about the implementation details of an object, or
about its physical location.

Use the Broker architecture to balance the following forces:
Components should be able to access services provided by others through remote,
location-transparent service invocations.
You need to exchange, add, or remove components at run-time.
The architecture should hide system and implementation-specific details from the
users of components and services.
Solution
Introduce a broker component to achieve better decoupling of clients and servers.
Servers register themselves with the broker, and make their services available to
clients through method interfaces.
Clients access the functionality of servers by sending requests via the broker.
A broker's tasks include locating the appropriate server, forwarding the request to the
server and transmitting results and exceptions back to the client.
By using the Broker pattern, an application can access distributed services simply by
sending message calls to the appropriate object.
In addition, the Broker architecture is flexible how?
The Broker pattern reduces the complexity involved in developing distributed
applications.
Broker systems therefore offer a path to the integration of two core technologies:
distribution and object technology.
They also extend object models from single applications to distributed applications.

The Broker architectural pattern comprises six types of participating components: clients,
servers, brokers, bridges, client-side proxies and server-side proxies.
A server implements objects that expose their functionality through interfaces that
consist of operations and attributes.
These interfaces are made available either through an interface definition language
(IDL) or through a binary standard.
There are two kinds of servers
Offering common services
Implementing Specific functionality
Server in our CIS example
WWW servers that provide access to HTML pages
Implemented as httpd daemon processes that wait on specific ports for incoming
requests.
,MSRITBANGALORE
When a request arrives at the server, the requested document and any additional data
is sent to the client using data streams.
Additionally, there exist CGI Scripts, Applets, and PHP etc
Clients are applications that access the services of at least one server.
To call remote services, clients forward requests to the broker. After an operation has
executed they receive responses or exceptions from the broker.
Clients do not need to know the location of the servers they access.
It allows the addition of new services and the movement of existing services to other
locations, even while the system is running.
In the context of the Broker pattern, the clients are the available WWW browsers.
A broker is a messenger that is responsible for the transmission of requests from
clients to servers, as well as the transmission of responses and exceptions back to the
client.
A broker must have some means of locating the receiver of a request based on its
unique system identifier.
A broker offers APIs to clients and servers that include operations for registering
servers and for invoking server methods.
A broker in our CIS example is the combination of an Internet gateway and the
Internet infrastructure itself.
Client-side proxies represent a layer between clients and the broker.
This additional layer provides transparency, in that a remote object appears to the
client as a local one.
In many cases, client-side proxies translate the object model specified as part of the
Broker architectural pattern to the object model of the programming language used to
implement the client.
Server-side proxies are generally analogous to Client-side proxies
The difference is that they are responsible for receiving requests, unpacking incoming
messages, unmarshaling the parameters, and calling the appropriate service.
Bridges are optional components used for hiding implementation details when two
brokers interoperate.
A bridge builds a layer that encapsulates all the system-specific details.
Bridges are not necessary in CIS because they all use http/ftp in common

Relation between objects:

,MSRITBANGALORE
Dynamics:
Scenario 1: Server registers itself with local broker component
The broker is started in the initialization phase of the system. The broker enters its
event loop and waits for incoming messages.
The user starts a server application. Server executes initialization code and then
registers with a broker
The broker receives the incoming registration request from the server. It extracts all
necessary information from the message and stores it into one or more repositories.
These repositories are used to locate and activate servers. An acknowledgment is sent
back.
After receiving the acknowledgment from the broker, the server enters its main loop
waiting for incoming client requests.

Scenario 2: Interaction between different brokers via bridge
Broker A receives an incoming request. It locates the server responsible for executing
the specified service by looking it up in the repositories. Since the corresponding
server is available at another network node, the broker forwards the request to a
remote broker.
The message is passed from Broker A to Bridge A. This component is responsible for
converting the message from the protocol defined by Broker A to a network-specific
but common protocol understood by the two participating bridges. After message
conversion, Bridge A transmits the message to Bridge B.
Bridge B maps the incoming request from the network-specific format to a Broker B-
specific format.
Broker B performs all the actions necessary when a request arrives, as described in
the first step of this scenario.
,MSRITBANGALORE

Implementation
Step1: Define an object model, or use an existing model.
Each object model must specify entities such as object names, objects, requests,
values, exceptions, supported types, type extensions, interfaces and operations.
Only Semantic issues are considered in this step
If the object model has to be extensible, prepare the system for future enhancements.
The description of the underlying computational model is a key issue in designing an
object model.
We need to describe definitions of the state of server objects, definitions of methods,
how methods are selected for execution and how server objects are generated and
destroyed.
Step2: Decide which kind of component-interoperability the system should offer.
We can design for interoperability either by specifying a binary standard or by
introducing a high-level interface definition language (IDL).
An IDL file contains a textual description of the interfaces a server offers to its
clients.
An IDL compiler uses an IDL file as input and generates programming-language code
or binary code.
One part of this generated code is required by the server for communicating with its
local broker, another part is used by the client for communicating with its local
broker.
Step3: Specify the APIs the broker component provides for collaborating with clients and
servers.
On the client side, functionality must be available for constructing requests, passing
them to the broker and receiving responses.
Decide whether clients should only be able to invoke server operations statically,
allowing clients to bind the invocations at compile-time.
If you want to allow dynamic invocations of servers as well, this has a direct impact
on the size or number of APIs.
If clients, servers and the broker are running as distinct processes, the API functions
need to be based on an efficient mechanism for inter-process communication between
clients, servers and the local broker.
,MSRITBANGALORE
Step4: Use proxy objects to hide implementation details from clients and servers.
On the client side, a local proxy object represents the remote server object called by
the client. On the server side, a proxy is used for playing the role of the client.
Client-side proxies package procedure calls into messages and forward these
messages to the local broker component.
Server-side proxies receive requests from the local broker and call the methods in the
interface implementation of the corresponding server.
Proxies hide implementation details by using their own inter-process communication
mechanism to communicate with the broker component.
Step5: Design the broker component in parallel with steps 3 and 4.
During design and implementation, iterate systematically through the following steps:
Specify a detailed on-the-wire protocol for interacting with client-side proxies
and server-side proxies.
A local broker must be available for every participating machine in the
network.
When a client invokes a method of a server, the Broker system is responsible
for returning all results and exceptions back to the original client.
If the proxies do not provide mechanisms for marshaling and unmarshaling
parameters and results, you must include that functionality in the broker
component.
If your system supports asynchronous communication between clients and servers,
you need to provide message buffers within the broker or within the proxies for the
temporary storage of messages.
Include a directory service for associating local server identifiers with the physical
location of the corresponding servers in the broker.
When your architecture requires system-unique identifiers to be generated
dynamically during server registration, the broker must offer a name service for
instantiating such names.
If your system supports dynamic method invocation, the broker needs some means for
maintaining type information about existing servers.
Plan the broker's actions when the communication with clients, other brokers or
servers fails.
Step6: Develop IDL compilers
Whenever you implement interoperability by providing an interface definition
language, you need to build an IDL compiler for every programming language you
support.
An IDL compiler translates the server interface definitions to programming language
code.

The Broker architectural pattern has some important benefits:
Location Transparency. As the broker is responsible for locating aserver by
using a unique identifier, clients do not need to know where servers are
located.
Changeability and extensibility of components. If servers change but their
interfaces remain the same, it has no functional impact on clients.
,MSRITBANGALORE
Portability of a Broker system. The Broker system hides operating systemand
network system details from clients and servers by using indirection layers
such as APIs, proxies and bridges.
Reusability. When building new client applications, you can often base the
functionality of your application on existing services

Liabilities:
Restricted efficiency. Applications using a Broker implementation areusually slower
than applications whose component distribution is static and known.
Lower fault tolerance. Compared with a non-distributed software system, a Broker
system may offer lower fault tolerance.

WhatisaPattern
Apatternforsoftwarearchitecturedescribesa
particularrecurringdesignproblemthatarisesin
specificdesigncontexts,andrepresentsawellproven
genericschemeforitssolution.The
solutionschemeisspecifiedbydescribingits
constituentcomponents,theirresponsibilitiesand
relationships,andthewaysinwhichthey
collaborate
Buschmann,F.etal,PatternOrientedSoftwareArchitectureVolume1,Wiley,1996
PropertiesofPatterns
Addressesarecurringdesignproblemthatarises
inspecificdesignsituationsandpresentsa
solutiontoit
Documentexisting,wellprovendesignexperience
IdentifyandSpecifyabtractionsatthehigh(est)
level
Provideacommonvocabularyandunderstandingdesignproblems
ARCHITECTURALPATTERN
THREEPARTSCHEMA
1.CONTEXT
2.PROBLEM
3.SOLUTION
,MSRITBANGALORE
ADDITIONALPARTS
VARIANTS
BENEFITS
LIABILITIES
Designsituationgivingrisetoadesignproblem
CONTEXT
Describesituationsinwhichtheproblemoccurs
Specifyingallsituationsispracticallynotpossible
Listallknownsituations;providesguidance
Example
DevelopingMessagingsolutionforamobilephone
DevelopingsoftwareforaManMachineInterface
PROBLEM
Setofforcesrepeatedlyarisinginthecontext
Startswithagenericproblemstatement;capturesthe
centraltheme
Completedbyforces;aspectoftheproblemthat
shouldbeconsideredwhensolvingit
Requirements
Context
Constraints
Desirableproperties
Forcescomplementorcontradict
SOLUTION
Configurationtobalanceforces
Structurewithcomponentsandrelationships
Runtimebehaviour
Structure:Aspatialbehaviouraddressesstatic
partofthesolution
Runtime:Behaviourwhilerunningaddresses
thedynamicpart
Example
Buildingblocksfortheapplication
Specificinputseventsandtheirprocessing
,MSRITBANGALORE
CategoryDescription
ArchitecturalAnarchitecturalpatternexpressesafundamentalstructural
organizationschemaofsoftwaresystems.Itprovidesasetof
predefinedsubsystems,specifiestheirrelationships,andincludes
rulesandguidelinesfororganisingtherelationshipsbetween
them.
DesignAdesignpatternprovidesaschemeforrefiningthesubsystemsor
componentsofasoftwaresystem,ortherelationshipsbetween
them.Itdescribesacommonlyrecurringstructureof
communicatingcomponentsthatsolvesageneraldesignproblem
withinaparticularcontext.
IdiomAnidiomisalowlevelpatternspecifictoaprogramming
language.Anidiomdescribeshowtoimplementparticular
aspectsofcomponentsortherelationshipbetweenthemusingfeaturesofthegiven
language.
CategoryDescription
MudtoStructureIncludespatternsthatsupportsuitabledecompositionofanoverall
systemtaskintocooperatingsubtasks
DistributedSystemsIncludespatternsthatprovideinfrastructuresforsystemsthathave
componentslocatedindifferentprocessesorinseveralsubsystemsandcomponents
InteractiveSystemsIncludespatternsthathelptostructurehumancomputerinteraction
AdaptableSystemsIncludespatternsthatprovideinfrastructuresfortheextensionand
adaptationofapplicationinresponsetoevolvingandchangingfunctionalrequirements
StructuralDecompositionIncludespatternsthatsupportasuitabledecompositionof
subsystemsandcomplexcomponentsintocooperatingparts
ARCHITECTURALPATTERNS
,MSRITBANGALORE
INTERACTIVESYSTEMS
1.MODELVIEWCONTROLLER
2.PRESENTATIONABSTRACTIONCONTROL
ADAPTIVESYSTEMS
1.MICROKERNAL
2.REFLECTION
ARCHITECTURALPATTERNS
MUDTOSTRUCTURE
1.PIPEANDFILTER
2.LAYERS
3.BLACKBOARD
DISTRIBUTEDSYSTEMS
1.BROKER
1. INTERACTIVESYSTEMS
PATTERNSTHATHELPSTOSTRUCTUREHUMANCOMPUTERINTERACTION
2.ADAPTABLESYSTEMS
PROVIDESINFRASTRUCTUREFOREXTENSIONANDADOPTIONOFAPPLICATIONTO
CHANGINGFUNCTIONALREQUIREMENTS
PATTERNDISCUSSIONCLASSIFICATION
1.CONTEXT
2.PROBLEM
3.SOLUTION
4.BENEFITS
,MSRITBANGALORE
5.LIABILITIES
6.VARIANTS
MVCMODELVIEWCONTROLLER
DIVIDESINTERACTIVEAPPLICATIONINTO3PARTS
1.MODELCONTAINSCOREFUNCTIONALITYANDDATA
2.VIEWDISPLAYINFORMATIONTOUSER.
3.CONTROLLERHANDLESUSERINPUT.
VIEWANDCONTROLLERTOGETHERGIVESUSERINTERFACE.
EXAMPLE:GRADESINTHEFORMOFDIFFERENTTYPESOFCHARTSANDTABLES.
HOWMVCWORKS?
1.EVENTISPASSEDTOCONTROLLER
2.CONTROLLERCHANGESVIEWS
3.VIEWSGETDATAFROMMODEL
4.MODELUPDATESVIEWWHENDATACHANGES.
IMPLEMENTATION
FUNDAMENTALSTEPS:
1.SEPARATEHUMANCOMPUTERINTERACTIONFROMCOREFUNCTIONALITY.
2.IMPLEMENTCHANGEPROPAGATIONMECHANISM.
3.DESIGNANDIMPLEMENTVIEWS.
4.DESIGNANDIMPLEMENTCONTROLLERS
5.DESIGNANDIMPLEMENTVIEWCONTROLLERRELATIONSHIP.
6.IMPLEMENTSETUPOFMVC.
ADDITIONALSTEPS
HIGHERDEGREEOFFREEDOMANDFLEXIBILITY
DYNAMICVIEWCREATION
PLUGGABLECONTROLLERS
HIERARCHICALVIEWSANDCONTROLLERS.
DECOUPLINGFROMSYSTEMDEPENDENCIES.
VARIANTS:
LOOSECOUPLINGOFVIEWANDCONTROLLERENABLESDIFFERENTVIEWESOFTHESAME
DOCUMENT.
BENEFITS:
MULTIPLEVIEWSOFTHESAMEMODEL
,MSRITBANGALORE
PLUGGABLEVIEWANDCONTROLLER
LIABILITIES:
INCREASEDCOMPLEXITY
INEFFICIENCYOFDATAACCESSINVIEW.
INTERACTIVESYSTEMS
1.MODELVIEWCONTROLLER(MVC)
2.PRESENTATIONABSTRACTIONCONTROL(PAC)
HIERARCHYOFCOOPERATINGAGENTS
EACHAGENTISRESPONSIBLEFORAPPLICATIONSFUNCTIONALITY
CONSISTSOFTHREECOMPONENTS,PRESENTATIONABSTRACTIONANDCONTROL
THISSEPARATESHUMANCOMPUTERINTERACTIONWITHCOREFUNCTIONALITY
PACISUSEDWHEREMANYSUBSYSTEMSAREINVOLVEDINTHEAPPLICATION
ORGANISESTHECOMMUNICATIONBETWEENCOREFUNCTIONALITYANDUSER
INTERFACEWHICHISNOTADDRESSEDINMVC.
CONTEXT:DEVELOPMENTOFANINTERACTIVEAPPLICATIONBYUSINGAGENTS.
PROBLEM:INTERACTIVESYSTEMSSHOULDBEVIEWEDASASETOFCOOPERATING
AGENTS,AGENTSSHOULDMAINTAINTHEIRSTATEANDDATA,
AGENTSSHOULDPROVIDETHEIROWNUI,SOLUTION:STRUCTURETHEAPPLICATIONLIKE
ATREEOFPACAGENTS.EACHAGENTDEPENDSONITSTOPLEVELAGENTS.
AGENTS
1.PRESENTATIONCOMPONENTPROVIDESVISIBLEBEHAVIOR
2.ABSTRACTIONCOMPONENTMAINTAINSDATAMODEL
3.CONTROLCOMPONENTSCONNECTSPRESENTATIONANDABSTRACTIONCOMPONENTS.
TOPLEVELPACAGENTPROVIDESFUNCTIONALCOREOFTHESYSTEM,
BOTTEMLEVELPACAGENTPROVIDESSEMANTICSOFTHESYSTEM,INTERMEDIATELEVEL
AGENTSMAINTAINSCOMMUNICATIONBETWEENLOWERLEVELAGENTS.
DYNAMICS
SCENERIOSUSESEQUENCEDIAGRAMSINITSSIMPLESTFORM.
IMPLEMENTATION
1.DEFINEAMODELOFTHEAPPLICATION
2.DEFINEASTRATEGYFORDESIGNINGPACHIERARCHY
3.SPECIFYTOPLEVELPACAGENT.
4.SPECIFYBOTTOMLEVELPACAGENTSFORSYSTEMSERVICES.
5.SPECIFYINTERMEDIATELEVELPACAGENTS.
6.SEPARATECOREFUNTIONALITYWITHHUMANINTERFACE.
,MSRITBANGALORE
7.INTRODUCETHECONTROLCOMPONENT.
8.LINKTHEHIERARCHYTOGETHER.
VARIANTS:PACAGENTSASACTIVEOBJECTS.
PACAGENTSASACTIVEPROCESSES.
BENEFITS:
SEPERATIONOFCONCERNS,SUPPORTFORCHANGEANDEXTENSION,SUPPORTFOR
MULTITASKING
LIABILITIES:INCREASEDSYSTEMCOMPLEXITY,COMPLEXCONTROLCOMPONENT,
OVERHEADINCOMMUNICATION,SMALLERATOMICSEMANTICCONCEPTS
UNIT6
UNIT6DEALSONLYWITHSALIENTFEATURESOFMICROKERNALANDREFLECTIONAS
OTHERDETAILSARESIMILARTOTHATEXPLAINEDINUNIT5
ADAPTABLEPATTERNS
Designforchange
,MSRITBANGALORE
Openforchange
SupportitsownmodificationCoreAdaptationtonewstandards,hardwareplatforms
TheMicrokernelarchitecturalpatternappliestosoftwaresystemsthatmustbeableto
adapttochangingsystemrequirements.Itseparatesminimalcorefunctionalityand
customerspecificparts.Themicrokernelalsoservicesandasocketforplugginginthese
extensionsandcoordinatingtheircollaboration
CONTEXT
DEVELOPMENTOFMANYAPPLICATIONSTHATUSESIMILARINTERFACESANDBUILTON
SAMECOREFUNCTIONALITY
PROBLEM
CONTINUOUSEVOLUTION
SOLUTION
SEQUANCEDIAGRAM
MICROKERNAL,INTERNALSEVER,EXTERNALSERVER,ADAPTER,CLIENT(LAYERED)
IMPLEMENTATIONTABLE:
Analysetheapplicationdomain
Analysetheexternalservers
Categorisetheservers
Partitionthecategories
Findaconsistentandcompletesetofoperationsandabstractions
Determinestrategiesforrequesttransmissionandretrieval
Structurethemicrokernelcomponent
Specifytheprogramminginterfacesforthemicrokernel
Microkernelisresponsibleforallthesystemresources
Designandimplementtheinternalservers
Implementtheexternalservers
Implementtheadapters
Developclientapplications
,MSRITBANGALORE
BENEFITS
Portability
FlexibilityandExtensibility
Separationofpolicyandmechanism
Scalability
Reliability
Transparency
LIABILITIES
Performance
Complexityofdesignandimplementation
ADAPTABLESYSTEMS
1.MICROKERNAL
2.REFLECTION:PROVIDESAMECHANISMFORDYNAMICALLYCHANGINGSTRUCTUREAND
BEHAVIOROFASOFTWARESYSTEM.
MODIFIABILITYANDEXTENSIBILITYAREADVANTAGES.
CONTEXT:BUILDINGSYSTEMSWHICHSUPPORTSMODIFICATIONS.
PROBLEM:CHANGINGSOFTWAREISTEDIOUSDUETOTHECOMPLEXINNERSTRUCTURE,
CHANGESCANBEOFANYSCALE,
FUNDAMENTALASPECTSCANCHANGE
SOLUTION:PROVIDEMETALEVELANDBASELEVELOBJECTS
METALEVELCONSISTSOFMETAOBJECTSMETAOBJECTSENCAPSULATEINFORMATION,
BASELEVELUSESMETAOBJECTSFORITSIMPLEMENTATIONANDREMAINSINDEPENDENT
OFTHOSEASPECTSWHICHARELIKELYTOCHANGE.
ANINTERFACEISSPECIFIEDTOMANIPULATEMETAOBJECTSITISCALLEDMOP(META
OBJECTPROTOCOL),PERSISTANTCOMPONENTSAREPRESENTATTHEBASELEVEL.
DYMAMICSPROVIDEDIFFERENTSCENERIOS
IMPLEMENTATION:
1.DEFINEAMODELOFAPPLICATION(PROBLEMDOMAIN)
,MSRITBANGALORE
2.IDENTIFYVARYINGBEHAVIOR
3.IDENTIFYSTRUCTURALASPECTSOFTHEDESIGNWHICHCANBECHANGED.
4.IDENTIFYSYSTEMSERVICES(RESOURCEALLOCATION,GARBAGECOLLECTION,PAGE
SWAPPING,OBJECTCREATION)
5.DEFINETHEMETAOBJECTS.
6.DEFINETHEMETAOBJECTPROTOCOL
7.DEFINETHEBASELEVEL.
VARIANTS:
REFLECTIONWITHSEVERALMETALEVELS.
BENEFITS:
1.NOMODIFICATIONOFSOURCECODE.
2.CHANGINGSOFTWARESYSTEMISEASY.
3.SUPPORTFORMANYKINDSOFCHANGE.(SUPPORTSCNAGEOFANYKINDORCHANGES
OFANYSCALE)
LIABILITIES:
1.MODIFICATIONATMETALEVELCAUSESDAMAGE
2.INCREASEDNUMBEROFCOMPONENTS.
3.SLOWERSYSTEMS.
4.NOTALLLANGUAGESSUPPORTREFLECTION.

,MSRITBANGALORE

UNIT 7

DesignPattern:WholePart
This design pattern belongs to the category of Structural Decomposition, which support a
suitabledecompositionofsubsystemsandcomplexcomponentsintocooperatingparts.
The context in which you will consider this design pattern is when you are implementing
aggregate objects. There are a few forces to balance when using this pattern. Parts might
havesomesimplebehavior,butcombiningthePartsmightgivesomeemergentbehavior.A
complexobjectshouldeitherbedecomposedintosmallerobjects,orcomposedofexisting
objects.Clientsshouldseethewholeobjectasjustoneobject,andallownodirectaccessto
itsconstituentParts.
Solution
TheWholepartpatternintroducesacomponentthatencapsulatesseveralsmallerobjects.
This aggregate object will appear as a single semantic unit to other objects in the system.
The Whole object defines an interface to allow other objects to access the functionality of
thesubsystem,astheycannotaccessconstituentPartsdirectly.
There are three types of relationships that can exist between the Whole object and the
variousPartobjectsinthesystem.
1. AssemblyParts relationship: Here there is tight coupling between Parts and whole. The
Aggregate has a structure which constrains Parts. Types of Parts, number of each Part is
predefined.
2. ContainerContents relationship is lesstightly coupled and it allows for dynamically
addingorremovingParts.
3. CollectionMember relationship is when all Part objects are identical or similar in
behavior. All Parts are treated equally and the Aggregate provides functionality to access
members.
Structure
WholeobjectrepresentsanaggregationofsmallerobjectsorParts.Wholecoordinatesand
organizesthecollaborationofParts.Byutilizingthefunctionalityofasinglepartormultiple
,MSRITBANGALORE
cooperating Parts, the Whole object provides services to external world. The Whole may
additionallyprovidefunctionalitywithouthavingtoinvokeanyPartobject.
ExternalclientscanaccessonlytheinterfacesexposedbytheWhole,asthePartobjectsare
outofboundsfortheclients.So,WholeactsasawrapperarounditsconstituentParts.The
structure of whole can impose some constraint on Part objects. The Whole object also
protectsPartsfromunauthorizedaccess.
Each Partobject canbelongto onlyone Whole, i.e., sharing of Parts isnot allowed. Whole
createsthePartobjectsandwhenWholeexits,Partobjectscannotpersist.
Implementation
ThefirststepistodesignthepublicinterfaceoftheWhole.So,firstweneedtoanalyzethe
functionalitytheWholemustoffertoitsclientsanddecideontheinterfacetogiveaccessto
the functionalities for the clients. When doing this, we look at the services only from the
clientsviewpoint.
ThenextstepistoseparatetheWholeintoParts.Therecouldbesituationswherewemight
have to synthesize a Whole from existing ones, i.e., take a bottomup approach. In other
situationswemightneedtotakeaTopdownapproach,wherewehavetodecomposethe
functionalityofthesubsystemintoconstituentparts.
The bottomup approach composes Wholes from looselycoupled Parts, which can be
reusedwhenbuildingothertypesofWhole.TheproblemsometimesisthatthePartsmight
notprovidecompletefunctionality,so,wemightneedtowritesomegluecodetotailorthe
parttofittherequirements
In the topdown approach, functionality of Whole is Partitioned and allocated to different
Part objects. The advantage is that there is no awkward gluecode, but we will have tight
couplingwhichmakesreusedifficult.
If using bottomup approach and using existing components, we need to specify
relationshipsbetweenthePartsandbetweenPartsandWhole.Ifsystemfunctionalityisnot
covered by existing Parts, we need to specify Parts that need to be built, probably using a
topdownapproach.
If using topdown approach, we need to partition the Whole's services into smaller
collaborating services and map these collaborating services to separate Parts. The
decomposition strategy selected should provide an easy way of implementing the services
oftheWholeobject.
ThenextstepistospecifytheservicesoftheWholeintermsofservicesoftheParts.Wecan
categorizeservicesintwoways:servicesprovidedbyusingPartobjectsandtheservicesthe
WholeperformsonitsownwithoutinvokinganyPartobjects.
,MSRITBANGALORE
If the services are provided by using Part objects we should strive to ensure that the Part
objects need no context information, resulting in loosecoupling. But if Part objects need
contextinformation,itwillresultintightcoupling.
A key decision to be made at this stage is if Parts can talk to each other or if all
communicationhastobemediatedthroughWhole.
ThenextstepwillbetoimplementthePartsandtheWhole.Wholeshouldmanagelifecycle
ofParts.WehavetodecideandimplementhowPartobjectswillbecreatedanddestroyed.
Variants
1. SharedPartsvariantisonewhereseveralWholescanshareonePart.Herethelifespan
ofasharedPartisdecoupledfromthatofitsWhole.
2. AssemblyParts variantis onewhere theWholeisanassemblyof smaller objects. Note
that the Part Objects can itself be composite objects, so the subsystem has a Tree or a
hierarchical structure. The AssemblyParts structures are fixed, so no addition or
removal of Parts at runtime is allowed. But, Exchange of Parts with other Parts of the
sametypemightbeallowed.
3. In the ContainerContents variant, the Whole acts as a container for different Part
objects.Here,wecanaddorremovePartobjectsdynamically.
4. CollectionMembers is a specialization of ContainerContents variant, where the Part
objects are of same type. The Parts are usually not coupled to or dependent on each
other. Here, too, we can add or remove Part objects dynamically. The Whole should
providesomefunctionalityforiteratingoversomeorallmembers.
5. In the Composite pattern the WholePart is represented as Tree. But the important
featureisthatthereisacommoninterfacetocomposite/simpleobjects,sowecantreat
objectsconsistentlyasthoughtheyweresimple.
Benefits
ChangeabilityofParts:Since,Partsarenotexposedtoclients,wecanreplacePartsaslong
assystemcanprovidesamefunctionality
Separation of concerns: Each concern is implemented by a separate Part and we can
implementcomplexstrategiesbycomposingthemfromsimplerservices
Reusability: Parts of a Whole can be reused in other aggregate objects and Wholes can be
reusedaswell,becauseClientsareagnosticabouttheParts.
Liabilities
Lower efficiency through indirection: The Clients have to go through Whole, which is an
overhead not present in monolithic systems. The performance degradation is especially
morewhenPartsarecompositeobjects
Complexity of decomposition into Parts: Partitioning solution space is often not
straightforward.
,MSRITBANGALORE
Organization of Work
The implementation of complex services is often solved by several components in
cooperation.
To organize work optimally within such structures we need to consider several
aspects.
Several general principles apply when organizing the implementation of complex
services.
separation of concerns
divide and conquer
Master-Slave applies the 'divide and conquer' principle
Widely used in Parallel and Distributed Computing
Also, in implementing triple modular redundancy
Types:
The Chain of Responsibility pattern avoids coupling the sender of a request to its
receiver by giving more than one object the chance to handle the request.
The Command pattern encapsulates a request as an object, allowing you to
parameterize clients with different requests, to queue or log requests and to support
undoable operations.
The Mediator pattern defines an object that encapsulates the way in which a set of
objects interact.

Master Slave
The Master-Slave design pattern supports fault tolerance, parallel computation and
computational accuracy. A master component distributes work to identical slave components
and computes a final result from the results these slaves return.
Example.
Travelling Salesman Problem
The task is to find an optimal round trip between a given set of locations such as the
shortest trip that visits each location exactly once.
The solution to this problem is of high computational complexity.
Generally, the solution to the traveling-salesman problem with n locations is the best
of (n-l)! possible routes.
Context: Partitioning work into semantically-identical sub-tasks.
Problem:
Several forces arise when implementing such a structure:
Clients should not be aware that the calculation is based on the 'divide and conquer'
principle.
Neither clients nor the processing of sub-tasks should depend on the algorithms for
partitioning work and assembling the final result.
It can be helpful to use different but semantically-identical implementations for
processing sub-tasks.
Processing of sub-tasks sometimes needs coordination, for example in simulation
applications using the finite element method.
Solution
Introduce a coordination instance between clients of the service and the processing of
individual sub-tasks.
A master component divides work into equal sub-tasks
Delegates these sub-tasks to several independent but semantically-identical slave
components
,MSRITBANGALORE
And computes a final result from the partial results the slaves return.
This general principle is found in three application areas:
Fault Tolerance
Parallel Computing
Computational Accuracy
Provide all slaves with a common interface. Let clients of the overall service
communicate only with the master.
We decide to approximate the solution to the traveling-salesman problem by
comparing a fixed number of trips.
Our strategy for selecting trips is simple-we just pick them randomly.
The program is tuned for a CM-5 computer from Thinking Machines Corporation
with sixty-four processors.
To take advantage of the CM-5 multi-processor architecture, the lengths of different
trips are calculated in parallel.
We therefore implement the trip length calculation as a slave.
A master determines a priori the number of slaves that are to be instantiated, specifies
how many trips each slave instance should compare, launches the slave instances, and
selects the shortest trip from all trips returned.

Structure:
The master component provides a service that can be solved by applying the 'divide
and conquer' principle.
It offers an interface that allows clients to access this service.
Internally, the master implements functions for partitioning work into several equal
sub-tasks, starting and controlling their processing, and computing a final result from
all the results obtained.
The master also maintains references to all slave instances to which it delegates the
processing of sub-tasks.
The slave component provides a sub-service that can process the sub-tasks defined by
the master. Within a Master-Slave structure, there are at least two instances of the
slave component connected to the master.

Relation between Master and Slave objects:
,MSRITBANGALORE

Dynamics
Scenario: Slaves are called one after the other
The scenario comprises of six phases
A client requests a service from the master.
The master partitions the task into several equal sub-tasks.
The master delegates the execution of these sub-tasks to several slave
instances, starts their execution and waits for the results they return.
The slaves perform the processing of the sub-tasks and return the results of
their computation back to the master.
The master computes a final result for the whole task from the partial results
received from the slaves.
The master returns this result to the client.

Implementation
Step1: Divide work
Specify how the computation of the task can be split into a set of equal sub-tasks.
Identify the sub-services that are necessary to process a sub-task.
In the travelling-salesman problem
,MSRITBANGALORE
Partition the problem so that a slave is provided with one round trip at time
and computes its cost.
However, for a machine like the CM5 with SPARC node processors, such a
partitioning might be too fine grained.
The costs for monitoring these parallel executions and for passing parameters
to them decreases the overall performance of the algorithm instead of speeding
it up.
A more efficient solution is to define sub-tasks that identify the shortest trip of a
particular subset of all trips.
This solution also takes account of the fact that there are only sixty-four processors
available on our CM5.
The number of available processors limits the number of sub-tasks that can be
processed in parallel.
To find the number of trips to be compared by each sub-task, we divide the number of
all trips to be compared by the number of available processors.
Step2: Combine sub-task results
Specify how the final result of the whole service can be computed with the help of the
results obtained from processing individual sub-tasks.
In our example, each sub-task returns only the shortest trip of a subset of all trips to be
compared.
We must still identify the shortest trip of these
Step 3: Specify the cooperation between master and slaves
Define an interface for the sub-service identified in step 1
It will be implemented by the slave and used by the master to delegate the processing
of individual sub-tasks.
There are two options for passing subtasks from master to slaves
include them as a parameter when invoking the sub-service, or
define a repository where the master puts sub-tasks and the slaves fetch them.
When processing a sub-task:
individual slaves can work on separate data structures or
all slaves can share a single data structure
Slaves may return the result of their processing:
explicitly as a return parameter, or
they may write it to a separate repository from which the master retrieves it.
For the traveling-salesman program we let each slave operate on its own copy of the
graph that represents all cities and their connections
The copies are created when instantiating slaves
Step 4: Implement the slave components according to the specifications developed in the
previous step
Step 5: Implement the master according to the specifications developed in step 1 to 3.
There are two options for dividing a task into sub-tasks.
The first is to split work into a fixed number of sub-tasks.
Most applicable if the master delegates the execution of the complete task to the
slaves.
This might typically occur when the Master-Slave pattern is used to support fault
tolerance or computational accuracy applications.
The second option is to define as many sub-tasks as necessary, or possible.
For example, the master component in our traveling-salesman program could define
as many sub-tasks as there are processors available.
,MSRITBANGALORE
The code for launching the slaves, controlling their execution and collecting their
results depends on many factors.
The master computes a final result with help of the results collected from the slaves.
Consequences Advantage
The Master-Slave design pattern has some important benefits:
Exchangeability and extensibility. By providing an abstract slave class, it is possible
to exchange existing slave implementations or add new ones without major changes to
the master. Clients are not affected by such changes.
Separation of concerns. The introduction of the master separates slave and client code
from the code for partitioning work, delegating work to slaves, collecting the results
from the slaves, computing the final result and handling slave failure or inaccurate
slave results.
Efficiency. The Master-Slave pattern for parallel computation enables you to speed up
the performance of computing a particular service when implemented carefully.
Liabilities
Feasibility. Master-Slave architecture is not always feasible. You must partition work,
copy data, launch slaves, control their execution, wait for the slave's results and
compute the final result. All these activities consume processing time and storage
space.
Machine dependency. The Master-Slave pattern for parallel computation strongly
depends on the architecture of the machine on which the program runs.
Hard to implement. Implementing Master-Slave is not easy, especially for parallel
computation.
Portability. Because of the potential dependency on underlying hardware
architectures, Master-Slave structures are difficult or impossible to transfer to other
machines.

Access Control
Sometimes a component or even a whole subsystem cannot or should not be
accessible directly by its clients.
For example, not all clients may be authorized to use the services of a component, or
to retrieve particular information that a component supplies.
And, sometimes we want to use the services of a remote service provider
This should be transparent to the client who requested the service
Types:
The Proxy design pattern makes the clients of a component communicate with a
representative rather than to the component itself.
The Facade pattern provides a uniform interface to a set of interfaces in a subsystem.
Facade defines a higher-level interface that makes the subsystem easier to use.
The Iterator pattern provides a way to access the elements of an aggregate object
sequentially without exposing its underlying representation.

DesignPattern:MasterSlave
Alternativeview
,MSRITBANGALORE
This pattern belongs to the category of Organization of Work. Work is partitioned into
severalidenticalsubtasks.Eachsubtaskisallocatedtoindependentcomponents(slaves)by
a special component (master). Master collates all the results returned by the slave
components.
ContextandForcestoBalance
Thecontexthereiswhenweneedtopartitionworkintosemanticallyidenticalsubtasks.
Master should hide the presence of slaves from Clients. The algorithm for partitioning the
task should not affect Clients or Slaves. Similarly, computing the final result by collating all
theresultsfromtheClientsshouldbetransparenttoClientsandSlaves.
In some cases where computational accuracy is missioncritical, Slaves must be
implementeddifferently,butwithidenticalfunctionality.
Also,Slavesneedtobecoordinatedtoachievesystembehavior.
Solution
A master component distributes work to identical slave components and computes a final
resultfromtheresultstheseslavesreturn.
Therearethreeapplicationareasinwhichthiscanbeapplied.
1. Fault tolerance, where the execution of a service is delegated to several replicated
implementations
2. Parallelcomputing,whereacomplextaskisdividedintoafixednumberofidentical
subtasksthatareexecutedconcurrently
3. Computational accuracy, where the execution of a service is delegated to several
differentimplementations
Structure
Mastercomponentprovidesaninterfacethatallowsclientstoaccesstheserviceachieved
by utilizing the Slave components. The responsibility of the Master component is to
Partition the work among several slave components. It should then start the execution of
slaves. After all slaves return their results it should compute a result and return it to the
Client.
TheSlavecomponentimplementsthesubserviceusedbythemaster.
Implementation
Thefirststepistodivideworkbypartitioningthetasktomultiplesubtasks.Thenweneedto
identifysubservicesneededtoaccomplishsubtasks.
,MSRITBANGALORE
The next step is computation of final result to send to client, by combining the results
returnedbythevariousslaves.
Next we will need to specify the cooperation between master and slaves. We have to
specifytheinterfaceforslaves.Wehavetodecidehowdatawillbepassedtotheslavesand
howtheslaveswillreturntheresultstotheMaster.Therearetwooptionshere:eitherwe
canuseasharedrepositoryorwecanpassthedataasparameter.
The next step is to implement the slave components. Here, if you want to achieve
concurrency,allclientsareidentical,butexistintheirownthread/process/hardware.Butif
youareusingvotingtactic,differentimplementationforeachslavewillberequired.
The last step is to implement the master. First functionality is partitioning the service to
subtasks.Herewecouldhaveafixednumberofsubtasks,oritcanbedynamic,depending
on the availability of slaves. Another functionality of the Master component is to manage
the lifecycle of slaves. We have to add functionality to launch slaves and coordinate
operationsofslaves.ThentheMasterhastocollectresultsandcomputefinalresulttoship
toclient.Lastimportantfunctionalitytoimplementiserrorhandling.
Variant
1. MasterSlaveforfaulttolerance:heretheMasterdelegatesentiretasktoallslaves,
so no need for partitioning of tasks. The Slaves are usually identical . The result of
first slave is sent to client, and typically the Master ignores results of other slaves.
There has to be a mechanism for detection of failure of slaves, e.g., through
timeouts.
2. MasterSlaveforparallelcomputation:Heretaskispartitionedbymasterandsentto
identicalslaves.Alltheslavesworkonsubtasksinparallelbutwithdifferentpartof
the data. Sometimes, they can work with shared data. The Master collates the
resultsfromthealltheslavesandsendsittoclient.Thisisthemostcommonuseof
theMasterSlavepattern.
3. MasterSlave forcomputational accuracy:Themaindifferencehere isthat weneed
different implementation on each slave, to implement the voting tactic. The final
resultcanbeaverageofallresultsfromslave,orthemaximum,orthemostcommon
value
4. Slavesas Processes: HereSlaves will run separatelyin theirownprocessspace, and
possiblyinmultiplehardware
5. MasterSlave with slave coordination: If computation is in multiple stages and
requiresslavestoexchangehugevolumesofdata,thecontrollogicforcoordination
canbeplacedintheslave,andtheMasterhascoordinationresponsibilities
Benefits
1. Exchangeability and extensibility: By using an abstract slave class, we can insulate
anychangestotheMaster,whenslaveimplementationhastobemodified.Clients,
ofcourse,arenotaffectedastheydonotdirectlydealwiththeSlaves.
,MSRITBANGALORE
2. Separationofconcerns:Weplacethecorefunctionalitywithslaves,andtheMaster
performs all tertiary duties, like, task partitioning, delegating work to slaves,
collecting results from slaves, collating result and ship to client and also handle
errors
3. Efficiency:Thepatternexploitsconcurrency,soperformancecanbeenhanced
Liabilities
1. Feasibility:Notalltaskscanbepartitioned,sotheapplicabilityofthisdesignpattern
islimited.
2. Systemdependencyaffectsportability:Thisisespeciallytrueinparallelcomputation,
wherethehardwarearchitectureandtopologydictatesdesign.
3. Implementation complexity: The added task of partitioning of tasks, and the
coordination of slaves could be complex. Also errorhandling might not be straight
forward.
4. Masterslavecommunicationlatencycanbeanissue,especiallyinrealtimesystems.

Proxy Design Pattern
The Proxy design pattern makes the clients of a component communicate with a
representative rather than to the component itself. Introducing such a placeholder can serve
many purposes, including enhanced efficiency, easier access and protection from
unauthorized access.

Example:

Company engineering staff regularly consults databases for information about material
providers, available parts, blueprints, and so on. Every remote access may be costly, while
many accesses are similar or identical and are repeated often. This situation clearly offers
,MSRITBANGALORE
scope for optimization of access time and cost. However, we do not want to burden the
engineer's application code with such optimization. The presence of optimization and the type
used should be largely transparent to the application user and programmer.
Context: A client needs access to the services of another component. Direct access is
technically possible, but may not be the best approach.
Problem:
A solution to such a design problem has to balance some or all of the following forces:
Accessing the component should be run-time-efficient, cost-effective, and safe for
both the client and the component.
Access to the component should be transparent and simple for the client.
The client should be well aware of possible performance or financial penalties for
accessing remote clients.
Solution
Let the client communicate with a representative rather than the component itself.
This representative-called a proxy
Proxy offers the interface of the component but performs additional pre- and post
processing such as access-control checking or making read-only copies of the
original.
Structure
The original implements a particular service. Such a service may range from simple
actions like returning or displaying data to complex data-retrieval functions or
computations involving further components.

The client is responsible for a specific task. To do its job, it invokes the functionality
of the original in an indirect way by accessing the proxy.
The client does not have to change its calling behavior and syntax from that which it
uses to call local components.

the proxy offers the same interface as the original, and ensures correct access to the
original.
To achieve this proxy maintains a reference to the original it represents.
,MSRITBANGALORE

The abstract original provides the interface implemented by the proxy and the
original.
In a language like C++, with no notable difference between subtyping and inheritance,
both the proxy and the original inherit from the abstract original.

The Relationship between the classes

Dynamics
Scenario: Client with the help of proxy getting service of the original
,MSRITBANGALORE

While working on its task the client asks the proxy to carry out a service.
The proxy receives the incoming service request and pre-processes it. This pre-
processing involves actions such as looking up the address of the original, or checking
a local cache to see if the requested information is already available.
If the proxy has to consult the original to fulfill the request, it forwards the request to
the original using the proper communication protocols and security measures.
The original accepts the request and fulfills it. It sends the response back to the proxy.
The proxy receives the response. Before or after transferring it to the client it may
carry out additional post-processing actions such as caching the result, calling the
destructor of the original or releasing a lock on a resource.

Implementation
Identify all responsibilities for dealing with access control to a component. Attach these
responsibilities to a separate component, the proxy.
2. If possible introduce an abstract base class that specifies the common parts of the
interfaces of both the proxy and the original.
Derive the proxy and the original from this abstract base.
If identical interfaces for the proxy and the original are not feasible you can use an
adapter for interface adaptation.
Adapting the proxy to the original's interface retains the client with
the illusion of identical interfaces, and a common base class for the
adapter and the original may be possible again.
3. Implement the proxy's functions.
4. Free the original and its clients from responsibilities that have migrated into the proxy.
5. Associate the proxy and the original by giving the proxy a handle to the original.
This handle may be a pointer, a reference, an address, an identifier, a socket, a port
and so on.
6. Remove all direct relationships between the original and its clients.
Replace them by analogous relationships to the proxy.

The Proxy design pattern has some important benefits:
Enhanced efficiency and lower cost.
,MSRITBANGALORE
The Virtual Proxy variant helps to implement a 'load-on-demand' strategy. This
allows you to avoid unnecessary loads from disk and usually speeds up your application.
Decoupling clients from the location of server components.
By putting all location information and addressing functionality into a Remote Proxy
variant, clients are not affected by migration of servers or changes in the networking
infrastructure.
Note however that a straightforward implementation of a remote proxy still has the
location of the original hard-wired into its code.
Separation of housekeeping code from functionality.
A proxy relieves the client of burdens that do not inherently belong to the task the
client is to perform.

Liabilities
Less efficiency due to indirection.
All proxies introduce an additional layer of indirection. But, usually negligible
compared to the cleaner structure of clients and gain of efficiency through caching.
Overkill via sophisticated strategies.
Be careful with intricate strategies for caching or loading on demand-they do not
always pay.
This occurs when originals are highly dynamic, for example in an airline reservation
or other ticket booking system.
UNIT 8

UsesofArchitecturalDocumentation
As we saw earlier that there are several stakeholders in a system and each Stake holders
Viewpoint is different. So, we cannot have a onesizefitsall document. Different
stakeholders for the documentation have different needs. Each require different kinds of
information, different levels of information and different treatments of information. Also,
stakeholderscanbeexperiencedorcouldbeanovice.
Architecturedocumentationisbothprescriptiveanddescriptive.Prescriptiveaspectsdetail
theconstraintsondecisionstobemadeinthefutureanddescriptiveaspectswilldocument
decisionsalreadymade.
LetusnowseehowdifferentstakeholdersmakeuseofArchitecturalDocuments
1. Architectandcustomerusethedocumenttonegotiatecompetingrequirements.
2. Architect and designers of constituent parts use it to resolve resource contention
andperhapstoestablishbudgetsforruntimeresourceconsumption.
3. Implementers use it to provide constraints that cannot be violated, as also the
exploitablefreedomstheyhavewhenbuildingthesystem
4. Testers and integrators are interested in aspects that specify blackbox behavior of
theelementsthatmustfittogether.
5. Maintainersuseittomakeclearthesideeffectsofaprospectivechange
,MSRITBANGALORE
6. Designers of other interoperating systems are interested in the parts of document
that discussed the services provided and required by the system, and the protocols
touseforsuchtransactions.
7. Qualityattributespecialists useittoprovidethe model thatdrives analytical tools,
tohelpevaluateifallQArequirementshavebeenmet
8. Managersuseittocreate/managedevelopmentteamsandalsototrackprogress
9. Qualityassuranceteamusesthedocumentationtoprovideabasisforconformance
checking
Views
Weunderstandtheneedformultipleviewsbecauseofthemultiplestakeholdersandtheir
varyingneedsandviewpoints.Whatallviewstoincludeinthearchitecturaldocumentation
canbedoneusingthesesteps
1. Produceacandidateviewlist. First,prepare listofstakeholders,the different views
they might be interested in and the level of detail that will be required by each
stakeholder
2. Combineviews:Nextweneedtoeliminateviewsthatcarryredundantinformation.
Alsosomeviewscanbecombined.
3. Prioritize:Nextstepwehavetoassignprioritiestowhichviewshavetobedonefirst.
Usually, we can follow a breadthfirst approach, i.e.,, first fill in all views with
overviewinformationandthenfleshoutthedetailbyorderofpriority.Also,wehave
tonotethattheManagementstakeholdermayneedattentionearlyintheprocess
DocumentingaView
ThisisthelayoutofthearchitecturaldocumentrecommendedbyBassetal.
1. Primarypresentation:Theessentialelementsofthesystems,relationshipsbetween
them.Thiscanbegraphicalortabular
2. Element Catalog: Details of all elements, including elements that may not have fit
into primary presentation is given here. In this section we need to discuss the
Properties of the elements, relationship between elements, interfaces offered by
eachelement,andthebehavioroftheelements
3. Context Diagram: This part relates the primary presentation to environment, in
termsofvariousinterfaces,protocols,etc.usedinthesystem
4. Variability Guide: The decisions that have deliberately been postponed has to be
documentedinthissection.Itmightalsobeappropriatetospecifythetimebywhich
suchdecisionhastobemade.
5. ArchitectureBackground:Thissectionshouldgivetherationaleforthechoicesmade
and also, why the alternatives were rejected. Analysis results to justify the design
should also be included here. Also, the assumptions made in making the design
decisionsshouldbemadeexplicit
6. Glossaryofalltechnicaltermsusedinthedocument.
7. Other Information: This is a catchall section to include any information that falls
outsidethepurviewofthepriorsections
DocumentingBehavior
,MSRITBANGALORE
StructuralViews(modules,uses,etc.)areinadequate.Behaviorneedstobedocumentedas
well.Theseshouldrevealmattersofinterestlike,orderingofinteractions,opportunitiesfor
concurrencyandtimedependenciesbetweenactions,etc.UMLsequencediagramsorstate
chartsmightbeusedtodocumentbehaviors.
DocumentingInterfaces
It is important document the interfaces, i.e., how elements within the system interact or
communicate.Hereisatemplatefordocumentinginterfaces.
1. InterfaceIdentity:Uniquenameofallinterfacestoalltheelementsinthesystemhas
tobegiven.
2. Resources provided: There are three parts to this section. First part is the resource
syntax or resource signature. This should include name of the resource, names of
arguments, data types of arguments, etc. The next part is the resource semantics,
i.e.,behaviorthathappenswhentheresourceisinvoked.Thiscanincludeeventsor
messagesthatmightberaisedwhentheresourceisinvoked,howitwillaffectother
behaviors,afterthisresourceisused,etc.Thelastpartisresourceusagerestrictions,
ifany.
3. Datatypedefinitions.Ifanydatatypeisusedthatisnotprovidedbytheunderlying
programming language that has described here. This should include declarations,
operations,translation,etc.
4. Exceptiondefinitions:Exceptionsthatcanberaisedbyallresourceshavetobelisted
in this section. Also, common exceptionhandling behavior should also be included
here.
5. Variabilityprovidedbytheinterface:Configurationoptionsprovidedbytheinterface
toelicitalternatebehaviorshouldbeincludedinthissection.
6. Quality attribute characteristics of the interface. This is needed to inform of any
significantQAcharacteristicaboutusageofresource(e.g.,performancedegradation
duetotoomanyfinegrainedcalls).
7. Element requirements: This section should specify the resource requirements of an
elementtoprovideitsserviceshouldbedescribedhere.
8. Rationale and design issues: Similar to the rationale section in documenting view,
thissectionshouldjustifythechoicesmadeandsignificantalternativesrejected.
9. Usageguide:Thisisimportantwhentheusageiscomplexandcannotbecompletely
explainedbythepriorsections.
CrossviewDocumentation
This should start with a section that tells how the documentation is organized to help the
stakeholderinreadingthedocument.
ThefirstiteminthismightbetheViewCatalog,whichdescribesforeachview,thenameof
the view, the description of the elements in it, the properties of the elements, relation
types, etc. The reason that particular view was included in the documentation should also
be mentioned here. The View template should specify the standard parts of a view
,MSRITBANGALORE
document and the contents and rules for each, to help the reader in identifying significant
aspectsfast.
The next section describes what the architecture is. This should contain the system
overview, which is a short description of the function of the system, targeted users,
background, etc. Mapping between views should be made explicit here. To help in the
reader navigate the documentation, the list of elements and where they appear in
document should also be given. A project glossary might be useful, to help nontechnical
stakeholdersornovicestakeholders.
Thelastsectionshouldexplainwhythearchitectureisthewayitis.Rationaleforthevarious
designdecisionsmadeshouldbeexplainedhere.Ifanychangescanbeanticipated,theside
effect of the change should be documented in this section. This section should explain the
constraintswithin whichthedevelopersneedtowork.Also,usefultoincludewillbetolist
thesignificantalternativesthatwererejected,andwhytheywererejected.

Documenting Architectures:
Need of Documenting Architecture
Documenting the architecture is the crowning step to crafting it.
Even a perfect architecture is useless if no one understands it, or
If key stakeholders misunderstand it.
The architecture for a system depends on the requirements levied on it, so too does the
documentation for architecture depend on the requirements levied on it.
Decidedly not a case of one size fits all !!!
Sufficiently abstract and sufficiently detailed
Different types of documentation needed for say, security and implementation
Architecture documentation is both prescriptive and descriptive.
different stakeholders for the documentation have different needsdifferent kinds of
information, different levels of information, and different treatments of information.
This might mean producing different documents for different stakeholders.
No, more likely, it means producing a single documentation suite with a roadmap that
will help different stakeholders navigate through it.
Write from the point of view of the reader
"easy to read" is in the eye of the beholder
In addition, each stakeholder comes in two varieties: seasoned and new.
Perhaps one of the most avid consumers of architectural documentation is none other
than the architect himself.
Documenting Views
Software architecture is a complex entity that cannot be described in a simple one-
dimensional fashion.
Documenting an architecture is a matter of documenting the relevant views and
then adding documentation that applies to more than one view.
This principle breaks the problem of architecture documentation into more tractable
parts
Choosing the relevant views
,MSRITBANGALORE
Documenting a view
Documenting information that applies to more than one view
Choosing the Relevant Views
This is where knowing your stakeholders and the uses they plan to make of the
documentation will help you construct the documentation package they need.
The many purposes that architecture can serveas a mission statement for
implementers, as the starting point for system understanding and asset recovery, as the
blueprint for project planning, and so forthare each represented by a stakeholder
wanting and expecting to use the documentation to serve that purpose.
Similarly, the quality attributes of most concern to you and the other stakeholders in
the system's development will affect the choice of what views to document.
In short, different views support different goals and uses.
Stakeholders and Corresponding Views

There are three types of views
Modules
Components and Connectors
Allocation
This three-way categorization reflects the fact that architects need to think about their
software in at least three ways at once

Module Views
C&C
Views
Allocation Views
Stakeholder Decomposition Uses Class Layer Various Deployment Implementation
Project
Manager
s s s d
Member of
Development
Team
d d d d d s s
Testers and
Integrators
d d s s s
Maintainers d d d d d s s
Product Line
Application
Builder
d s o s s s
Customer s o
End User s s
Analyst d d s d s d
Infrastructure
Support
s s s s d
New
Stakeholder
x x x x x x x
Current and
Future
Architect
d d d d d d s
Key: d =detailed information, s =some details, o =overview information, x =anything
,MSRITBANGALORE

Choosing a View
1. Produce a candidate view list
Begin by building a stakeholder/view table
Be as comprehensive as you can.
For the columns, enumerate the views that apply to your system.
Once you have the rows and columns defined, fill in each cell to describe how much
information the stakeholder requires from the view:
none, overview only, moderate detail, or high detail.
2. Combine views.
The candidate view list from step 1 is likely to yield an impractically large number of
views.
First look for views in the table that require only overview depth or that serve very
few stakeholders.
Next, look for views that are good candidates to be combinedthat is, a view that
gives information from two or more views at once.
For small and medium projects, the implementation view is often easily overlaid with
the module decomposition view etc
3. Prioritize
Which view to be completed first depends upon details specific to your project
you don't have to complete one view before starting another.
People can make progress with overview-level information, so a breadth-first
approach is often the best.
Also, some stakeholders' interests supersede others
Documenting the view
First of all, whatever sections you choose to include, make sure to have a standard
organization.
Allocating specific information to specific sections will help the documentation writer
attack the task and recognize completion, and
It will help the documentation reader quickly find information of interest at the
moment and skip everything else.
Clements et. al. proposed seven-part standard organization which is working
practically well.
Seven-part Standard Organization
1. Primary presentation shows the elements and the relationships among them that populate
the view.
The primary presentation should contain the information you wish to convey about
the system first.
Some elements can be omitted.
For example, you may wish to show the elements and relations that come into play
during normal operation, but relegate error handling or exceptional processing to the
supporting documentation.
Usually graphical, along with keys that explains notations
Sometimes, tabular. Text presents a summary.
2. Element catalog details at least those elements and relations depicted in the primary
presentation, and perhaps others.
Producing primary presentation is of focus, but without backup information, it
has little value.
,MSRITBANGALORE
For instance, if a diagram shows elements A, B, and C, there had better be
documentation that explains in sufficient detail what A, B, and C are, and their
purposes or the roles they play, rendered in the vocabulary of the view.
Introduce omitted elements here and detail.
3. Context diagram shows how the system depicted in the view relates to its environment in
the vocabulary of the view.
For example, in a component-and-connector view you show which component and
connectors interact with external components and connectors, via which interfaces and
protocols.

4. Variability guide shows how to exercise any variation points that are a part of the
architecture shown in this view.
An example of variability is found in software product lines where the product line
architecture is suitable for multiple particular systems
It should include documentation regarding each point of variation including
- the options among which a choice is to be made
- the binding time of the option.

5. Architecture background explains why the design reflected in the view came to be.
An architecture background includes:
- rationale, explaining why the decisions reflected in the view were made and why
alternatives were rejected.
- analysis results, which justify the design or explain what would have to change in
the face of a modification.
- assumptions reflected in the design.
6. Glossary of terms used in the views, with a brief description of each.
7. Other information. The precise contents of this section will vary according to the standard
practices of your organization.
They might include management information such as authorship, configuration
control data, and change histories.
Strictly speaking, information such as this is not architectural.

Documenting Behavior
Views present structural information about the system.
Structural information is not sufficient to allow reasoning about some system
properties.
For example, Reasoning about deadlocks
Behavior descriptions add information that reveals the ordering of interactions among
the elements, opportunities for concurrency, and time dependencies of interactions
Behavior can be documented either about an element or about an ensemble of
elements.
Exactly what to model will depend on the type of system being designed?
Different modeling techniques and notations are used depending on the type of
analysis to be performed.
In UML we use
State charts
Sequence Diagrams
,MSRITBANGALORE
State charts add a number of useful extensions to traditional state diagrams such as
nesting of state and "and" states, which provide the expressive power to model
abstraction and concurrency.
It is possible to answer a question such as Will the response time to a stimulus always
be less than 0.5 seconds?
A sequence diagram documents a sequence of stimuli exchanges.
It presents a collaboration in terms of component instances and their interactions and
shows the interaction arranged in time sequence.
The vertical dimension represents time and the horizontal dimension represents
different components.
They make it possible to answer a question such as what parallel activities occur when
the system is responding to these specific stimuli under these specific conditions.
Documenting Interfaces
An interface is a boundary across which two independent entities meet and interact or
communicate with each other.
Documenting an interface consists of naming and identifying it and documenting its
syntactic and semantic information.
The first two parts constitute an interface's "signature."
Signatures are useful (for example, they can enable automatic build checking), but are
only part of the story.
Semantics actually tell what happens when resources are brought into play
the architect chooses what information is permissible and appropriate for people to
assume about the element, and what is unlikely to change.
Documenting an interface is a matter of striking a balance between disclosing too
little information and disclosing too much.
The rule of thumb is to focus on how elements interact with their operational
environments, not on how they are implemented.
Elements that occur as modules often correspond directly to one or more elements in a
component-and-connector view.
The module and component-and-connector elements are likely to have similar, if not
identical, interfaces, and
Documenting them in both places would produce needless duplication.
To avoid that, the interface specification in the component-and-connector view can
point to the interface specification in the module view, and only contain the
information specific to its view.

WheredoessoftwarearchitecturefitsintheSDLC
Requirementscomefirst
Butnotallrequirementsarenecessarytogetstarted
Architectureshapedby(remembertheABC)
Functionalrequirements
Qualityrequirements
Businessrequirements
Expertiseandexperienceofarchitects
,MSRITBANGALORE
AttributeDrivenDesign
Designarchitecturetosupportbothfunctionalrequirementsandqualityrequirements.
ADDforSAthenfollowingRationalUnifiedProcessfortherestofthedesign
StepsinvolvedinAttributeDrivenDesign(ADD)
Choosethemoduletodecompose
startwithentiresystem
Inputsforthismoduleneedtobeavailable
Constraints,functionalandqualityrequirements
Refinethemodule
Choosearchitecturaldriversrelevanttothisdecomposition
Choosearchitecturalpatternthatsatisfiesthesedrivers
Instantiatemodulesandallocatefunctionalityfromusecasesrepresentingusingmultiple
views
Defineinterfacesofchildmodules
Verifyandrefineusecasesandqualityscenarios
Repeatforeverymodulethatneedsfurtherdecomposition
System>subsytem>submodule
Startwiththeentiresystemasthemodule
Refinethemodule
Choosethearchitecturaldriversfromthequalityscenariosandfunctionalrequirements
Thedriverswillbeamongthetoppriorityrequirementsforthemodule.
Realtimeperformancerequirement
Modifiabilityrequirement
Requirementsarenottreatedasequals
Lessimportantrequirementsaresatisfiedwithinconstraintsobtainedbysatisfyingmore
importantrequirements
,MSRITBANGALORE
ThisisadifferenceofADDfromotherSAdesignmethods
Recallanarchitecturalpatternisdeterminedby:
1.Asetofelements
2.Atopologicallayoutoftheelementsindicatingrelationships
3.Asetofsemanticconstraints
4.Asetofinteractionmechanisms
Foreachqualityrequirementthereareidentifiabletacticsandthenidentifiablepatterns
thatimplementthesetactics.
Reexamineperformanceandmodifiabilitytactics
ModifiabilityTacticcategories
1.Localizechanges
2.Preventrippleeffects
3.Deferbindingtime
Sincethemodifiabilityscenariosareprimarilyconcernedwithdesigntimechanges
primarytacticislocalizechanges
PerformanceTacticcategories
1.Resourcedemandcategory
2.Resourcearbitrationcategory
Fromeachprimarycategoryselectonetactic
1.Localizechanges
2.Semanticcoherenceandinformationhiding
3.Separateresponsibilitiesdealingwith
Userinterface
Nextstepistoverifywhetherdecompositionachievesthedesiredfunctionality
andAllocatethatfunctionality
Applyingusecasesmaymodifydecomposition
Intheendeveryusecaseoftheparentmodulemustberepresentablebysequenceof
responsibilitieswithinchildren
Assigningtheseresponsibilitiestothechildrenwillalsodeterminecommunications
betweenchildren
Views:moduledecomposition,concurrency,anddeployment
Moduledecompositionview
Providecontainersforfunctionality
Concurrencyview
Parallelactivitiessuchasresourcecontention,deadlock
Likelywillleadtothediscoveryofnewresponsibilities
Deploymentview
,MSRITBANGALORE
UsecasesIllustratingConcurrency
Twousersdoingsimilarthingsatthesametime
Oneuserperformingmultipleactivitiessimultaneously
Startingupthesystem
Shuttingdownthesystem
Thethreeviewsprovide:
Moduleview
patternsofcommunication
Concurrencyview
Interactionsamongthreads
Synchronizationinformation
Deploymentview
Hardwarerequirements
Timingrequirements
Communicationrequirements
Verifyingthedecompositionbyrunningtheparentsusecases
Preparingchildrenfortheirowndecompositionbyinheritingusecases/constraintsfrom
theparent.
Wewillexaminethisbylookingat:
Functionalrequirements
Constraints
QualityScenarios
UsingFunctionalrequirementstoverifyandrefine
Decomposingfunctionalrequirementsassignsresponsibilitiestochildmodules
,MSRITBANGALORE
Primarypresentationelementsandtheirrelationships
Elementcatalogexplainsthepicture
Contextdiagramhowthesystemrelatestoitsenvironment
Variabilityguidehowtoexerciseanyvariationpoints
Architecturebackgroundwhythedesignreflectedintheviewcametobe
Glossaryoftermsused
Otherinformation
,MSRITBANGALORE
Aninterfaceisaboundaryacrosswhichtowindependententitiesmeetandinteractor
communicatewitheachother.
Documentinginterfaceisanimportantpartofdocumentingarchitecture.
Documentinginterfaces
Interfaceidentityuniquename
,MSRITBANGALORE
Resourcesprovided
Locallydefineddatatypesifused
Exceptiondefinitionsincludinghandling
Variabilityprovidedforproductlines
Qualityattributesoftheinterface
Elementrequirements
Designissues
Usageguide
Howthedocumentationisorganized?
1.ViewcatalogIntroductiontoview
2.ViewTemplateDiagramasdiscussed
Resourcesprovided
Syntaxsignature
Semantics
assignmentofvaluestodata
changesinstate
eventssignaledormessagessent
howotherresourceswillbehavedifferentlyinfuture
humanlyobservableresults
Usagerestrictions
initializationrequirements
limitonnumberofactorsusingresource
WHATTHEARCHITECTUREIS?
SYSTEMOVERVIEW
MAPPINGBETWEENVIEWS
ELEMENTLIST
,MSRITBANGALORE
PROJECTGLOSSARY
THEIMLICATIONSOFSYSTEMWIDEDESIGNCHOICES?
MODIFIABILITYANDEXTENSIONEFFECTS
CONSTRAINTSONTHEDESIGNERDURINGIMPLEMENTATION
DECISIONALTERNATIVESTHATWEREREJECTED.
WHYADECISIONWASMADE,,Decisionmakingbyusingabstractionsitselfis
softwarearchitecture
ENDOFARCHITECTURALDISCUSSION

Software Architecture

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software Architecture

Загружено:

Авторское право:

Доступные форматы

SOFTWAREARCHITECTUREVTUEDUSATNOTESACADEMICYEAR20092010

A reference model is used to clarify things within an environment or a problem space by

Active redundancy (hot restart)

Passive redundancy (warm restart)

Availability: Tactics for Fault Recovery:: Reintroduction

Availability: Tactics for Fault Prevention

The tactic of Runtime registration supports plugandplay operation, but at an additional

The goal of performance tactics is to generate a response to an arriving event

Scenario I (top-down requests)

Вам также может понравиться