modularization & software architectures€¦ · essential concepts for architecture analysis...
TRANSCRIPT
Vorlesung Software Engineering IWintersemester 2002/03
Universität Salzburg
O.Univ.-Prof. Dipl.-Ing. Dr.techn. Wolfgang Pree© Copyright Wolfgang Pree, All Rights Reserved
MMMMoooodddduuuullllaaaarrrriiiizzzzaaaattttiiiioooonnnn &&&&
SSSSooooffffttttwwwwaaaarrrreeee AAAArrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeeessssUniversität
Salzburg
Permission to make digital or hard copies of all or part of this work for personal or classroom use is grantedwithout fee provided that copies are not made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, or to republish, to post on servers or toredistribute to lists, requires prior specific permission and/or a fee.
© 2002, W. Pree 2
Context
� Motivation & basic terminology
� Essential concepts for architecture analysis� Architectural styles
� Architecture description
� (Re)design strategies for (OO) architectures
� Architecture analysis� SAAM (Software Architecture Analysis Method)
� ATAM (Architecture Tradeoff Analysis Method)
� Analysis for rearchitecting legacy systems
© 2002, W. Pree 3
Motivation &basic terminology
© 2002, W. Pree 4
Definition of software architecture (I)
Software architecture :=
software components +
the relationships among them
� top-level design of a system
� identification of core subsystems/abstractions
© 2002, W. Pree 5
Definition of softwarearchitecture (II)
closely related terms/concepts:� domain-specific software architectures, frameworks,
product lines (→→→→ reusable architectures)
� architectural styles
� design patterns (some of the GoF patterns focus on architecture, eg, Facade, Mediator)
� component-based software
© 2002, W. Pree 6
Benefits of architecture analysis
� Communication among stakeholders based on an explicitdescription of high-level abstractions of the system underdevelopment
� Early design decisions, influenced by driving qualityattributes.
� Transferable abstraction of a system; can promote large-scale reuse.
© 2002, W. Pree 7
Essential concepts forarchitecture analysis� Architectural styles� Architecture description� (Re)design strategies for (OO)
architectures
© 2002, W. Pree 8
Architectural styles
© 2002, W. Pree 9
AAAArrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeee ddddeeeessssccccrrrriiiippppttttiiiioooonnnn bbbbaaaasssseeeedddd oooonnnn
aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrraaaallll ssssttttyyyylllleeeessss ****))))
� Data-centered:� Repository
� Blackboard
� Data-flow:� Pipes & filters
� Batch/sequential
� Call-and-return:� Top down
� OO
� layered
» Virtual machine:– Interpreter
– Rule-based
» Independentcomponents:
– Communicatingprocesses
– Event systems
– implicitinvocation
– explicitinvocation
*) The presentation is based on Software Architecture in Practice (Bass et al.; Addison-Wesley, 1998) and Software Architecture: Perespectives on an Emerging Discipline (Shaw, Garlan; Prentice Hall, 1996)
© 2002, W. Pree 10
SSSSaaaammmmpppplllleeee aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrraaaallll ssssttttyyyylllleeee::::
DDDDaaaattttaaaa----cccceeeennnntttteeeerrrreeeedddd ((((IIII))))
Access to shared data represents the core characteristic ofdata-centered architectures. The data integrability forms theprincipal goal of such systems.
Shared Data
Client Client
passive data
computationalcomponent / object
data flow
Legend:
© 2002, W. Pree 11
SSSSaaaammmmpppplllleeee aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrraaaallll ssssttttyyyylllleeee::::
DDDDaaaattttaaaa----cccceeeennnntttteeeerrrreeeedddd ((((IIIIIIII))))
The means of communication between the componentsdistinguishes the subtypes of the data-centered architecturalstyle:
� Repository: passive data (see schematic representationof previous slide)
� Blackboard: active dataA blackboard sends notification to subscribers whenrelevant data change (→ Observer pattern)
© 2002, W. Pree 12
SSSSaaaammmmpppplllleeee aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrraaaallll ssssttttyyyylllleeee::::
DDDDaaaattttaaaa----cccceeeennnntttteeeerrrreeeedddd ((((IIIIIIIIIIII))))
+ clients are quite independent of each other=> clients can be modified without affecting others
coupling between clients might increase performance butlessen this benefit
+ new clients can be easily added
No rigid separation of styles: When clients are independentlyexecuting processes: client/server architectural style
© 2002, W. Pree 13
SSSSaaaammmmpppplllleeee aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrraaaallll ssssttttyyyylllleeee::::
DDDDaaaattttaaaa----fffflllloooowwww
The system consists of a series of transformations on successive piecesof (input) data.
Reuse and modifiability form the principal goals of such architectures.
� Batch sequential� Pipe-and-filter (→ incremental)
Validate Sort ReportTape Tape Tape Page
© 2002, W. Pree 14
Architecturedescription
© 2002, W. Pree 15
AAAArrrrcccchhhhiiiitttteeeeccccttttuuuurrrraaaallll ssssttttyyyylllleeeessss aaaarrrreeee oooofffftttteeeennnn iiiinnnnssssuuuuffffffffiiiicccciiiieeeennnntttt
ttttoooo ddddeeeessssccccrrrriiiibbbbeeee aaaa ssssyyyysssstttteeeemmmm‘‘‘‘ssss aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeee
Architectural styles do not clearly categorize architectures. Thusthey do not suffice to describe architectures as a whole.
Consider the following sample cases:
� The layers in a layered architecture might be objects/ADTs.
� Commercial client/server systems with a CORBA-basedinfrastructure could be described as layered object-basedprocess systems, i.e., a hybrid of three styles.
© 2002, W. Pree 16
Choose an appropriate mix of variousnotations + informal description
As a consequence, one has to decide on the appropriate description, whichwill be a mix of the following principal options:
� schematic representation according to CMU/SEI
� 4+1 View Model of Architecture (Kruchten , 1995)
� UML:� subsystem/package-diagrams
� class-diagrams
� interaction-/object-diagrams
� state-diagrams
� any schematic figures that help; informal text as glue
� source code fragments of coarse-grained components orcomponent interfaces
� formal specifications, eg, with architecture description languages
© 2002, W. Pree 17
Sample architectural description ofJavaSpaces
JavaSpaces characteristics (from an architecturalpoint of view):
� data-centered, mainly a repositoryarchitectural style, sometimes black-boardarchitectural style
� main design goals� extensibility through loose coupling of distributed
processes and distributed Java components
� simplicity from a reuser‘s point of view
© 2002, W. Pree 18
JavaSpaces architectureoverview
write
write
take
read
read (waiting)
© 2002, W. Pree 19
Characteristics of JavaSpaces (JS)
� high-level coordination tool for gluing processes andcomponents together in a distributed system without messagepassing and remote method invocation
� a space is a shared, network-accessible repository forobjects
� instead of communicating directly, JS apps consist of processesthat coordinate by exchanging objects through spaces
© 2002, W. Pree 20
Sample JS use scenarios (I)
Example isn‘t another way to teach, it is the only way toteach (Albert Einstein)
(1) Space acting as “auction room“:
Sellers deposit for-sale items with descriptions and askingprices as objects into the space.
Buyers monitor the space for items that interest them. Ifan item interest them they put bid objects into the space.
Sellers monitor the space for bids.
etc.
© 2002, W. Pree 21
Sample JS use scenarios (II)
(2) Compute-intensive jobs
A series of tasks—for example, rendering a frame in acomputer animation represents a task—are written into aspace.
Participating graphic workstations search the space forrendering tasks. Each one finding tasks to be done,removes it, accomplishes it, writes the result back into thespace.
© 2002, W. Pree 22
Interfaces of JS key abstractions
and their usage
The rest of the architecture description could be a seriesof documented source code and commented UML classand interaction diagrams that illustrate the simplicity ofreusing the JS architecture.
public calls SampleMsg implements Entry { // empty JS interface
...
}
// putting an object into a space
SampleMsg msg= new SampleMsg();
JavaSpace space= SpaceAccessor.getSpace();
space.write(msg, ...); // other parameters omitted...
© 2002, W. Pree 23
(Re)design strategiesfor (OO) architectures
© 2002, W. Pree 24
DDDDeeeessssiiiiggggnnnn ssssttttrrrraaaatttteeeeggggiiiieeeessss sssshhhhoooouuuulllldddd hhhheeeellllpppp ttttoooo iiiimmmmpppprrrroooovvvveeee tttthhhheeee qqqquuuuaaaalllliiiittttyyyy ooooffff
aaaa((((nnnn OOOOOOOO)))) ssssooooffffttttwwwwaaaarrrreeee aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeee ddddeeeeppppeeeennnnddddiiiinnnngggg oooonnnn tttthhhheeee
ddddrrrriiiivvvviiiinnnngggg qqqquuuuaaaalllliiiittttyyyy aaaattttttttrrrriiiibbbbuuuutttteeeessss
� Check an architecture’s decomposition intomodules/components/objects
� Check the variation points of an object-orientedframework architecture
© 2002, W. Pree 25
AAAApppppppprrrroooopppprrrriiiiaaaatttteeee mmmmoooodddduuuullllaaaarrrriiiizzzzaaaattttiiiioooonnnn iiiinnnn tttthhhheeeeoooorrrryyyy ((((IIII))))
Balance between
� maximizing the cohesion within a component
� minimizing the coupling between components
One module =>coupling = 0cohesion → max
Each operation in a separate module =>coupling → max
cohesion = 0
complexity
number of modules
coupling
cohesion
overall complexity
© 2002, W. Pree 26
AAAApppppppprrrroooopppprrrriiiiaaaatttteeee mmmmoooodddduuuullllaaaarrrriiiizzzzaaaattttiiiioooonnnn iiiinnnn tttthhhheeeeoooorrrryyyy ((((IIIIIIII))))
� Balanced distribution of responsibilities betweencomponents
� Minimal interface of a component (increases couplingwithin a component)
� tight relationship between instance variables andmethods
� no redundant methods/procedures
� small number of parameters
� expressive and consistent naming
� no global data
© 2002, W. Pree 27
HHHHoooowwww ccccaaaannnn tttthhhheeee tttthhhheeeeoooorrrryyyy bbbbeeee aaaapppppppplllliiiieeeedddd ttttoooo OOOOOOOO
ssssyyyysssstttteeeemmmmssss????
SAAM focuses on cohesion and coupling from the point of view ofrelevant quality attributes.
In the following we consider some concepts and rules of thumbfor an analysis of
� the coarse-grained design of class hierarchies
� coupling/interaction between components
� cohesion within a component
� evolution of class hierarchies
� a framework‘s variation points
© 2002, W. Pree 28
CCCCooooaaaarrrrsssseeee----ggggrrrraaaaiiiinnnneeeedddd ddddeeeessssiiiiggggnnnn ooooffff ccccllllaaaassssssss hhhhiiiieeeerrrraaaarrrrcccchhhhiiiieeeessss ((((IIII))))
Classes represent the basic units for structuring OOsystems. Software architects group them in families,teams and subsystems.
Class families� based on abstract classes/interfaces� Container classes (abstract class Container)� GUI components (abstract class Component)
� bottom-up or top-down development of families� roots of class families should be light-weight, ie,
avoid data representations
© 2002, W. Pree 29
CCCCooooaaaarrrrsssseeee----ggggrrrraaaaiiiinnnneeeedddd ddddeeeessssiiiiggggnnnn ooooffff ccccllllaaaassssssss hhhhiiiieeeerrrraaaarrrrcccchhhhiiiieeeessss ((((IIIIIIII))))
Class teams� consist of several cooperating families� ET++: Text team consisting of Text, TextView
andTextFormatter families
� Container and Iterator families form a team
� reused as a whole
� abstractly coupled => avoidance of tight coupling
© 2002, W. Pree 30
CCCCooooaaaarrrrsssseeee----ggggrrrraaaaiiiinnnneeeedddd ddddeeeessssiiiiggggnnnn ooooffff ccccllllaaaassssssss
hhhhiiiieeeerrrraaaarrrrcccchhhhiiiieeeessss ((((IIIIIIIIIIII))))
Subsystemsexplicit encapsulation of a class team→ Facade pattern� reduces coupling between specific classes of teams
� definition of an additional abstraction to make reuse easierfor clients
subsystem
clients
© 2002, W. Pree 31
RRRReeeedddduuuucccciiiinnnngggg tttthhhheeee ccccoooouuuupppplllliiiinnnngggg bbbbeeeettttwwwweeeeeeeennnn
ccccoooommmmppppoooonnnneeeennnnttttssss tttthhhhrrrroooouuuugggghhhh mmmmeeeeddddiiiiaaaattttoooorrrrssss
Mediator pattern effect: components can more likely bereused independently of each other:
M
© 2002, W. Pree 32
EEEEnnnnssssuuuurrrriiiinnnngggg ccccoooohhhheeeessssiiiioooonnnn wwwwiiiitttthhhhiiiinnnn aaaa
ccccoooommmmppppoooonnnneeeennnntttt
In order to test that property asking the followingquestions is helpful:� Can a component be
� understood� tested
without knowing its embedding in a software system? Example: modularization of an OO discrete event
simulation system
� Does a component have side effects on othercomponents?
© 2002, W. Pree 33
EEEEvvvvoooolllluuuuttttiiiioooonnnn ooooffff ccccllllaaaassssssss hhhhiiiieeeerrrraaaarrrrcccchhhhiiiieeeessss ((((IIIIIIII))))
Vertical reorganizations:
� moving common properties/protocols/parameter classes upthe class hierarchy
� splitting up an overly complex class into a class family
� avoiding the overriding of too many specific methods byadding abstract classes
Horizontal reorganizations:
� splitting up a class with too many responsibilities into a classteam/subsystem
� moving features into strategy classes (→ Strategy/Bridgepattern)
© 2002, W. Pree 34
WWWWhhhhyyyy aaaannnnaaaallllyyyyzzzzeeee vvvvaaaarrrriiiiaaaattttiiiioooonnnn ppppooooiiiinnnnttttssss
ooooffff ffffrrrraaaammmmeeeewwwwoooorrrrkkkkssss????
How can one assess the quality of an OOframework architecture?Striving for flexibility for the flexibility’s sake—by incorporatingas many patterns as possible—produces an overly complexframework.
� Flexibility of has to be given in the right dosis
� Variation point identification should be an explicitactivity in the framework development process and in aframework analysis
© 2002, W. Pree 35
HHHHoooowwww ttttoooo ccccaaaappppttttuuuurrrreeee vvvvaaaarrrriiiiaaaattttiiiioooonnnn
ppppooooiiiinnnnttttssss
Variation points can either correspond to� functionality (→→→→ hook methods) or to
� domain abstractions (→ abstract classes/interfaces).
Layout of a (function) variation point card:
Variation point name
general description of semantics
sketch variation point behavior inat least two specific situations
specify degree of flexibility:
adaptation by end user
adaptation without restart
© 2002, W. Pree 36
VVVVaaaarrrriiiiaaaattttiiiioooonnnn ppppooooiiiinnnntttt ddddeeeessssccccrrrriiiippppttttiiiioooonnnn
Sample (function) variation point in a reservation framework architecture:
rate calculation when rental items are returned;the calculation is based on application-specificparameters
Rate calculation
hotel system: calculation results from theroom rate * number of nights + telephonecalls + mini bar consumption
car rental system: calculation results fromthe car type rate * number of days + probablyrate per mile * (driven miles - free miles) +price for refilling + rate for rented extras suchas a cell telephone.
specify degree of flexibility:
adaptation by end user
adaptation without restart
© 2002, W. Pree 37
TTTTrrrraaaannnnssssffffoooorrrrmmmmaaaattttiiiioooonnnn hhhheeeeuuuurrrriiiissssttttiiiiccccssss rrrreeeessssuuuullllttttiiiinnnngggg
ffffrrrroooommmm vvvvaaaarrrriiiiaaaattttiiiioooonnnn ppppooooiiiinnnntttt aaaannnnaaaallllyyyyssssiiiissss
without restart by end user object modeltransformation
– – additional hook method(Unification pattern)
– additional hook method inseparate hook class
(Separation pattern)– additional hook method +
configuration tool
additional hook method inseparate hook class +
configuration tool
© 2002, W. Pree 38
SSSSaaaammmmpppplllleeee ccccllllaaaassssssss hhhhiiiieeeerrrraaaarrrrcccchhhhyyyy ttttrrrraaaannnnssssffffoooorrrrmmmmaaaattttiiiioooonnnn
bbbbaaaasssseeeedddd oooonnnn vvvvaaaarrrriiiiaaaattttiiiioooonnnn ppppooooiiiinnnntttt aaaannnnaaaallllyyyyssssiiiissss
The rate calculation variation point could imply a horizontaltransformation of a class hierarchy from the Unificationpattern to the Separation/Bridge pattern and vice versa:
...
RentalItem
printOffer()...
printInvoice()calcRate(): double
...
...= calcRate();
...
...
...= calculator.calcRate(this);
...
calculator: RateCalculator
RentalItem
printOffer()...
printInvoice()
...
1 1...
RateCalculator
...
calcRate(r: RentalItem): double
. . .
© 2002, W. Pree 39
HHHHiiiinnnnttttssss ffffoooorrrr ffffiiiinnnnddddiiiinnnngggg////aaaannnnaaaallllyyyyzzzziiiinnnngggg
vvvvaaaarrrriiiiaaaattttiiiioooonnnn ppppooooiiiinnnnttttssss
In practice, domain experts are not used to answering questionsregarding generic solutions.
Ways to overcome this obstacle:
� take a look at maintenance—rank the costs associated with systemchanges
� investigate scenarios/use cases and check their flexibility requirements
� ask the right people :–)
© 2002, W. Pree 40
Architecture analysis:– The SAAM
– ATAM
© 2002, W. Pree 41
When and Why To AnalyzeArchitecture -1
� Analyzing for system qualities early in the life cycle allows for acomparison of architectural options.
� When building a system� Architecture is the earliest artifact where trade-offs are
visible.� Analysis should be done when deciding on architecture.� The reality is that analysis is often done during damage
control, later in the project.
© 2002, W. Pree 42
When and Why To AnalyzeArchitecture -2.
� When acquiring a system� Architectural analysis is useful if the system will
have a long lifetime within organization.� Analysis provides a mechanism for
understanding how the system will evolve.� Analysis can also provide insight into other
visible qualities.
© 2002, W. Pree 43
Qualities Are Too Vague forAnalysis
� Is the following system modifiable?� Background color of the user interface is changed
merely by modifying a resource file.� Dozens of components must be changed to
accommodate a new data file format.
� A reasonable answer is
� yes with respect to changing background color
� no with respect to changing file format
© 2002, W. Pree 44
Qualities Are Too Vague forAnalysis
� Qualities only have meaning within a context.
� SAAM specifies context through scenarios.
© 2002, W. Pree 45
Scenarios
� A scenario is a brief description of a stakeholder’sinteraction with a system.
� When creating scenarios, it is important to consider allstakeholders, especially
� end users
� developers
� maintainers
� system administrators
© 2002, W. Pree 46
Steps of a SAAM Evaluation
� Identify and assemble stakeholders
� Develop and prioritize scenarios
� Describe candidate architecture(s)
� Classify scenarios as direct or indirect
� Perform scenario evaluation
� Reveal scenario interactions
� Generate overall evaluation
© 2002, W. Pree 47
Step 1: Identify and AssembleStakeholders -1
Stakeholder InterestCustomer Schedule and budget; usefulness of system; meeting customers’ (or
market’s) expectationsEnd user Functionality, usabilityDeveloper Clarity and completeness of
architecture; high cohesion and limited coupling of parts; clear interaction mechanisms
Maintainer Maintainability; ability to locate places of change
© 2002, W. Pree 48
Step 1: Identify and AssembleStakeholders -2
Stakeholder InterestSystem Ease in finding sources ofadministrator operational problemsNetwork Network performance,
administrator predictability
Integrator Clarity and completeness of architecture; high cohesion and limited coupling of parts; clear interaction mechanisms
© 2002, W. Pree 49
Step 1: Identify and AssembleStakeholders -3.
Stakeholder InterestTester Integrated, consistent error-handling;
limited component coupling;high component cohesion;conceptual integrityApplication Architectural clarity, completeness;builder (if interaction mechanisms; simpleproduct line tailoring mechanismsarchitecture)Representative Interoperabilityof the domain
© 2002, W. Pree 50
Step 2: Stakeholders Developand Prioritize Scenarios
� Scenarios should be typical of the kinds ofevolution that the system must support:� functionality� development activities� change activities
� Scenarios also can be chosen to give insight intothe system structure.
� Scenarios should represent tasks relevant to allstakeholders.
� Rule of thumb: 10-15 prioritized scenarios
© 2002, W. Pree 51
Step 3: Describe CandidateArchitectures
� It is frequently necessary to elicit appropriatearchitectural descriptions.
� Structures chosen to describe the architecture willdepend on the type of qualities to be evaluated.
� Code and functional structures are primarily usedto evaluate modification scenarios.
© 2002, W. Pree 52
Step 4: Classify Scenarios
� There are two classes of scenarios.� Direct scenarios are those that can be executed by
the system without modification.� Indirect scenarios are those that require
modifications to the system.� The classification depends upon both the scenario and
the architecture.� For indirect scenarios we gauge the order of difficulty
of each change: e.g. a person-day, person-week,person-month, person-year.
© 2002, W. Pree 53
Step 5: Perform ScenarioEvaluation
� For each indirect scenario� identify the components, data connections,
control connections, and interfaces that must beadded, deleted, or modified
� estimate the difficulty of modification� Difficulty of modification is elicited from the
architect and is based on the number ofcomponents to be modified and the effect of themodifications.
� A monolithic system will score well on this step, butnot on next step.
© 2002, W. Pree 54
Step 6: Reveal ScenarioInteractions
� When multiple indirect scenarios affect the samecomponents, this could indicate a problem.
� could be good, if scenarios are variants of each other
� change background color to green
� change background color to red
� could be bad, indicating a potentially poor separation ofconcerns
� change background color to red
� port system to a different platform
© 2002, W. Pree 55
Step 7: Generate OverallEvaluation
� Not all scenarios are equal.
� The organization must determine which scenarios aremost important.
� Then the organization must decide as to whether thedesign is acceptable “as is” or if it must be modified.
© 2002, W. Pree 56
Interaction of SAAM Steps
classificationof scenarios
individualevaluationof indirectscenarios
assessmentof scenariointeraction
overallevaluation
scenariodevelopmentarchitecturedescription
© 2002, W. Pree 57
Example: SAAM Applied toRevision Control System
� “WRCS” is a large, commercially-available revisioncontrol system.
� No documented system architecture existed prior to theevaluation.
� The purpose of the evaluation was to assess the impactof anticipated future changes.
� Three iterations were required to develop a satisfactoryrepresentation, alternating between� development of scenarios� representation of architecture
© 2002, W. Pree 58
Architectural Representation ofWRCS
visdiffctrls
win31
OWLfmext
fntext
main
report
wrcs hook
bcext
mcext
vbext
pvcs2rcs
sccs2rcs
msarn200
make
diff
diff
bindiff
nwcalls
nwspxipx
nwnim
© 2002, W. Pree 59
Scenarios Used in WRCS
� User scenarios
� compare binary file representations
� configure the product’s toolbar
� Maintainer
� port to another operating system
� make minor modifications to the user interface
� Administrator
� change access permissions for a project
� integrate with a new development environment
© 2002, W. Pree 60
Scenario Classification
� User scenarios� compare binary file representations: indirect� configure the product’s toolbar: direct
� Maintainer� port to another operating system: indirect� make minor modifications to the user interface:
indirect� Administrator
� change access permissions for a project: direct� integrate with a new development environment:
indirect
© 2002, W. Pree 61
Scenario Interactions
� Each indirect scenario necessitated a change in somemodules. This can be represented either tabularly orvisually.
� The number of scenarios that affected each module canbe shown with a table or graphically, with a fish-eye view.
� A fish-eye view uses size to represent areas of interest.
© 2002, W. Pree 62
Scenario Interaction Table
Module No. changesmain 4wrcs 7diff 1bindiff 1pvcs2rcs 1sccs2rcs 1nwcalls 1nwspxipx 1nwnlm 1hook 4report 1visdiff 3ctrls 2
© 2002, W. Pree 63
Scenario Interaction Fish-Eye
visdiffctrls
fmext
fntext
wwwwrrrrccccssss hook
pvcs2rcs
sccs2rcs
msarn200
make
diff
diff
bindiff
nwcalls
nwspxipx
win31
OWL
bcext
mcext
vbext
nwnim
report
main
© 2002, W. Pree 64
Lessons Learned from WRCS
� Granularity of architectural description
� Interpretation of scenario interactions
© 2002, W. Pree 65
Proper Granularity ofArchitectural Description
� The level of detail of architectural description isdetermined by the scenarios chosen.
� The next slide shows what an architect thought was anappropriate level of detail.
� Components are annotated with the numbers of indirectscenarios that affect them.
© 2002, W. Pree 66
Original Representation ofWRCS
visdiff11
11
diff
msarn20012
make12
11,12
ctrls
main11,12,13
report13
fmext13
fntext13
© 2002, W. Pree 67
The “main” ScenarioInteractions
� Possibilities:� Scenarios are all
of the same class.� Scenarios are of
different classesand “main” cannotbe subdivided.
� Scenarios are ofdifferent classes,and “main” can besubdivided.
visdiff11
11diff
msarn20012
make12
11,12
ctrls
main11,12,13
report13
fmext13
fntext13
main111
main212
main313
© 2002, W. Pree 68
WRCS: What did we learn?
� We identified severe limitations in achieving the desiredportability and modifiability. A major system redesignwas recommended.
� The evaluation itself obtained mixed results.� Senior developers/managers found it important and
useful.� Developers regarded this as just an academic
exercise.� SAAM allowed insight into capabilities and limitations
that weren’t easily achieved otherwise.� This was accomplished with only scant knowledge of the
internal workings of WRCS.
© 2002, W. Pree 69
Lessons from SAAM -1
� Direct scenarios provide a� first-order differentiation mechanism for
competing architectures� mechanism for eliciting and understanding
structures of architectures (both static anddynamic)
� It is important to have stakeholders present atevaluation meetings.� Stakeholders find it to be educational.� Architectural evaluators may not have the
experience to keep presenters “honest.”
© 2002, W. Pree 70
Lessons from SAAM -2.
� SAAM and traditional architectural metrics� Coupling and cohesion metrics do not represent
different patterns of use.� High scenario interaction shows low cohesion.� A scenario with widespread hits shows high coupling.� Both are tied to the context of use.� SAAM provides a means of sharpening the use of
coupling and cohesion metrics.
© 2002, W. Pree 71
Summary
� A SAAM evaluation produces
� technical results: provides insight into systemcapabilities
� social results
� forces some documentation of architecture
� acts as communication vehicle amongstakeholders
© 2002, W. Pree 72
Architecture analysis:The ATAM
© 2002, W. Pree 73
� Why analyze an architecture?
� ATAM Steps
� An example
� Summary and Status
Outline
© 2002, W. Pree 74
Why Analyze an Architecture?
� All design involves tradeoffs.
� A software architecture is the earliest life-cycle artifactthat embodies significant design decisions: choices andtradeoffs.
© 2002, W. Pree 75
The ATAM
� We have been developing the Architecture TradeoffAnalysis Method (ATAM) for over two years.
� The purpose of ATAM is: to assess the consequences ofarchitectural decision alternatives in light of qualityattribute requirements.
© 2002, W. Pree 76
Purpose of ATAM - 1
� We need a method in which the right questions areasked early to:� Discover risks -- alternatives that might create future
problems in some quality attribute
� Discover sensitivity points -- alternatives for which aslight change makes a significant difference in somequality attribute
� Discover tradeoffs -- decisions affecting more thanone quality attribute
© 2002, W. Pree 77
Purpose of ATAM - 2.
� The purpose of an ATAM is NOT to provide preciseanalyses . . . the purpose IS to discover risks created byarchitectural decisions.
� We want to find trends: correlation between architecturaldecisions and predictions of system properties.
� Discovered risks can then be made the focus ofmitigation activities: e.g. further design, further analysis,prototyping.
© 2002, W. Pree 78
ATAM Benefits
� There are a number of benefits from performing ATAManalyses:
� Clarified quality attribute requirements
� Improved architecture documentation
� Documented basis for architectural decisions
� Identified risks early in the life-cycle
� Increased communication among stakeholders
� The results are improved architectures.
© 2002, W. Pree 79
� Why analyze an architecture?
� ATAM Steps
� An example
� Summary and Status
Outline
© 2002, W. Pree 80
ATAM Steps
� 1. Present ATAM
� 2. Present business drivers� 3. Present architecture
� 4. Identify architectural styles� 5. Generate quality attribute utility tree
� 6. Elicit and analyze architectural styles
� 7. Generate seed scenarios� 8. Brainstorm and prioritize scenarios
� 9. Map scenarios onto styles
� 10. Present out-brief and/or write report
ATAM Steps
© 2002, W. Pree 81
1. Present ATAM
� Evaluation Team presents an overview of ATAM including:� ATAM steps in brief� techniques
� utility tree generation� style-based elicitation/analysis� scenario brainstorming/mapping
� outputs� scenarios� architectural styles� quality attribute questions� risks and “non-risks� utility tree
Presentation
© 2002, W. Pree 82
2. Present Business Drivers
� ATAM customer representative describes thesystem’s business drivers including:
� business context for the system
� high-level functional requirements
� high-level quality attribute requirements
� architectural drivers: quality attributes that“shape” the architecture
� critical requirements: quality attributes mostcentral to the system’s success
Presentation
© 2002, W. Pree 83
3. Present Architecture
� Architect presents an overview of thearchitecture including:
� technical constraints such as an OS, hardware,or middle-ware prescribed for use
� other systems with which the system mustinteract
� architectural approaches used to meet qualityattribute requirements
� Evaluation team begins probing for:
� risks� architectural styles
Presentation
© 2002, W. Pree 84
� High-level overview of architecture is completed byitemizing architectural styles found in the architecture.
� Examples:
� client-server
� 3-tier
� pipeline
� publish-subscribe
4. Identify Architectural Styles
Investigation and Analysis
© 2002, W. Pree 85
� Identify, prioritize and refine the most importantquality attribute goals by building a utility tree.
� a utility tree is an AHP (analytic hierarchyprocess)-like model of the “driving” attribute-specific requirements
� typically performance, modifiability, security,and availability are the high-level nodes
� scenarios are leaves of utility tree� Output: a prioritization of specific quality attribute
requirements.
5. Generate Quality Attribute Utility Tree
Investigation and Analysis
© 2002, W. Pree 86
Utility Tree Construction -1
Utility
Performance Modifiability Availability
New sensors New middleware Change Web UI
Survive a singlenetwork failure
Live upgrade Quick restartafter disk failure
© 2002, W. Pree 87
Utility Tree Construction -2
Utility
Performance Modifiability Availability
New sensors New middleware Change Web UI
Survive a singlenetwork failure
Live upgrade Quick restartafter disk failure
(0.2) (0.5) (0.3)
(0.7)(0.1)(0.2)
(0.5)(0.4)(0.1)
© 2002, W. Pree 88
� Evaluation Team probes architectural styles fromthe point of view of specific quality attributes toidentify risks.
� Identify the styles which pertain to the highestpriority quality attribute requirements
� Generate quality-attribute specific questions forhighest priority quality attribute requirement
� Ask quality-attribute specific questions
� Identify and record risks and non-risks
6. Elicit and Analyze Architecture Styles
Investigation and Analysis
© 2002, W. Pree 89
Concurrent Pipelines Style
P21
P11 P12 P13 P1j
Pn1 Pn2 Pn3 Pnk
Processor Process Data flow
© 2002, W. Pree 90
Quality Attribute Questions
� Quality attribute questions probe styles to elicitarchitectural decisions which bear on qualityattribute requirements.
� Performance� How are priorities assigned to processes?� What are the message arrival rates?
� Modifiability� Are there any places where layers/facades are
circumvented ?� What components rely on detailed knowledge
of message formats?
© 2002, W. Pree 91
Risks and Non-Risks -1
� While risks are potentially problematicarchitectural decisions, …
� Non-risks are good decisions relying on implicitassumptions.
� Risk and non-risk constituents
� architectural decision
� quality attribute requirement
� rationale
� Sensitivity points are candidate risks and risks arecandidate tradeoff points.
© 2002, W. Pree 92
Risks and Non-Risks -2
� Example risk� Rules for writing business logic modules in the
second tier of your 3-tier style are not clearlyarticulated. This could result in replication offunctionality thereby compromising modifiability of thethird tier.
� Example non-risk� Assuming message arrival rates of once per second,
a processing time of less than 30 ms, and theexistence of one higher priority process, a 1 secondsoft deadline seems reasonable.
© 2002, W. Pree 93
� Scenarios are example stimuli used to
� Represent stakeholders’ interests
� Understand quality attribute requirements
� Seed scenarios are sample scenarios
� Scenarios are specific
� anticipated uses of (use cases),
� anticipated changes to (growth scenarios), or
� unanticipated stresses (exploratory) to the system.
7. Generate Seed Scenarios Testing
© 2002, W. Pree 94
� Stakeholders generate scenarios using abrainstorming process.
� Each stakeholder is allocated a number of votesroughly equal to 0.3 x #scenarios
� Prioritized scenarios are compared with the utility treeand differences are reconciled.
8. Brainstorm andPrioritize Scenarios
Testing
© 2002, W. Pree 95
Example Scenarios
� Use case
� Remote user comes via the web to access reportdatabase.
� Growth scenario
� Add a new data server to reduce latency by 50%.
� Exploratory scenario
� Half of the servers go down during operation.
=> Scenarios should be as specific as possible.
© 2002, W. Pree 96
� Identify styles and components within styles impactedby each scenario.
� Continue identifying risks and non-risks.
� Continue annotating architectural information.
9. Map Scenarios onto Styles Testing
© 2002, W. Pree 97
� Recapitulate steps of ATAM� Present ATAM outputs
� styles� scenarios� questions� utility tree� risks� non-risks
� Offer recommendations
10. Present Out-Brief/Write Report
Out-Briefing
© 2002, W. Pree 98
� Why analyze an architecture?
� ATAM Steps
� An example
� Summary and Status
Outline
© 2002, W. Pree 99
2. Present Business Drivers
� A distributed battlefield management system (BMS)
� One mobile central commander node� A set of mobile fighter nodes under commander� Information from many sources/sensors� Messages of different types (maps, orders)
� Stakeholders wanted to understand how the systemwould perform and adapt to changes
Presentation
© 2002, W. Pree 100
3. Present Architecture
� Physical view:“customer-providers”, wherethe commandernode is thecustomer and thefighter nodes areproviders.
� Detailed informationalso collected forconcurrency andcode views.
CommanderNode
FighterNode
FighterNode
FighterNodeFighter
Node
FighterNode
FighterNode
. . .
Presentation
© 2002, W. Pree 101
� We elicited information on the architectural approacheswith respect to modifiability, availability, andperformance.
� For availability, a backup commander scheme wasdescribed.
� For modifiability, standard subsystem organizationalpatterns were described.
� For performance, an independent communicatingcomponents style was described..
4. Identify Architectural Styles
Investigation and Analysis
© 2002, W. Pree 102
Utility
Performance Modifiability Availability(0.3) (0.2) (0.5)
Ballistics kernelcomputation New message
formatsNew messagedata types
Server failure
5. Generate Quality Attribute Utility Tree
Investigation and Analysis
© 2002, W. Pree 103
� The repair time forthe system is thetime to turn thebackup into thecommander node.
� Communicationbetween thecommander nodeand the backupkeeps the backup “insync”.
CommanderNode
FighterNode
FighterNode
FighterNodeFighter/
Backup
FighterNode
FighterNode
. . .
6. Elicit and Analyze Architecture Styles
Investigation and Analysis
© 2002, W. Pree 104
Availability Analysis - 1
� QA = the fraction of time the system is working
� The system is considered to be working if there is aworking commander node and one or more fighternodes.
� When the commander node fails the system has failed.
� Provisions have been made in the BMS architecture toturn a designated fighter (backup) node into acommander node.
© 2002, W. Pree 105
Availability Analysis - 2
� Availability can be seen as: QA = h(λc, λb, µc, µb)
where λc = failure rate of the commander
λb = failure rate of the backup
µc = repair rate of the commander
µb = repair rate of the backup
� Problem! The backup has no backup, i.e. in the BMSarchitecture, µb = 0
� We discovered this problem via qualitative analysisquestions that focused on failure and repair rates.
© 2002, W. Pree 106
Availability Analysis - 3
� Hence, two well-aimed hits (or hardware failures) disablethe entire system!
� The solution was to turn more fighter nodes into potentialbackups.
� Alternatives could be:
� Acknowledging backups (n)
� Passive backups (m)
� Passive backups (m) + update
© 2002, W. Pree 107
Availability: Sensitivity/RiskIdentification
� The availability of the system can now be seen as:
QA = j(n, m)
� n and m are architectural availability sensitivity points
� Since availability is a key attribute for the battlemanagement mission, some choices of n and m presentavailability risks
© 2002, W. Pree 108
� Initial set of seed scenarios were too general
� “System fails”
� Seed scenarios were later refined
� “Command node is destroyed and the Backupnode takes over as the Commander node”
7. Generate SeedScenarios
Testing
© 2002, W. Pree 109
� 46 scenarios were collected, covering modifiability,scalability, availability, performance, portability.
� Examples:
� Modifiability: map data formats change
� Performance: the number of simultaneousmissions doubles
� Availability: the commander is disable by adirect hit
8. Brainstorm andPrioritize Scenarios
Testing
© 2002, W. Pree 110
Scenario Prioritization
� The stakeholders suggested groupings of scenarios.
� The stakeholders used preference-voting to prioritizescenarios.
� The result was 15 high priority scenarios.
© 2002, W. Pree 111
� The architects mapped each of the high-priorityscenarios onto the BMS architecture.
� During this stage we:
� Gathered attribute-specific information qualitativeattribute questions
� Clarified our understanding of the architecture andthe scenarios
� Documented the answers
9. Map Scenarios onto StylesTesting
© 2002, W. Pree 112
Performance Analysis - 1
� We discovered a performance problem via a qualitativeattribute questions that asks about the relative speeds ofcommunication and processing.
� The problem uncovered was: the nodes in the BMSarchitecture communicated via slow modems.
© 2002, W. Pree 113
Performance Analysis -2
� End-to-end latency calculations showed that the overalllatency was highly sensitive to the number and size oftransmitted messages.
� Communication load came from:� The normal operations communication overhead� The number of backups (both acknowledging and
passive)
© 2002, W. Pree 114
Performance: Sensitivity/RiskIdentification
� Thus, system performance can be characterized as:
� QP = k(n, m, CO)
� Communications overhead was a constant.
� n and m are architectural performance sensitivity points.
© 2002, W. Pree 115
Tradeoff Identification
� Increasing the number of backups increases availability,but also increases average latency (because thesebackups must be kept up-to-date by the commander).
� Hence, the number of active and passive backups (n andm) is a tradeoff point in the BMS architecture.
� The designers had not been aware of the tradeoffinherent in their design.
© 2002, W. Pree 116
� Presentation and written report detailed the potentialmodifiability, performance, and availability problems, and…
� delineated new architecture options and their costs:� Acknowledging backups� Passive backups� Passive backups + updates
10. Present Out-Brief/Write Report
Out-Briefing
© 2002, W. Pree 117
Results of the BMS ATAM
� Greatly improved architectural documentation� Stakeholder buy-in� Discovery of missing performance and availability
requirements� Highlighting of a previously unknown tradeoff point in the
architecture� Delineation of recommendations to mitigate the risks of
this tradeoff
© 2002, W. Pree 118
� Why analyze an architecture?
� ATAM Steps
� An example
� Summary and Status
Outline
© 2002, W. Pree 119
Summary - 1
� ATAM is a method for evaluating an architecturewith respect to multiple quality attributes.
� It is an effective risk mitigation strategy to avoid thedisastrous consequences of a poor architecture.ATAM:� can be done early� requires stakeholder participation
� The key to the method is looking for trends, not inmaking precise analyses.
© 2002, W. Pree 120
Summary - 2
� ATAM relies critically on
� Clearly-articulated quality attribute requirements
� Active stakeholder participation
� Active participation by the architect
� Familiarity with architectural styles and analyticmodels
© 2002, W. Pree 121
Analysis forrearchitecting legacy
systems
© 2002, W. Pree 122
WWWWhhhhiiiicccchhhh ssssyyyysssstttteeeemmmmssss ggggeeeetttt rrrreeeeeeeennnnggggiiiinnnneeeeeeeerrrreeeedddd????
Modifyability
Value
discard reengineer
maintain enhance
© 2002, W. Pree 123
RRRReeeeaaaarrrrcccchhhhiiiitttteeeeccccttttiiiinnnngggg ffffoooorrrr iiiimmmmpppprrrroooovvvviiiinnnngggg tttthhhheeee
mmmmooooddddiiiiffffyyyyaaaabbbbiiiilllliiiittttyyyy ooooffff aaaannnn aaaarrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeee
� Getting rid of replicated code/functionality increasesthe modifyability =>Analyse existing source code in order to findreplicated code fragments that vary a bit.Replicated functionality is more difficult to find, asthe corresponding code fragments are often quitedifferent.
� In most cases these variations don’t allow simplepackaging into procedures with some parameters
=> small frameworks are helpful
© 2002, W. Pree 124
CCCCaaaasssseeee ssssttttuuuuddddyyyy:::: rrrreeeepppplllliiiiccccaaaatttteeeedddd ccccooooddddeeee iiiinnnn CCCC////SSSS
ssssyyyysssstttteeeemmmmssss
RP-Handling
Server / Host
RPC 1
ListHandl.
RPC 2
Client
RPC 1 RPC 3
. . .
RPC 2 RPC 1
ListHandl.
RPC 2
© 2002, W. Pree 125
PPPPaaaacccckkkkaaaaggggeeee rrrreeeepppplllliiiiccccaaaatttteeeedddd ccccooooddddeeee iiiinnnnttttoooo ssssmmmmaaaallllllll
ffffrrrraaaammmmeeeewwwwoooorrrrkkkkssss ((((==== ffffrrrraaaammmmeeeelllleeeettttssss)
RP-Handling
Server / Host
Client
. . .
ListHandl. RPC
© 2002, W. Pree 126
FFFFrrrraaaammmmeeeelllleeeettttssss vvvveeeerrrrssssuuuussss ffffrrrraaaammmmeeeewwwwoooorrrrkkkkssss
A framelet
� does not assume main control of an application,
� is small in size (< 10 classes/components),
� has a clearly defined simple interface.
The term framelet just makes explicit that it is a smallframework.
Thus, framework construction principles can be applied.
© 2002, W. Pree 127
Sample frameletcomponents
© 2002, W. Pree 128
LLLLiiiisssstttt----HHHHaaaannnnddddlllliiiinnnngggg ((((GGGGUUUUIIII----BBBBeeeeaaaannnn))))
open empty dialog
open dialog &display itemremove item
add item
parameters: dialog, class of a list item
reuse effect: about 200 LOC (at hundreds of spots)
reuse effort in a Beans environment: 3–4 minutes
© 2002, W. Pree 129
RRRRPPPPCCCC ((((NNNNoooonnnn----GGGGUUUUIIII----BBBBeeeeaaaannnn))))
parameter:RPC name
(RP parametersare assembledautomatically)
reuse effect:about 300 LOC(at hundreds ofspots)
lastName String Schwarzenegger
RP parameter description object
par. name type value
. . .
RPCallManager
constructRPC(...)
invokeRPC(...)RPC via JNI Server/Host
¿
≠≠≠≠ ¬
a
b
c
© 2002, W. Pree 130
RRRReeeefffflllleeeeccccttttiiiioooonnnn aaaassss mmmmoooorrrreeee fffflllleeeexxxxiiiibbbblllleeee aaaalllltttteeeerrrrnnnnaaaattttiiiivvvveeee ttttoooo
aaaabbbbssssttttrrrraaaacccctttt ccccllllaaaasssssssseeeessss &&&& iiiinnnntttteeeerrrrffffaaaacccceeeessss
Reflection can be useful to automate componentconfiguration:� assumes only that components support reflection,
eg, checking the methods of a component
� semantics have to be defined on the domain leveleg, naming conventions
� coupling is based on these semantics
Components of a framelet as well as different framelets canbe coupled via reflection.
© 2002, W. Pree 131
CCCCoooouuuupppplllliiiinnnngggg sssseeeemmmmaaaannnnttttiiiiccccssss
ddddeeeeffffiiiinnnneeeedddd sssseeeeppppaaaarrrraaaatttteeeellllyyyy
The simplest way to define coupling semantics is anaming convention
Object
exchange values of instancevariables with the same name and compatible types
programming language
domain-specificconventions
© 2002, W. Pree 132
EEEExxxxppppeeeerrrriiiieeeennnncccceeee wwwwiiiitttthhhh ffffrrrraaaammmmeeeelllleeeetttt----bbbbaaaasssseeeedddd
rrrreeeeaaaarrrrcccchhhhiiiitttteeeeccccttttiiiinnnngggg
� significant effort required for the identificationof replicated functionality
� good news: that effort pays off as legacysystems get streamlined
� framework technology useful to define smallcomponents with variation points
=> hands-on experience with frameworks
� design and implementation of frameletsimplies a small component library with highlyreusable assets that might also be adpatablefor other applications
© 2002, W. Pree 133
Summary andconclusion
© 2002, W. Pree 134
Where Have We Been?
Hopefully, by now, you are convinced that:
� it is a good idea to have a software architecture
� this architecture should be documented
� this architecture should be communicated to thesystem’s stakeholders
� this architecture should be analyzed
© 2002, W. Pree 135
WWWWhhhhyyyy AAAAnnnnaaaallllyyyyzzzzeeee aaaannnn AAAArrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeee???? ---- 1111
To get insights into a system‘s qualities that could not beachieved via design inspections, code inspections,...
We can analyze to understand:
� how to rearchitect a system
� the eventual modifiability of a system
� where architectural tradeoffs occur
© 2002, W. Pree 136
WWWWhhhhyyyy AAAAnnnnaaaallllyyyyzzzzeeee aaaannnn AAAArrrrcccchhhhiiiitttteeeeccccttttuuuurrrreeee???? ---- 2222
� Architecture analysis is easy to do.
� Architecture analysis is (relatively) cheap.
� It can be done early, when discovered problems are stillfixable at a reasonable cost.
� It improves the quality of an architecture as well as thestakeholders‘ understanding and confidence.
� It is a way of enhancing team communication.
� It is an effective risk mitigation technique.
© 2002, W. Pree 137
Appendix A
Overview ofarchitectural styles
© 2002, W. Pree 138
Overview of architecturalstyles*)
� Data-centered:� Repository
� Blackboard
� Data-flow:� Pipes & filters
� Batch/sequential
� Call-and-return:� Top down
� OO
� layered
» Virtual machine:– Interpreter
– Rule-based
» Independentcomponents:
– Communicatingprocesses
– Event systems
– implicitinvocation
– explicitinvocation*) The presentation is based on Software Architecture in Practice (Bass et al.; Addison-Wesley, 1998) and
Software Architecture: Perespectives on an Emerging Discipline (Shaw, Garlan; Prentice Hall, 1996)
© 2002, W. Pree 139
Data-centered (I)
Access to shared data represents the core characteristic ofdata-centered architectures. The data integrability forms theprincipal goal of such systems.
Shared Data
Client Client
passive data
computationalcomponent / object
data flow
Legend:
© 2002, W. Pree 140
Data-centered (II)
The means of communication between the componentsdistinguishes the subtypes of the data-centered architecturalstyle:
� Repository: passive data (see schematic representationof previous slide)
� Blackboard: active dataA blackboard sends notification to subscribers whenrelevant data change (→ Observer pattern)
© 2002, W. Pree 141
Data-centered (III)
+ clients are quite independent of each other=> clients can be modified without affecting others
coupling between clients might increase performance butlessen this benefit
+ new clients can be easily added
No rigid separation of styles: When clients are independentlyexecuting processes: client/server architectural style
© 2002, W. Pree 142
Data-flow
The system consists of a series of transformations on successivepieces of (input) data. Reuse and modifiability form the principalgoals of such architectures.
Validate
process
data flow
Legend:
Sort ReportTape Tape Tape Page
© 2002, W. Pree 143
Data-flow substyles
� Batch sequential (→ sample on previous slide)
� components (= processing steps) are independent programs
� each step runs to completion before the next step starts,i.e., each batch of data is transmitted as a whole betweensteps
� Pipe-and-filter (→ UNIX pipes & filters)
� incremental transformation of data based on streams
� filters are stream transducers and use little contextualinformation and retain no state information betweeninstantiations
� pipes are stateless and just move data between filters
© 2002, W. Pree 144
Pros and cons of pipes-and-filters
+ no complex component interactions to manage
+ filters are black boxes
+ pipes and filters can be hierarchically composed
– batch mentality => hardly suitable for interactive applications
– filter ordering can be difficult; filters cannot interact cooperativelyto solve a problem
– performance is often poor
parsing/unparsing overhead due to lowest common denominatordata representation
– filters which require all input for output production have to createunlimited buffers
© 2002, W. Pree 145
Virtual machine (I)
Virtual machines simulate some functionality that is notnative to the hardware/software on which it isimplemented. This supports achieving the quality attribute ofportability.
Examples:
� interpreters
� command language processors
� rule-based systems
© 2002, W. Pree 146
Virtual machine (II)
Schematic representation:
Data(program state)
Program beinginterpreted
InterpretationEngine Internal state
inputs
outputs
programinstructions
state data
selected instruction
selected data
dataupdates
© 2002, W. Pree 147
Call-and-return
Call-and-return architectures rely on the well-knownabstraction of procedures/functions/methods. Shaw andGarlan discern between the following substyles:
� main-program-and-subroutine style
� remote-procedure-call systems also belongto this category but are decomposed inparts that live on computers connected viaa network
� object-oriented or abstract-data-type style
� layered style
© 2002, W. Pree 148
Layered style
Components belong to layers. In pure layered systems eachlevel should communicate only with its immediateneighbors.
Each successive layer is built on its predecessor, hiding thelower layer and providing some services that the upper layersmake use of. Upper layers often form virtual machines.
User interface
Basic utilities
Core system
© 2002, W. Pree 149
Event systems
Publish/subscribe (observer) pattern: Components can register aninterest in notifications.
Example: coupling between JavaBeans
Listener
Source Listener
Listener
© 2002, W. Pree 150
Heterogeneous styles (I)
Example: event system + layered style
Listener
Source Listener
Listener
© 2002, W. Pree 151
Heterogeneous styles (II)
In general, the presented architectural styles do not clearlycategorize architectures. Styles exist as cognitive aids andcommunication cues.
� The data-centered style, composed out of thread-independent clients is like an independent componentarchitecture.
� The layers in a layered architecture might be objects/ADTs.
� The components in a pipe-and-filter architecture are usuallyindependently operating processes and thus also correspondto an independent component architecture.
� Commercial client/server systems with a CORBA-basedinfrastructure could be described as layered object-basedprocess systems, i.e., a hybrid of three styles.
© 2002, W. Pree 152
Appendix B—Bibliography (I)
Bass L., Clements P., Kazman R. (1998) Software Architecture in Practice, Addison-Wesley
Fayad M., Schmidt D., Johnson R. (1999) Building Application Frameworks: Object-Oriented Foundations of Framework Design,Wiley
Fayad M., Schmidt D., Johnson R. (1999) Implementing Application Frameworks: Object-Oriented Frameworks at Work, Wiley
Fayad M., Schmidt D., Johnson R. (1999) Domain-Specific Application Frameworks: Manufacturing, Networking, DistributedSystems, and Software Development, Wiley
Gabriel R.P. (1996). Patterns of Software—Tales from the Software Community. New York: Oxford University Press
Gamma E., Helm R., Johnson R. and Vlissides J. (1995) Design Patterns—Elements of Reusable OO Software. Reading, MA:Addison-Wesley (also available as CD)
Pree W. (1995) Design Patterns for Object-Oriented Software Development. Reading, Massachusetts: Addison-Wesley/ACM Press
Szyperski C. (1998) Component Software—Beyond Object-Oriented Programming, Addison-Wesley.
Shaw M., Garlan D. (1996) Software Architecture—Perspectives on an Emerging Discipline. Prentice-Hall
comprehensive architecture descriptions of real-world software systems:
Freeman E, Hupfer S, Arnold K (1999) JavaSpaces—Principles, Patterns, and Practice, Addison-Wesley
Wirth N, Gutknecht J. (1993) Project Oberon—The Design of an Operating System and Compiler, Addison-Wesley
© 2002, W. Pree 153
Appendix B—Bibliography (II)
Bibliography on Software Architecture Analysis (http://www.fit.ac.jp/~zhao/pub/sa.html),
maintained by Jianjun Zhao
This is the bibliography on software architecture analysis, with special emphasis on architectural-level understanding, testing, debugging, reverse engineering, re-engineering,maintenance, and complexity measurement.
------------------------------------------------------------------------
R. Balzer, "Instrumenting, Monitoring and Debugging Software Architectures."
P. Bengtsson and J. Bosch, "Scenario-Based Software Architecture Reengineering," Proc. 5th International Conference on Software Reuse (ICSR5), pp.308-317, IEEE ComputerSociety Press, Victoria, B.C, Canada, June 1998.
P. Bengtsson, "Towards Maintainability Metrics on Software Architecture: An Adaptation of Object-Oriented Metrics," Firsrt Nordic Workshop on Software Architecture(NOSA'98), Ronneby, August 1998.
P. Bengtsson and J. Bosch, "Architecture Level Prediction of Software Maintenance," Proc. 3rd European Conference on Maintenance and Reengineering (CSMR99) , Amsterdam,The Netherlands, March 1999.
L. Bass, P. Clements, and R. Kazman, "Software Architecture in Practice," Published by Addison-Wesley in the SEI Series, 1998.
A. Bertolino, P. Inverardi, H. Muccini, and A. Rosetti, "An Approach to Integration Testing Based on Architectural Descriptions," Proc. Third IEEE International Conference onEngineering of Complex Computer Systems (ICECCS97), pp.77-84, Como, Italy, September 1997.
G. Canfora, A. De Lucia, G. di Lucca, and A. Fasolino, "Recovering the Architectural Design for Software Comprehension," Proc. IEEE Third Workshop on ProgramComprehension, Washington, DC, November 1994.
S. J. Carriere and R. Kazman, "The Perils of Reconstructing Architectures," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.13-16, ACM SIGSOFT, Orlando,Florida, USA, November 1998.
S. J. Carriere, R. Kazman, and S. Woods, "Assessing and Maintaining Architectural Quality," Proc. 3rd European Conference on Maintenance and Reengineering (CSMR99) ,Amsterdam, The Netherlands, March 1999.
P. Clements, R. Krut, E. Morris, and K. Wallnau, "The Gadfly: An Approach to Architectural-Level System Comprehension," Proc. 4th International Workshop on ProgramComprehension (IWPC96), IEEE Computer Society Press, pp.178-186, 1996.
J. F. Girard and R. Koschke, "Finding Components in a Hierarchy of Modules: A Step towards Architectural Understanding," Proc. International Conference on SoftwareMaintenance (ICSM97), IEEE Computer Society Press, pp.58-65, Bari, Italy, October 1997.
© 2002, W. Pree 154
Appendix B—Bibliography (III)
G. Y. Guo, J. M. Atlee, and R. Kazman, "A Software Architecture Reconstruction Method," Proc. First Working IFIP Conference on Software Architecture (WICSA1), San Antonio,TX, USA, February 1999.
D. Harris, H. Reubenstein, and A. S. Yeh, "Reverse Engineering to the Architectural Level," Proc. International Conference on Software Engineering (ICSE95), pp.186-195, IEEEComputer Society Press, July 1995.
S. Henry and D. Kafura, "Software Structure Metrics Based on Information Flow," IEEE Transactions on Software Engineering, 7(5), September 1981.
P. Inverardi and A. L. Wolf, "Formal Specification and Analysis of Software Architectures using the Chemical Abstract Machine Model," IEEE Transactions on SoftwareEngineering, 21(4):373--386, April 1995.
R. Kazman, "Tool Support for Architectural Analysis and Design," Proc. 2nd Software Architecture Workshop (ISAW2), pp.94-97, San Francisco, CA, October 1996.
R. Kazman, G. Abowd, L. Bass, and P. Clements, "Scenario-Based Analysis of Software Architecture," IEEE Software, pp.47-55, November 1996.
R. Kazman and M. Burth, "Assessing Architectural Complexity," Proc. 2nd Euromicro Working Conference on Software Maintenance and Reengineering (CSMR98), pp.104-112,IEEE Computer Society Press, Florence, Italy, March 1998.
R. Kazman and S. J. Carriere, "View Extraction and View Fusion in Architectural Understanding," Proc. 5th International Conference on Software Reuse (ICSR5), pp.290-299,IEEE Computer Society Press, Victoria, B.C, Canada, June 1998.
R. Kazman, M. Klein, M. Barbacci, H. Lipson, T. Longstaff, and S. J. Carriere, "The Architecture Tradeoff Analysis Method," Proc. Fourth IEEE International Conference onEngineering of Complex Computer Systems (ICECCS98), pp.68-78, Montery, USA, August 1998.
R. Kazman, S. Woods, and S. J. Carriere, "Requirements for Integrating Software Architecture and Reengineering Models: CORUM II", Proc. 5th Working Conference on ReverseEngineering (WCRE98), pp.154-163, Honolulu, HI, October 1998.
R. Kazman and S. J. Carriere, Playing Detective: Reconstructing Software Architecture from Available Evidence", Journal of Automated Software Engineering, April 1999. (toappear)
T. H. Kim, Y. T. Song, L. Chung, and D. Huynh, "Software Architecture Analysis Using Dynamic Slicing", Proc. AoM/IAoM CS'99, Auguest 1999.
T. H. Kim, Y. T. Song, L. Chung, and D. Huynh, "Dynamic Software Architecture Slicing", Proc. 23th IEEE Annual International Computer Software and Applications Conference(COMPSAC99), October 1999. (to appear)
J. Kramer and J. Magee, "Analysing Dynamic Change in Software Architectures: A Case Study", Proc. IEEE 4th International Conference on Configurable Distributed Systems(CDS 98), pp.91-100, Annapolis, May 1998.
R.L. Krikhaar, R.P. de Jong, J.P. Medema, and L.M.G. Feijs, "Architecture Comprehension Tools for a PBX System", Proc. 3rd European Conference on Maintenance andReengineering (CSMR99) , Amsterdam, The Netherlands, March 1999.
D.C. Luckham, J.J. Kenney, L.M. Augustin, J. Vera, D. Bryan, and W. Mann, "Specification and Analysis of System Architecture Using Rapide," IEEE Transactions on SoftwareEngineering, Vol.21, No.4, pp.336-355, April 1995.
C. H. Lung, S. Bot, K. Kalaichelvan, and R. Kazman, "An Approach to Software Architecture Analysis for Evolution and Reusability," Proc. of CASCON '97, November 1997.
© 2002, W. Pree 155
Appendix B—Bibliography (IV)
C. H. Lung and K. Kalaichelvan, "A Quantitative Approach to Software Architecture Sensitivity Analysis", Proc. of the 10th Internationall Conference on Software Engineering andKnowledge Engineering, pp. 185-192, June 1998.
C. H. Lung, "Software Architecture Recovery and Restructuring through Clustering Techniques," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.101-104,ACM SIGSOFT, Orlando, Florida, USA, November 1998.
J. Magee, J. Kramer, and D. Giannakopoulou, "Analysing the Behaviour of Distributed Software Architectures: a Case Study", Proc. 5th IEEE Workshop on Future Trends inDistributed Computing Systems (FTDCS97), pp.240-247, Tunisia, October 1997.
J. Magee, J. Kramer, and D. Giannakopoulou, "Software Architecture Directed Behavior Analysis," Proc. Ninth International Workshop on Software Specification and Design(IWSSD9), pp.144-146, IEEE Computer Society Press, Ise-Shima, Japan, April 1998.
J. Magee, J. Kramer and D. Giannakopoulou, "Behaviour Analysis of Software Architectures" Proc. First Working IFIP Conference on Software Architecture (WICSA1), SanAntonio, Texas, February 1999.
T. J. McCabe and C. W. Butler, "Design Complexity Measurement and Testing," Communications of ACM, Vol.32, No.12, pp.1415-1425, 1989.
G. Naumovich, G.S. Avrunin, L.A. Clarke, and L.J. Osterweil, "Applying Static Analysis to Software Architectures," Proc. the Sixth European Software Engineering ConferenceHeld Jointly with the 5th ACM SIGSOFT Symposium on Foundations of Software Engineering, pp.77-93, Lecture Notes in Computer Science, Vol.1301, Springer-Verlag, 1997.
D. E. Perry and A. L. Wolf, ``Foundations for the Study of Software Architecture'', ACM SIGSOFT Software Engineering Notes, pp.40-52, Vol.17, No.4, October 1992.
J. Peterson and M. Sulzmann, "Analysis of Architectures using Constraint-Based Types," Proc. First Working IFIP Conference on Software Architecture (WICSA1), San Antonio,TX, USA, February 1999.
M. D. Rice and S. B. Seidman, "An Approach to Architectural Analysis and Testing," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.121-123, ACMSIGSOFT, Orlando, Florida, USA, November 1998.
D.J. Richardson and A. L. Wolf, "Software Testing at the Architectural Level," Proc. 2nd International Software Architecture Workshop (ISAW2), pp.68-71, San Francisco,California, October 1996.
M. Shaw and D. Garlan, "Software Architecture: Perspectives on an Emerging Discipline," Prentice Hall, 1996.
J.A. Stafford, D.J. Richardson, and A. L. Wolf, "Chaining: A Software Architecture Dependence Analysis Technique," Technical Report CU-CS-845-97, University of Colorado,September 1997.
J.A. Stafford, D.J. Richardson, and A. L. Wolf, "Aladdin: A Tool for Architecture-level Dependence Analysis of Software Systems," University of Colorado Technical Report, CU-CS-858-98, 1998.
J.A. Stafford and A. L. Wolf, "Architectural-level Dependence Analysis in Support of Software Maintenance," Proc. 3rd International Software Architecture Workshop (ISAW3),pp.129-132, ACM SIGSOFT, Orlando, Florida, USA, November 1998.
W. Tracz, "Testing and Analysis of Software Architectures," Proc. ACM International Symposium on Software Testing and Analysis (ISSTA96), S.Diego, USA, January 1996.
V. Tzerpos and R.C. Holt, "The Orphan Adoption problem in Architecture Maintenance," Proc. Working Conference on Reverse Engineering (WCRE97), Amsterdam, TheNetherlands, October 1997.
© 2002, W. Pree 156
Appendix B—Bibliography (V)
C. Williams, "Software Architecture: Implications for Computer Science Research," Proc. First Working IFIP Conference on Software Architecture (WICSA1), San Antonio, TX,USA, February 1999.
J. Zhao, "Software Architecture Slicing," Proc. 14th Conference of Japan Society for Software Science and Technology (JSSST'97), pp.49-52, Ishikawa, Japan, September 1997.
J. Zhao, "Using Dependence Analysis to Support Software Architecture Understanding," in M. Li (Ed.), "New Technologies on Computer Software," pp.135-142, InternationalAcademic Publishers, September 1997.
J. Zhao, "Applying Slicing Technique to Software Architectures," Proc. Fourth IEEE International Conference on Engineering of Complex Computer Systems (ICECCS98), pp.87-98, August 1998.
J. Zhao, "On Assessing the Complexity of Software Architectures," Proc. 3rd International Software Architecture Workshop (ISAW3), pp.163-166, ACM SIGSOFT, Orlando,Florida, USA, November 1998.
J. Zhao, "Extracting Reusable Software Architectures: A Slicing-Based Approach," Proc. ESEC/FSE'99 Workshop on Object-Oriented Reengineering, Toulouse, France, September1999. (to appear)
------------------------------------------------------------------------
Other Links on Software Architecture
Bibliographies:
Ric Holt's Annotated Biblography on Software Architecture http://plg.uwaterloo.ca/~holt/cs/746/98/biblio.html
Rick Kazman's Software Architecture Bibliography http://www.cgl.uwaterloo.ca/~rnkazman/SA-bib.html
Kamran Sartipi's Software Architecture Bibliography http://se.math.uwaterloo.ca:80/~ksartipi/papers/sa-bib.ps
SEI Bibliography on Software Architecture http://www.sei.cmu.edu/architecture/bibpart1.html
Others:
Dewayne Perry's Web Page on Software Architecture http://www.bell-labs.com/user/dep/work/swa/
Software Architecture Technology Guide http://www-ast.tds-gn.lmco.com/arch/guide.html
On-line Proceedings of the International Workshop on the Role of Software Architecture in Testing and Analysis (ROSATEA)
http://www.ics.uci.edu/~djr/rosatea/
------------------------------------------------------------------------
Maintained by Jianjun Zhao ([email protected])