Architectural styles; Pipes and filters; Data abstraction and object-oriented organization; Event-based, implicit invocation; Layered systems; Repositories; Interpreters; Process control; Other familiar architectures; Heterogeneous architectures. Case Studies: Keyword in Context; Instrumentation software; Mobile robotics; Cruise control; three vignettes in mixed style.

1. Architectural Styles and Case Studies 1
Software Architecture Unit – II
Architectural Styles and Case Studies
Architectural styles; Pipes and filters; Data abstraction and object-oriented organization; Event-
based, implicit invocation; Layered systems; Repositories; Interpreters; Process control; Other
familiar architectures; Heterogeneous architectures. Case Studies: Mobile robotics; Cruise control;
three vignettes in mixed style.
Some Architectural Styles
Data flow systems
 Batch sequential
 Pipes and filters
Call-and-return systems
 Main program & subroutines
 Hierarchical layers
 OO systems
Virtual machines
 Interpreters
 Rule-based systems
Independent components communicating processes
 Event systems
Data-centered systems (repositories)
 Databases
 Blackboards

2. Architectural Styles and Case Studies 2
Pipe and Filter Architectural Style
• Suitable for applications that require a defined series of independent computations to be
performed on data.
• A component reads streams of data as input Software Design and produces streams of data as
output.
• Components: called filters, apply local transformations to their input streams and
often do their computing incrementally so that output begins before all input is consumed.
• Connectors: called pipes, serve as conduitsor the streams, transmitting outputs of one
filter to inputs of another filter.
Pipe and Filter Invariants
• Filters do not share state with other filters.
• Filters do not know the identity of their upstream or downstream filters.
Pipe and Filter Specializations
• Pipelines: Restricts topologies to linear sequences of filters
• Batch Sequential: A degenerate case of a pipeline architecture where each filter
processes all of its input data before producing any output.
PipeandFilterExamples
•UnixShellScripts:Provides anotationforconnectingUnix processesviapipes.
–catfile|grepErroll|wc-l
•TraditionalCompilers:Compilationphases arepipelined, thoughthephases arenotalwaysincremental.The
phasesinthepipelineinclude:
–lexicalanalysis+parsing+semanticanalysis+codegeneration
Pipesandfiltersadvantages:
 Easytounderstandtheoverallinput/output behaviorofasystemasasimplecompositionofthe
behaviorsoftheindividual filters.
 Theysupportreuse, sinceanytwofilterscanbehookedtogether,providedtheyagreeonthedata
thatisbeingtransmittedbetweenthem.
 Systemscanbeeasilymaintainedandenhanced, since newfilterscanbeaddedtoexistingsystems
andoldfilterscanbereplacedbyimprovedones.
 Theypermitcertainkinds ofspecializedanalysis,suchasthroughputanddeadlockanalysis.
 Thenaturallysupportconcurrentexecution.
Pipesandfiltersdisadvantages:
•Notgoodchoiceforinteractivesystems,becauseoftheirtransformationalcharacter.
•Excessiveparsingandunparsingleadstolossofperformanceandincreasedcomplexityinwritingthefilters
themselves

3. Architectural Styles and Case Studies 3
Object – Oriented and data abstraction
• Suitable for applications in which a central issue is identifying and protecting related bodies of
information (data).
• Data representations and their associated operations are encapsulated in an abstract data type.
• Components: are objects.
• Connectors: are function and procedure invocations (methods).
Object – Oriented Invariants
• Objects are responsible for preserving the integrity (e.g., some invariant) of the data
representation.
• The data representation is hidden from other objects.
Object-Oriented Specializations
• Distributed Objects
• Objects with Multiple Interfaces
Object-Oriented Advantages
•Becauseanobjecthidesits datarepresentationfromitsclients,itispossibletochangetheimplementation
withoutaffectingthoseclients.
•Candesignsystemsascollectionsofautonomousinteractingagents.
Object-OrientedDisadvantages
•Inorderforoneobjecttointeractwithanotherobject(via amethodinvocation)thefirst objectmustknow
theidentityofthesecondobject.
–ContrastwithPipeandFilter Style.
–Whentheidentityofanobjectchanges, itisnecessarytomodifyallobjectsthatinvokeit.
•Objectscausesideeffectproblems:
–E.g.,AandBbothuseobject C,thenB’seffectsonC looklikeunexpectedsideeffectstoA.

