Architectural Styles and Case Studies, Software architecture ,unit–2
Download as DOCX, PDF14 likes11,671 views
The document discusses various architectural styles in software architecture including pipes and filters, object-oriented design, event-based invocation, layered systems, repository style, and blackboard architecture. It includes case studies such as mobile robotics and cruise control, detailing how different architectures can be applied in practical scenarios, their advantages, and disadvantages. Each architectural style is characterized by its components and connectors, emphasizing their suitability for specific applications and the benefits they bring to software design.
Architectural Styles and Case Studies, Software architecture ,unit–2
- 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.