Software Architecture in Practice
description
Transcript of Software Architecture in Practice
![Page 1: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/1.jpg)
1
Software Architecturein
Practice
Architectural Design
![Page 2: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/2.jpg)
2
The bottom line
Bertrand 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...
![Page 3: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/3.jpg)
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 Buildability
Question: How do we then use this information to guide the design ???
Architectural Design ?
![Page 4: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/4.jpg)
4
Architectural design
The idealized process
Functional requirement
s
Functional requirement
s
Architectural qualities
Architectural qualities
Architectural Design
Proposals
Best Architecture
Code
ArchitecturalEvaluation
ArchitecturalDesign
![Page 5: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/5.jpg)
5
Architectural Design
The process of designing a software architecture that meets quality attribute requirements– And enables implementation of functional requirements
Characteristics of the process– Creative – Iterative (and incremental)
• Functional decomposition
• Quality decomposition
– Experimental• Architectural prototyping
– Based on experience• This lesson
![Page 6: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/6.jpg)
6
Overview
Architectural Styles– A vocabulary of large-scale structure
Architectural Patterns– Name, Problem, Solution, Consequences– Patterns = Styles?
Tactics– Surgical bits and pieces
![Page 7: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/7.jpg)
7
Architectural Style
![Page 8: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/8.jpg)
8
Architectural Style
An 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 patterns
– thereby delimits/spans a set of architectures– (also called architectural pattern )
Ex.: Client-Server
![Page 9: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/9.jpg)
9
The parts of a ’style’
Parts of a style– A set of component types with a given
role/functionality– A topology of relations (usually runtime relations) – A set of connectors (RMI, socket, memory, etc.) that
handle communication, coordination or collaboration.– A set of semantic constraints
• i.e. what can components/connectors do or not do?
![Page 10: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/10.jpg)
10
Exercise: Client-server
Component types?– categories of components
Topology?– (“the landscape” / set of relations)
Connectors?– what are the carriers of data- and control flow?
Semantic constraints?– what rule must the components/connectors obey?
![Page 11: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/11.jpg)
11
Why is it interesting?
Why are architectural styles / patterns interesting and important?
![Page 12: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/12.jpg)
12
Why is it interesting?
Because they
describe architectures with specific qualities
…and– document it– provides a vocabulary
![Page 13: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/13.jpg)
13
Classification in Bass
Independent Components– Event Systems– Communicating Processes
Data Flow– Batch sequential– Pipes and filters
Data-Centered– Repository– Blackboard
![Page 14: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/14.jpg)
14
Classification
Virtual Machine– Interpreter– Rule-based system
Call and Return– Layered– Object-oriented– Main program and subroutine
Heterogeneous styles– different styles mixed at different levels
![Page 15: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/15.jpg)
15
Data-centered
Repository and Blackboard
QA: Data integrability: clients are independent Exercise: Name some examples of systems
![Page 16: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/16.jpg)
16
Data-flow
Batch-sequential and Pipes-and-filters
QA: Modifiability, Reusability Exercise: Name some examples of systems
![Page 17: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/17.jpg)
17
Virtual machine
Interpreter Rule-based systems
QA: Portability Exercise: Name some examples of systems
![Page 18: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/18.jpg)
18
Call-and-Return
MPS style [OO style] Layered style
QA: Modifiability, Scalability (Layers:Portability)
![Page 19: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/19.jpg)
19
Independent components
Communicating processes– client-server is a prominent case
Event systems– publish-subscribe systems– message/channel based systems
QA: Modifiability (decouple sender and receiver)
![Page 20: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/20.jpg)
20
Heterogeneous styles
Most large systems use several styles in a mix The categories are not disjoint
Ex.: CORBA-based client-server– Object-oriented call-and-return– Layered– Independent components
![Page 21: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/21.jpg)
21
Summary
Architectural styles/patterns are proven templates for organizing components and connectors to achieve certain QA.
Can be classified– Data-flow– Data-centred– Communicating processes– Call and return
Most real architectures are mixes of styles.
![Page 22: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/22.jpg)
22
Architectural Patterns
Same wine on new bottles?
![Page 23: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/23.jpg)
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
![Page 24: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/24.jpg)
24
‘Alcoves’: One of Alexander’s patterns
179. Alcoves ** ... 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)
![Page 25: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/25.jpg)
25
Branding?
Buschmann et al. (1st ed)– Pattern-oriented software architecture
Patterns that are– more coarse-grained than design p.– more specific focus than design p.
Examples– Model-view-controller, Blackboard, Broker,
Forwarder/Receiver, ...
Two other volumes– concurrency, networking, resource management
![Page 26: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/26.jpg)
26
Forwarder/Receiver
Forwarder/Receiver
– decouples Inter Process Communication
– + portability, modifiability wrt. network IPC– + marshalling/unmarshalling– - modifiability wrt. re-configurations of network
• As forwarder is tightly coupled to receiver
![Page 27: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/27.jpg)
27
Forwarder/Receiver
![Page 28: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/28.jpg)
28
Client/Dispatcher/Server
Client/Dispatcher/Server
– provide location transparency
– + modifiability wrt. location– - performance – - does not encapsulate IPC– - no marshalling
![Page 29: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/29.jpg)
29
Client/Dispatcher/Server
![Page 30: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/30.jpg)
30
Broker (Java RMI, .NET Remoting)
Recipe:– Take one forwarder/receiver and combine it with a
client/dispatcher/server– Add rules for marshalling, a request/reply protocol,
definition of identity, and error handling– Fry for half a minute in an IDL-to-code generator– Spice it up with some directory service
– Serve it running
![Page 31: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/31.jpg)
31
Broker
![Page 32: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/32.jpg)
32
Discussion
Relate to
– CORBA
– TS-05
![Page 33: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/33.jpg)
33
Summary
As Broker shows, architectural patterns
– may be much more complex than design patterns• involving a lot of sub-patterns, tools, protocols, constraints
– deal with problems a higher level of abstraction – more “architectural”
– much more restricted in its usage compared to design patterns
![Page 34: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/34.jpg)
34
Tactics
Surgical means for getting a quality
![Page 35: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/35.jpg)
35
Architectural Tactics
Tactic– A design decision that
influences the control of a quality attribute response
– E.g., Heartbeat to control availability
Architectural strategy– Collection of tactics
Characteristics– Capture what architects do in
practice– Tactics may refine other
tactics– Tactics may influence more
than one quality attribute• Since quality attributes are
interdependent
![Page 36: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/36.jpg)
36
POS Revisited – Component and Connector View
![Page 37: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/37.jpg)
37
POS Revisited – Module View
(Revised compared to [Christensen et al, 2007])
User Interface
Domain Model
Technical Services
POS
![Page 38: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/38.jpg)
38
POS Revisited – Allocation View
![Page 39: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/39.jpg)
39
Categories of Tactics
Classified according to (main) quality attribute concern– Availability– Modifiability– Performance– Security– Testability– Usability
![Page 40: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/40.jpg)
40
Availability Tactics (1)
![Page 41: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/41.jpg)
41
Availability Tactics (2)
Fault detection– Ping/echo
• One component pings• Expects response within predefined time
– Heartbeat (dead man timer)• One component emits heartbeat message
periodically• Other components listen for it• Often carry payload (like T in TS-05)
– Exceptions• Raise exception when fault class is encountered• Omission, crash, timing, response fault
Fault recovery – repair – Voting
• Redundant processes and processors• Voter process check responses – fail if deviant
– Active redundancy (hot restart)• Maintain redundant, parallel components• Only use one response
– Passive redundancy (warm restart)• Primary component responds, informs standbys
of updates to make• Resume standby if primary fails
– Spare• Standby computing platform• Boot and initialize state when needed
Fault recovery – reintroduction – Shadow operation
• Previously failed component runs in “shadow mode”
• Restore when sure that it works– State resynchronization
• Redundancy requires restoring after downtime– Checkpoint/rollback
• Create checkpoint recording consistent state at points in time
• Rollback to previous checkpoint if inconsistent state detected
Fault prevention– Removal from service
• (Periodically) remove component to prevent anticipated failure
– Transactions• Bundling sequential steps• Undo all if necessary
Give examples of each!
![Page 42: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/42.jpg)
42
POS Availability Scenarios
Exercise– Which tactics
can be used to handle the scenarios?
– Are other tactics relevant to POS?
POS – Quality Attribute Scenario 1
Scenario(s): The barcode scanner fails; failure is detected, signalled to user at terminal; continue in degraded mode
Relevant Quality Attributes: Availability
Stimulus Source: Internal to system
Stimulus: Fails
Environment: Normal operation
Artefact (If Known): Barcode scanner
Response: Failure detected, shown to user, continue to operate
Scen
ario
Com
pone
nts
Response Measure: No downtime
React in 2 seconds
POS – Quality Attribute Scenario 2
Scenario(s): The inventory system fails and the failure is detected. The system continues to operate and queue inventory requests internally; issue requests when inventory system is running again
Relevant Quality Attributes: Availability
Stimulus Source: Internal to system
Stimulus: Fails
Environment: Normal operation
Artefact (If Known): Inventory system
Response: Failure detected, operates in degraded mode, queues requests
Detects when inventory system is up again
Scen
ario
Com
pone
nts
Response Measure: Degraded mode is entered for maximum one hour
![Page 43: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/43.jpg)
43
Modifiability Tactics (1)
![Page 44: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/44.jpg)
44
Modifiability Tactics (2)
Assumption– Restricting modifications to small set of
module will reduce cost of change Localize changes
– Semantic coherence• Ensure responsibilities of a module are
coherent• Low coupling + high coherence +
measured against scenarios of change– Anticipate expected changes
• Make decomposition so that considered changes affect minimal number of modules
• Based on assumptions of what changes will be
– Generalize module• Make module compute broader range
of functions• E.g., constants -> input parameters
– Limit possible options• Reduce options for modifications
Prevention of ripple effect– Hide information
• Decompose responsibilities• Choose which to make public, hide
others– Maintain existing interface
• Mask variations– Restricts communication paths
• Restrict the number of module with which a component shares data
– Use an intermediary• Create module handling dependencies
between components (e.g., Adapter)
Defer binding time– Runtime registration– Configuration files– Polymorphism– Component replacement– Adherence to defined protocols
Give examples of each!
![Page 45: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/45.jpg)
45
Exercise– Which tactics
can be used to handle the scenario?
– Are other tactics relevant to POS?
POS – Quality Attribute Scenario 3
Scenario(s): The POS system should be extended to handle “supermarket” domains as well as “small shop” domains
Relevant Quality Attributes: Modifiability
Stimulus Source: Developers
Stimulus: Wants to change domain of POS
Environment: Development time
Artefact (If Known): POS system
Response: Domain is changed
Scen
ario
Com
pone
nts
Response Measure: Cost of change is “reasonable”
POS Modifiability Scenario
![Page 46: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/46.jpg)
46
Performance Tactics (1)
![Page 47: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/47.jpg)
47
Performance Tactics (2)
Resource Demand– Increase Computation Efficiency
• Better algorithms to reduce latency– Reduce Computational Overhead
• Avoid intermediaries, communicate directly (tight coupling)
• Cmp adapters and other modifiability tactics
– Manage Event Rate• Lower the rate of sampling of
environmental variables– Control Frequency of Sampling
• Use queues to buffer external events, and sample this using a lower frequency
Resource Management– Introduce Concurrency
• Process requests in parallel, load balancing
– Maintain multiple copies of data or computations
• Caching, dynamic programming
– Increase Available Resources• Faster processors, additional
processors, more memory, faster network, ...
Resource Arbitration– Scheduling Policy
• FIFO • Fixed-priority scheduling• Dynamic priority scheduling• Static scheduling
Give examples of each!
![Page 48: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/48.jpg)
48
POS Performance Scenario
POS – Quality Attribute Scenario 4
Scenario(s): The POS system scans a new item, item is looked up, total price updated within two seconds
Relevant Quality Attributes: Performance
Stimulus Source: End user
Stimulus: Scan item, fixed time between events for limited time period
Environment: Development time
Artefact (If Known): POS system
Response: Item is looked up, total price updated
Scen
ario
Com
pone
nts
Response Measure: Within two seconds
![Page 49: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/49.jpg)
49
Security Tactics
![Page 50: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/50.jpg)
50
Testability Tactics
![Page 51: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/51.jpg)
51
Testability Tactics (2)
Manage Input/Output– Record/Playback
• Record information across an interface, using it later as input for test harness
– Separate Interface from Implementation
• Allows replacing production units with test stubs (fakes, mock objects, spies)
– Specialized access routes/interfaces• Add accessors to internal state inspection for
testing internal algorithms• Keep separate from production code interfaces
Internal Monitoring– Built-in Monitors
• Maintain performance load, capacity, security information for inspection
• Turn on/off using macros/aspect oriented techniques
• May influence results (monitoring takes time, increase resource demand, etc.)
Give examples of each!
![Page 52: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/52.jpg)
52
Usability Tactics
![Page 53: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/53.jpg)
53
Usability Tactics (2)
Separate User Interface– Handle rapid changes in UI
requirements– (Modifiability tactics?)
Support User Initiative– Cancel– Undo– Aggregate
• Allow user to make composite operations
– Show multiple views
Support Systemt Initiative– User Model
• Collect data on usage to predict user behaviour and experience
– Task Model• Know the overall task to support users’
interaction with the invidiual steps
– System Model• Know state of system to report to user
Give examples of each!
![Page 54: Software Architecture in Practice](https://reader033.fdocuments.net/reader033/viewer/2022061603/56813a0e550346895da1e2aa/html5/thumbnails/54.jpg)
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 tactics– Is it complete? What is the level of granularity? What
is the quality of their presentation?