4. Architectural Styles and Case Studies 4
Event-Based, Implicit Invocation Style
•Suitableforapplicationsthat involveloosely-coupledcollectionofcomponents,eachofwhichcarriesout
someoperationandmayintheprocessenableotheroperations.
•Particularly usefulforapplicationsthatmustbereconfigured“onthefly”:
– Changing a service provider.
– Enabling or disabling capabilities.
•Insteadofinvokingaproceduredirectly...
–Acomponentcanannounce (orbroadcast)oneormoreevents.
–Othercomponentsinthesystemcanregisteran interestinaneventbyassociatinga procedurewiththe
event.
–Whenaneventisannounced,thebroadcastingsystem(connector)itselfinvokesalloftheproceduresthat
havebeenregisteredfortheevent.
•Aneventannouncement“implicitly”causestheinvocationofprocedures inothermodules.
ImplicitInvocationInvariants
•Announcersofeventsdonotknowwhichcomponentswillbeaffectedbythoseevents.
•Componentscannotmakeassumptionsabouttheorderofprocessing.
•Componentscannotmakeassumptionsaboutwhatprocessingwilloccuras aresultoftheirevents
ImplicitInvocationSpecializations
•Oftenconnectorsinanimplicitinvocationsystemincludethetraditionalprocedurecallinadditiontothe
bindingsbetweeneventannouncementsandprocedurecalls.
ImplicitInvocationExamples
•Usedinprogrammingenvironmentstointegratetools:
–Debuggerstopsata breakpointandmakesthatannouncement.
–Editorrespondstotheannouncementbyscrollingtotheappropriatesourcelineoftheprogramand
highlightingthat line.
•Usedtoenforceintegrityconstraintsin databasemanagementsystems(calledtriggers).
•Usedinuserinterfacestoseparatethepresentationofdatafromtheapplicationsthatmanagethatdata.
Advantages:
•Providesstrongsupportforreusesinceanycomponentcanbeintroducedintoasystem simplybyregistering
itfortheeventsofthatsystem.
•Easessystemevolutionsincecomponentsmaybereplacedbyothercomponentswithoutaffectingthe
interfacesofothercomponentsinthesystem.
Disadvantages:
•Whenacomponentannouncesanevent:
–ithasnoideawhatothercomponentswillrespondtoit
–itcannotrelyontheorderinwhichtheresponsesareinvoked
–itcannotknowwhenresponsesarefinished

5. Architectural Styles and Case Studies 5
Layered systems
• Suitable for applicationsthat involve distinct classes of servicesthat can be organized hierarchically.
• Each layer providesservice to the layerabove it and servesasa client to the layer belowit.
• Onlycarefullyselected proceduresfrom the inner layersare made available (exported) to their
adjacent outer layer.
• Components: are typicallycollectionsof procedures.
• Connectors: are typically procedure calls under restricted visibility
Layered StyleSpecializations
• Often exceptionsare made to permit non-adjacent layers to communicatedirectly.
– Thisisusuallydone for efficiencyreasons.
Layered StyleExamples
• Layered Communication Protocols:
– Each layer providesa substrate for communication at some levelof abstraction.
– Lower levelsdefine lower levelsof interaction, the lowest levelbeinghardware connections
(physicallayer).
• OperatingSystems
– Unix
Layered StyleAdvantages
• Design: based on increasinglevelsof abstraction.
• Enhancement: Changesto the function ofone layer affectsat most two other layers.
• Reuse: Different implementations(with identicalinterfaces)of the same layer can be used
interchangeably.
Layered StyleDisadvantages
• Not allsystemsare easily structured in an layered fashion.
• Performance requirementsmayforce the couplingof high-levelfunctionsto their lower-level
implementations.

