Presentation on theme: "Software Architecture in Practice"— Presentation transcript:
1 Software Architecture in Practice Architectural Design
2 ... once everything has been said, software is defined by code. The bottom lineBertrand Meyer:... once everything has been said,software is defined by code.Or – in other words:Architectural views, UML, quality attribute scenarios don’t pay the bills...
3 What do we do?We have identified that our architecture should strike a balance between qualities A, B, and C – in various scenarios.and - Conceptual integrity, Correctness and completeness, and BuildabilityQuestion: How do we then use this information to guide the design ???Architectural Design ?
4 Architectural design The idealized process Architectural EvaluationFunctional requirementsArchitecturalDesignArchitectural DesignProposalsArchitectural qualitiesBest ArchitectureCode
5 Architectural DesignThe process of designing a software architecture that meets quality attribute requirementsAnd enables implementation of functional requirementsCharacteristics of the processCreativeIterative (and incremental)Functional decompositionQuality decompositionExperimentalArchitectural prototypingBased on experienceThis lesson
6 Overview Architectural Styles Architectural Patterns Tactics A vocabulary of large-scale structureArchitectural PatternsName, Problem, Solution, ConsequencesPatterns = Styles?TacticsSurgical bits and pieces
8 Architectural StyleAn architectural style is a description of component types and a pattern of their runtime control and/or data transfer.defines constraints on component types and interaction patternsthereby delimits/spans a set of architectures(also called architectural pattern )Ex.: Client-ServerIflg. Bass §2.2 (se også Hofmeister §1.1.3)Bemærk: fokus på runtime! AltsåStyle defineret ved (Bass §5.1):mængde af komponent typertopologi = runtime relationer mellem komponenternemængde af semantiske begrænsninger (typisk data/control adgang)mængde af connectorer som medierer kommunikation, koordinering, samarbejde
9 The parts of a ’style’ Parts of a style A set of component types with a given role/functionalityA topology of relations (usually runtime relations)A set of connectors (RMI, socket, memory, etc.) that handle communication, coordination or collaboration.A set of semantic constraintsi.e. what can components/connectors do or not do?
10 Exercise: Client-server Component types?categories of componentsTopology?(“the landscape” / set of relations)Connectors?what are the carriers of data- and control flow?Semantic constraints?what rule must the components/connectors obey?
11 Why are architectural styles / patterns interesting and important? Why is it interesting?Why are architectural styles / patterns interesting and important?
12 describe architectures with specific qualities Why is it interesting?Because theydescribe architectures with specific qualities…anddocument itprovides a vocabulary
13 Classification in Bass Independent ComponentsEvent SystemsCommunicating ProcessesData FlowBatch sequentialPipes and filtersData-CenteredRepositoryBlackboardBaseret på Bass figur 5.1.Bemærk at klassifikation i en given familie ikke er entydig. F.eks. tilhører en client-server arkitektur både ’independent components’ og ’data-centered’ familien.
14 Classification Virtual Machine Call and Return Heterogeneous styles InterpreterRule-based systemCall and ReturnLayeredObject-orientedMain program and subroutineHeterogeneous stylesdifferent styles mixed at different levels
15 Data-centered Repository and Blackboard QA: Data integrability: clients are independentExercise: Name some examples of systemsSAP-Fig 5.2Repository: Passiv datalagringBlackboard: Publish/subscribe notifikation på ændringerQuality attributes: (data) integrability, modifiability i mindre gradEks.: client-server, SCM systemer; voice-recognition
16 Data-flow Batch-sequential and Pipes-and-filters QA: Modifiability, ReusabilityExercise: Name some examples of systemsSAP-Fig 5.3Batch-sequential: Een process helt færdig før næste tager over;Pipes-and-filters: Incrementel transformation af dataQuality Attributes: Reuse, modifiability. Anti-QA: PerformanceUlemper: umuligt at lave interaktive systemer. Ofte dårlig performancefordi komponenterne ikke kan kommunikere indbyrdes og dermed optimere,og ofte bruges et lav-niveau format over pipes (ASCII).Eks.: ’Gamle’ tape-baserede systemer, UNIX shell, billed-behandling IS2000
17 Virtual machine Interpreter Rule-based systems QA: Portability Exercise: Name some examples of systemsSAP-Fig5.4QA: Portability. Anti-QA: PerformanceEks.: Java virtuelle maskiner
18 Call-and-Return MPS style [OO style] Layered style QA: Modifiability, Scalability (Layers:Portability)SAP-Fig 5.5 & 5.7QA: Modifiability, ScalabilityDiskuter n-tier versus layered arkitektur. Diskuter Layer bridging.Sammenlign ’virtual machine’Eks.: TCP/IP en typisk lagdelt arkitektur. Stepwise refinement -> MPSFiguren for layers ikke så vældig god. F.eks. pile OP i lagene hvilket bryder noget med modifiability QA.
19 Independent components Communicating processesclient-server is a prominent caseEvent systemspublish-subscribe systemsmessage/channel based systemsQA: Modifiability (decouple sender and receiver)Uafhængige processer ELLER objekter som kommunikerer via beskeder.Event systemer: Hvorledes kontrol fordeles er en del af style’n. Implicit invokation er ’publish/subscribe’ (Observer pattern).Eks.: Windows event-dispatching; Java Swing registrering af listener instanser (Samme mekanisme i EJB?)
20 Heterogeneous styles Most large systems use several styles in a mix The categories are not disjointEx.: CORBA-based client-serverObject-oriented call-and-returnLayeredIndependent components
21 SummaryArchitectural styles/patterns are proven templates for organizing components and connectors to achieve certain QA.Can be classifiedData-flowData-centredCommunicating processesCall and returnMost real architectures are mixes of styles.
22 Architectural Patterns Same wine on new bottles?
23 Christopher Alexander: Pattern Each pattern describes a problem which occurs over and over again in our envi-ronment, and then descri-bes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.Christopher Alexander worked on planning towns and buildings, but the definition works just as well for object-oriented patterns.In software the solution is expressed in terms of objects, roles, interfaces, and collaboration patterns instead of windows, doors and walls, but the contents of a patter is always:A solution to a problem in a context
24 ‘Alcoves’: One of Alexander’s patterns ... many large rooms are not complete unless they have smaller rooms and alcoves opening off them. No homogeneous room, or homogeneous height, can serve a group of people well. To give a group a chance to be together, as a group, a room must also give them the chance to be alone, in one’s and two’s in the same space.This problem is felt most acutely in the common rooms of a house – the kitchen, the family room, the living room. In fact it is so critical there, that the house can drivee the family apart when it remains unsolved...In modern life, the main function of a family is emotional; it is a source of security and love. But these qualities will only come into existence if the members of the house are physically able to be together as a family.This is often difficult. The various members of the family come and go at different times of day; even when they are in the house, each has his own private interests...To solve the problem, there must be some way in which the members of the family can be together, even when they are doing different things.Therefore:Make small places at the edge of any room, usually no more than 6 feet wide and 3 to 6 feet deep and possibly much smaller. These alcoves should be large enough for two people to sit, chat, or play and sometimes large enougf to contain a desk or table.Give the alcove a ceiling which is markedly lower than the ceiling height in the main room...(Alexander, 1977)
25 Branding? Buschmann et al. (1st ed) Patterns that are Examples Pattern-oriented software architecturePatterns that aremore coarse-grained than design p.more specific focus than design p.ExamplesModel-view-controller, Blackboard, Broker, Forwarder/Receiver, ...Two other volumesconcurrency, networking, resource management
26 Forwarder/Receiver Forwarder/Receiver decouples Inter Process Communication+ portability, modifiability wrt. network IPC+ marshalling/unmarshalling- modifiability wrt. re-configurations of networkAs forwarder is tightly coupled to receiver
30 Broker (Java RMI, .NET Remoting) Recipe:Take one forwarder/receiver and combine it with a client/dispatcher/serverAdd rules for marshalling, a request/reply protocol, definition of identity, and error handlingFry for half a minute in an IDL-to-code generatorSpice it up with some directory serviceServe it running
33 Summary As Broker shows, architectural patterns may be much more complex than design patternsinvolving a lot of sub-patterns, tools, protocols, constraintsdeal with problems a higher level of abstraction – more “architectural”much more restricted in its usage compared to design patterns
34 Surgical means for getting a quality TacticsSurgical means for getting a quality
35 Architectural Tactics A design decision that influences the control of a quality attribute responseE.g., Heartbeat to control availabilityArchitectural strategyCollection of tacticsCharacteristicsCapture what architects do in practiceTactics may refine other tacticsTactics may influence more than one quality attributeSince quality attributes are interdependent
41 Availability Tactics (2) Fault detectionPing/echoOne component pingsExpects response within predefined timeHeartbeat (dead man timer)One component emits heartbeat message periodicallyOther components listen for itOften carry payload (like T in TS-05)ExceptionsRaise exception when fault class is encounteredOmission, crash, timing, response faultFault recovery – repairVotingRedundant processes and processorsVoter process check responses – fail if deviantActive redundancy (hot restart)Maintain redundant, parallel componentsOnly use one responsePassive redundancy (warm restart)Primary component responds, informs standbys of updates to makeResume standby if primary failsSpareStandby computing platformBoot and initialize state when neededFault recovery – reintroductionShadow operationPreviously failed component runs in “shadow mode”Restore when sure that it worksState resynchronizationRedundancy requires restoring after downtimeCheckpoint/rollbackCreate checkpoint recording consistent state at points in timeRollback to previous checkpoint if inconsistent state detectedFault preventionRemoval from service(Periodically) remove component to prevent anticipated failureTransactionsBundling sequential stepsUndo all if necessaryGive examples of each!
42 POS Availability Scenarios ExerciseWhich tactics can be used to handle the scenarios?Are other tactics relevant to POS?
44 Modifiability Tactics (2) AssumptionRestricting modifications to small set of module will reduce cost of changeLocalize changesSemantic coherenceEnsure responsibilities of a module are coherentLow coupling + high coherence + measured against scenarios of changeAnticipate expected changesMake decomposition so that considered changes affect minimal number of modulesBased on assumptions of what changes will beGeneralize moduleMake module compute broader range of functionsE.g., constants -> input parametersLimit possible optionsReduce options for modificationsPrevention of ripple effectHide informationDecompose responsibilitiesChoose which to make public, hide othersMaintain existing interfaceMask variationsRestricts communication pathsRestrict the number of module with which a component shares dataUse an intermediaryCreate module handling dependencies between components (e.g., Adapter)Defer binding timeRuntime registrationConfiguration filesPolymorphismComponent replacementAdherence to defined protocolsGive examples of each!
45 POS Modifiability Scenario ExerciseWhich tactics can be used to handle the scenario?Are other tactics relevant to POS?
47 Performance Tactics (2) Resource DemandIncrease Computation EfficiencyBetter algorithms to reduce latencyReduce Computational OverheadAvoid intermediaries, communicate directly (tight coupling)Cmp adapters and other modifiability tacticsManage Event RateLower the rate of sampling of environmental variablesControl Frequency of SamplingUse queues to buffer external events, and sample this using a lower frequencyResource ManagementIntroduce ConcurrencyProcess requests in parallel, load balancingMaintain multiple copies of data or computationsCaching, dynamic programmingIncrease Available ResourcesFaster processors, additional processors, more memory, faster network, ...Resource ArbitrationScheduling PolicyFIFOFixed-priority schedulingDynamic priority schedulingStatic schedulingGive examples of each!
51 Testability Tactics (2) Manage Input/OutputRecord/PlaybackRecord information across an interface, using it later as input for test harnessSeparate Interface from ImplementationAllows replacing production units with test stubs (fakes, mock objects, spies)Specialized access routes/interfacesAdd accessors to internal state inspection for testing internal algorithmsKeep separate from production code interfacesInternal MonitoringBuilt-in MonitorsMaintain performance load, capacity, security information for inspectionTurn on/off using macros/aspect oriented techniquesMay influence results (monitoring takes time, increase resource demand, etc.)Give examples of each!
53 Usability Tactics (2) Separate User Interface Handle rapid changes in UI requirements(Modifiability tactics?)Support User InitiativeCancelUndoAggregateAllow user to make composite operationsShow multiple viewsSupport Systemt InitiativeUser ModelCollect data on usage to predict user behaviour and experienceTask ModelKnow the overall task to support users’ interaction with the invidiual stepsSystem ModelKnow state of system to report to userGive examples of each!
54 Discussion Tactics help make quality attribute decisions Does it make sense to divide tactics according to quality attributes – cf. interdependence?Do tactics make sense regardless of domain?Are the tactics really just design ideas?Cf. patterns…Bass’ list of tacticsIs it complete? What is the level of granularity? What is the quality of their presentation?