6. Architectural Styles and Case Studies 6
Repository Style
• Suitable for applications in which the central issue is establishing, augmenting, and
maintaining a complex central body of information.
• Typically the information must be manipulated in a variety of ways. Often long-term
persistence is required.
• Components:
– A centraldata structure representingthe current state of the system.
– A collection of independent componentsthat operate on the centraldata structure.
• Connectors:
– Typicallyprocedure calls or direct memoryaccesses.
Repository StyleSpecializations
• Changesto the data structure trigger computations.
• Data structure in memory(persistent option).
• Data structure on disk.
• Concurrent computations and data accesses.
Repository StyleExamples
• Information Systems
• ProgrammingEnvironments
• GraphicalEditors
• AI(Artificial Intelligence)Knowledge Bases
• Reverse EngineeringSystems
Repository StyleAdvantages
• Efficient wayto store large amountsof data.
• Sharingmodelispublished asthe repositoryschema.
• Centralized management:
– backup
– security
– concurrencycontrol
Repository StyleDisadvantages
• Must agreeon adatamodel a priori(derived bylogic,without observed facts)
• Difficult to distributedata.
• Data evolution is expensive.

7. Architectural Styles and Case Studies 7
BlackboardStyle
 Characteristics: cooperating ‘partial solution solvers’ collaborating but not following a pre-
defined strategy.
 Current state of the solution stored in the blackboard.
 Processing triggered by the state of the blackboard.
Examples of Blackboard Architectures
Problems for which no deterministic solution strategy is known, but many different approaches
often alternative ones) exist and are used to build a partial or approximate solution.
AI: vision, speech and pattern recognition.
Heterogenous Architecture
It isa combination of different architecturesat different phases.
There are three kindsof heterogeneity,theyare asfollows.
 Locationallyheterogeneous meansthat a drawingof itsruntime structureswillreveal
patternsof different stylesin different areas.
For example,some branchesof a Main-Program-and-Subroutinessystem might have a shared data
repository(i.e.a database).
 HierarchicallyHeterogeneous meansthat a component of one style,when decomposed,is
structured accordingto the rulesof a different style
For example,an end-user interface sub-system might be built usingEvent System architecturalstyle,
while allother sub-systems − using Layered Architecture.
 SimultaneouslyHeterogeneous meansthat anyof severalstylesmay wellbe apt
descriptionsof the system.

8. Architectural Styles and Case Studies 8
Interpreter Style
• Suitable for applicationsin which the most appropriate language or machine for executingthe
solution isnot directlyavailable.
• Components: include one state machine for the execution engine and three memories:
– current state of the execution engine
– program beinginterpreted
– current state of the program beinginterpreted
• Connectors:
– procedure calls
– direct memoryaccesses.
Interpreter StyleExamples
• ProgrammingLanguage Compilers:
– Java
– Smalltalk
• Rule Based Systems:
– Prolog
– Coral
• ScriptingLanguages:
– Awk
– Perl
Interpreter StyleAdvantages
• Simulation of non-implemented hardware.
• Facilitatesportabilityof application or languagesacrossa varietyof platforms.
Interpreter StyleDisadvantages
• Extra levelof indirection slowsdown execution.
• Java hasan option to compile code.
– JIT (Just In Time)compiler.

9. Architectural Styles and Case Studies 9
Process-Control Style
• Suitable for applications whose purpose is to maintain specified properties of the outputs of the
process at (sufficiently near) given reference values.
• Components:
– Process Definition includes mechanisms for manipulating some process variables.
– Control Algorithm for deciding how to manipulate process variables.
• Connectors: are the data flow relations for:
– Process Variables:
• Controlled variable whose value the system is intended to control.
• Input variable that measures an input to the process.
• Manipulated variable whose value can be changed by the controller.
– Set Point is the desired value for a controlled variable.
– Sensors to obtain values of process variables pertinent to control.
Feed-Back Control System
 The controlled variable is measured and the result is used to manipulate one or more of the
process variables.
Open-LoopControlSystem
 Informationabout processvariablesis notusedtoadjustthe system
ProcessControlExamples
•Real-TimeSystemSoftwaretoControl:
–AutomobileAnti-LockBrakes
–NuclearPowerPlants
–AutomobileCruise-Control

10. Architectural Styles and Case Studies 10
Case Study
MobileRobots: A casestudyon architectural styles
Typical software functions.
 Acquiringand interpretinginput provided bysensors.
 Controllingthe motion of wheelsand other movable parts.
 Planningfuture paths.
Examplesof complications.
 Obstaclesmayblockpath.
 Sensor input maybe imperfect.
 Robot mayrun out of power.
 Mechanicallimitationsmay restrict accuracyof movement.
 Robot maymanipulate hazardousmaterials.
 Unpredictable eventsmay demand a rapid (autonomous)response.
Evaluation criteriafor agiven architecture
Req 1.Accommodation of deliberateand reactivebehavior. Robot must coordinate actionsto
achieve assigned objectives with the reactions imposed bythe environment.
Req 2.Allowancefor uncertainty. Robot must function in the context of incomplete,unreliable and
contradictoryinformation.
Req 3.Accountingof dangers in therobot’s operations and its environment. Relatingto fault
tolerance,safetyand performance, problemslike reduced power supply,unexpectedlyopen doors,
etc.,
should not lead to disaster.
Req 4.Flexibility. Support for experimentation and reconfiguration.
Solution 1: Control Loop
Therequirements areas follows:
Req 1: An advantage of the closed loop paradigm isits simplicity,it capturesthe basicinteraction
between the robot andtheoutside.
Req 2: Uncertaintyisresolved byreducingunknownsthrough iteration: a problem if more
subtle(clever)stepsare needed.
Req 3: Fault tolerance and safetyare enhanced bythe simplicityof the architecture.
Req 4: Major components(supervisor, sensors,motors)can be easilyreplaced

11. Architectural Styles and Case Studies 11
Solution 4: Blackboard architecture
Componentsare the following:
 Captain: Overallsupervisor
 Map navigator: High-level path planner
 Lookout: Monitorsenvironment for landmarks.
 Pilot: Low-levelpath planner and motor controller
 Perception subsystems: Accept sensor input &integrate it into a coherent situation
interpretation.
Therequirements areas follows:
Req 1: The componentscommunicate via shared repositoryof the blackboard system.
Req 2: The blackboard isalso the meansfor resolvingconflictsor unvertaintiesin the robot’sworld
view.
Req 3: Speed,safety,and realiablityisguaranteed.
Req 4: Supportsconcurrencyand decouplessendersfrom receivers,thisfacilitatingmaintenance.

12. Architectural Styles and Case Studies 12
Cruise Control
A cruise control (CC) system that exists to maintain the constant vehicle speed even over varying
terrain.
Inputs: System On/Off: If on, maintain speed
Engine On/Off: If on, engine is on. CC is active only in this state
Wheel Pulses: One pulse from every wheel revolution
Accelerator: Indication of how far accelerator is de-pressed
Brake: If on, temp revert cruise control to manual mode
Inc/Dec Speed: If on, increase/decrease maintained speed
Resume Speed: If on, resume last maintained speed
Clock: Timing pulses every millisecond
Outputs: Throttle: Digital value for engine throttle setting
Restatement of Cruise-Control Problem
Whenever the system isactive,determine the desired speed,and controlthe engine throttle setting
to maintain that speed.
PROCESS CONTROL VIEW OF CRUISE CONTROL
Computational Elements
Process definition - take throttle setting as I/P & control vehicle speed
Control algorithm - current speed (wheel pulses) compared to desired speed
o Change throttle setting accordingly presents the issue:
o decide how much to change setting for a given discrepancy
Data Elements
Controlled variable: current speed of vehicle
Manipulated variable: throttle setting
Set point: set by accelerator and increase/decrease speed inputs
system on/off, engine on/off, brake and resume inputs also have a bearing
Controlled variable sensor: modelled on data from wheel pulses and clock

13. Architectural Styles and Case Studies 13
Completecruisecontrol system
Three Vignettes in mixed style
In general,it isa commercialsoftware content management system,recordsand documents
management system,portal,and collaboration tools company.Vignette'sPlatform consistsof several
suitesof productsallowing non-technicalbusinessusersto create,edit and track content through
workflowsand publish thiscontent through Web or portalsites.
Each level corresponds to a different process management function with its own decision-support
requirements.
Level 1: Process measurement and control: direct adjustment of final control elements.
Level 2: Process supervision: operations console for monitoring and controlling Level 1.
Level 3: Process management: computer-based plant automation, including management reports,
optimization strategies, and guidance to operations console.
Levels 4 and 5: Plant and corporate management: higher-levelfunctionssuch as cost accounting,
inventorycontrol,and order processing/scheduling.