Upload
vizions007
View
4
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Software Architecture
Citation preview
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 1
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
12 Design ⇒ Software Architecture Introduction to Design Readings
[GJM03] Fundamentals of Software Engineering by Carlo Ghezzi, Mehdi Jazayeri, andDino Mandrioli, Second Edition, Prentice Hall; Chapter 4
[dlP72] Parnas David L., “On the criteria to be used in decomposing systems intomodules,” CACM, Dec., 1972
[dlP76] Parnas David L., “On the design and development of program families,” IEEETrans.SE., vol. SE-2, pp.1-9, Mar. 1976
[dlP79] Parnas, D.L. Designing software for ease of extension and contraction. In IEEETrans. SE, Mar. 1979
Science of Design: Software-Intensive Systems A National Science FoundationWorkshop Airlie Center, November 2-4, 2003http://www.cs.virginia.edu/~sullivan/sdsis/workshop%202003.htm
Software Architecture Readings David Garlan, “Software Architecture: a Roadmap,” Proceedings of the conference on
The future of Software engineering, Limerick, Ireland, June 04 - 11, 2000 M. Shaw and P. Clements,”A field guide to boxology: Preliminary classification of
architectural styles for software systems,” Proceedings of COMPSAC 1997, August1997
M. Shaw and D. Garlan, Tutorial Slides on Software Architecture http://www-2.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/Tutorial_Slides/Soft_Arch/quick_index.html
Garlan, David & Shaw, “An Introduction To Software Architecture,” Technical report, TheSoftware Engineering Institute, Carnegie Mellon University
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Modular DecompositionHow to define the structure of a modular system?
A module is a well-defined component of a software systemA module is part of a system that provides a set of services toother modules
What are desirable properties of a decomposition?CohesionCouplingComplexityCorrectnessCorrespondence
Strategies for decompositionInformation HidingLayering
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 2
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Cohesion & CouplingCohesion: The reason that elements are found togetherin a moduleEx: coincidental, temporal, functional, …The details aren’t critical, but the intent is usefulDuring maintenance, one of the major structuraldegradations is in cohesion
Coupling: Strength of interconnection between modulesHierarchies are touted as a wonderful couplingstructure, limiting interconnectionsBut don’t forget about composition, which requiressome kind of coupling
It’s easy to......reduce coupling by calling a system a single module…increase cohesion by calling a system a single module
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Coupling
Coupling also degrades over time“I just need one function from that module…”
Unnecessary coupling hurtsPropagates effects of changes more widelyHarder to understand interfaces (interactions)Harder to understand the designComplicates managerial tasksComplicates or precludes reuse
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 3
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
CouplingNo satisfactory measure of couplingEither across modules or across a systemCruickshank and Gaffney Coupling metric
Mj = sum of thenumber of input andoutput items sharedbetween components i& jZi = average number ofinput and outputitems shared over mcomponents withcomponent in = number ofcomponents in thesoftware product
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Complexitysimpler designs are better, all else beingequalno useful measures of design/programcomplexity existAlthough there are dozens of such measuresLOC seems to be the most reliable predictorwhen single domains are considered, e.g.data processingnumerical processingsymbolic processing e.g., compilersconcurrent/distributed systems e.g., operating
systems
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 4
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
CorrectnessVery difficult (we’ll come back to this briefly laterin the course)Even if you “prove” modules are correct, how doyou proveComposition of the modules within and outside thesystem to be designedSystem software that must interpret/compile andrun the composed modulesHardware on which the complied modules run, etc.
Leveson and others have shown clearly that asystem can fail even when each of the pieceswork properly
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Correspondence “Problem-program mapping” The way in which the design is associated with the
requirements The idea is that the simpler the mapping, the
easier it will be to accommodate change in thedesign when the requirements change
See M. Jackson: problem frames
Requirements Design Implementationcorrespondence correspondence
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 5
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Functional decompositionDivide-and-conquer based on functions
input;
compute;
output
Then proceed to decompose computeThis is stepwise refinement (Wirth, 1971)There is an enormous body of work in this area,including many formal calculi to support theapproachClosely related to proving programs correctMore effective in the face of stable requirements
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Properties of a modular structureAlmost all the literature focuses on logical structures in
design, but physical structure plays a big role in practiceSharingSeparating work assignmentsDegradation over time
To what degree do you consider your systemsas having modules?as consisting of a set of files?a question of physical vs. logical structure of programs
In some languages/environments, they are one and the same, e.g.,Smalltalk-80
How to define the structure of a modular system?A module is a well-defined component of a software systemA module is part of a system that provides a set of services toother modules where services are computational elements that other modules may use
Why so littleattention paid to this?
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 6
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Modules and relationsLet S be a set of modules
S = {M1, M2, . . ., Mn}A binary relation★ R on S is a subset of
R ⊆ S x S If Mi and Mj are in S, <Mi, Mj> ∈ R can be written as
MiR Mj
Transitive closure R+ of R Mi R+ Mjiff MiR Mj or ∃ Mk in S s.t. MiR Mk and MkR+ Mj
R is a hierarchy iff there are no two elements Mi, Mj s.t.MiR Mj ∩ MjR Mi
Relations can be represented as graphs; a hierarchy is a DAG(directed acyclic graph)
★we assume our relations to be irreflexive
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
The uses relationA uses B; examples
A requires the correct operation of BA can access the services exported by B through its interfaceA depends on B to provide its servicesexample: A calls a routine exported by B
A is a client of B; B is a serverthe correctness of A depends on the presence of a correctversion of Brequires specification and implementation of A and thespecification of B
Criteria for uses(A,B)A is essentially simpler because it uses BB is not substantially more complex because it does not use AThere is a useful subset containing B but not AThere is no useful subset containing A but not B
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 7
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
The uses relationuses should be a hierarchy
Hierarchy makes software easier to understandProceed from leaf nodes (who do not use others)upwardsThey make software easier to buildThey make software easier to test
A non-hierarchical uses relation makes it difficultto produce useful subsets of a system -- ParnasIt also makes testing difficult(What about upcalls?)So, it is important to design the uses relation
Can uses be mechanically computed? uses not the same as invokes
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
The is_component_of RelationUsed to describe a higher level module asconstituted by a number of lower level modulesA is_component_of B
B consists of several modules, of which one is AB comprises AIf MS,i={Mk|Mk∈S ∧ Mk is_component_of Mi}
then we say that MS,i implements Mi
Careful recording of (hierarchical) uses andis_component_of relations supports design ofprogram families
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 8
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
A graphical view of is_component_of
M7
(is_component_of) (comprises)
They are a hierarchy
M8 M9 M5 M6
M2 M3 M4
M1 M7 M8 M9 M5 M6
M2 M3 M4
M1
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Hierarchy
Organizes the modular structure throughlevels of abstractionEach level defines an abstract (virtual)machine for the next levellevel can be defined preciselyMi has level 0 if no Mj exists s.t. Mi R Mj
let k be the maximum level of all nodes Mj
s.t. Mi R Mj … then Mi has level k+1
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 9
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Interface designInterface should not reveal what we expect maychange laterIt should not reveal unnecessary detailsInterface acts as a firewall preventing access to hiddenparts
PrototypingOnce an interface is defined, implementation can bedonefirst quickly but inefficientlythen progressively turned into the final version
Initial version acts as a prototype that evolves into thefinal product
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Interface vs. implementationTo understand the nature of uses, we need to knowwhat a used module exports through its interfaceThe client imports the resources that are exported by itsserversModules implement the exported resourcesImplementation is hidden to clients
Clear distinction between interface and implementationis a key design principleSupports separation of concernsclients care about resources exported from serversservers care about implementation
Interface acts as a contract between a module and itsclients
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 10
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Information hidingperhaps the most important intellectual tool developed to
support software design; makes anticipation of change acenterpiece in decomposition into modules
are OO & IH the same?OO classes are chosen based on the domain of the problem(in most OO analysis approaches), not necessarily based onchange, but they are obviously related (e.g., separatinginterface from implementation)
Notkin’s IH “Central Premises”1. can effectively anticipate changes2. changing an implementation is the best change, since it’sisolated
3. semantics of a module must remain unchanged whenimplementations are replaced
4. one implementation can satisfy multiple clients5. information hiding can be recursively applied
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Layering [Parnas 79]Focus on information hiding modules isn’t enoughOne may also consider abstract machines
In support of program familiesSystems that have “so much in common that it pays tostudy their common aspects before looking at the aspectsthat differentiate them”
Still focusing on anticipated changeLots of language support for information hiding modules
C++ classes, Ada packages, etc.We have essentially no language support for layering
Operating systems provide support, primarily forreasons of protection, not abstractionBig performance cost to pay for “just” abstraction
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 11
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Categories of modulesFunctional modules
traditional form of modularizationprovide a procedural abstractionencapsulate an algorithm
Librariesa group of related procedural abstractionse.g., mathematical libraries
implemented by routines of programming languages
Common pools of datadata shared by different modulese.g., configuration constants
the COMMON FORTRAN construct
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Abstract Modules
Abstract objectsObjects manipulated via interface functionsData structure hidden to clients
Abstract data typesMany instances of abstract objects may begenerated
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 12
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Abstract objectsExamples
calculator of expressions expressed in Polish postfixform: a*(b+c) abc+*a stack where the values of operands are shifted untilan operator (assume only binary operators) isencountered in the expressionInterface of the abstract object STACK
exportsprocedure PUSH (VAL: in integer);procedure POP_2 (VAL1, VAL2: out
How does the design anticipate change in type ofexpressions to be evaluated?e.g., it does not adapt to unary operators
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
indicates that details of thedata structure are hidden to clients
Abstract data types (ADTs)Example: stack ADT
ADTs correspond to Java and C++ classes & may alsobe implemented by Ada private types and Modula-2opaque types
module STACK_HANDLER
exports
type STACK = ?;
This is an abstract data -type module; the data structure
is a secret hidden in the implementation part.
procedure PUSH (S: in out STACK ; VAL: in integer); procedure POP (S: in out STACK ; VAL: out integer); function EMPTY (S: in STACK) : BOOLEAN;
.
.
.
end STACK_HANDLER
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 13
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
module FIFO_CARSuses CARSexports
type QUEUE : ?;procedure ENQUEUE (Q: in out QUEUE ; C: in CARS);procedure DEQUEUE (Q: in out QUEUE ; C: out CARS);function IS_EMPTY (Q: in QUEUE) : BOOLEAN;function LENGTH (Q: in QUEUE) : NATURAL;procedure MERGE (Q1, Q2 : in QUEUE ; Q : out QUEUE);This is an abstract data-type module representingqueues of cars, handled in a strict FIFO way;queues are not assignable or checkable for equality,since “:=” and “=” are not exported.…
end FIFO_CARS
Abstract data types (ADTs)Aother example: simulation of a gas station
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Software Architecturearchitecture of a system describes its gross structure illuminates the top level design decisions
how the system is composed of interacting partsthe main pathways of interactionthe key properties of the parts
allows high-level analysis and critical appraisala bridge between requirements and implementation
an abstract description of a system,exposes certain properties, while hiding others.
useful for:UnderstandingReuseConstructionEvolutionAnalysisManagement
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 14
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Roles of Software Architecture Understanding:
simplifies the understanding oflarge systems using an abstraction
constraints on system design rationale
Construction a partial blueprint for
development: components anddependencies
Evolution dimensions along which a system
is expected to evolve "load-bearing walls" ->
ramifications of changes, costestimation
separate concerns about thefunctionality of a component fromthe ways in which that componentis connected to (interacts with)other components
Analysis consistency checking conformance
to constraints to quality attributes
dependence analysis domain-specific analyses for
architectural styles Reuse
reuse of large components andframeworks
Management leads to a much clearer
understanding of requirements,implementation strategies, andpotential risks
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Software Architectures Architectural taxonomy (“boxology”) Architectural patterns & idioms Design patterns & idioms Reuse
Class libraries Components Frameworks Middleware
Requirements
DetailedDesign
High-levelDesign
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 15
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Framework Architecture
Class Library Architecture
ADTs
Strings
LocksIPC
MathLOCAL
INVOCATIONS APPLICATION-SPECIFIC
FUNCTIONALITY
GLUECODE
Files
GUIEVENTLOOP
Frameworks & Class LibrariesA framework is an integrated set ofabstract classes that can becustomized for instances of a familyof applications
A class is a unit of abstraction &implementation in an OOprogramming language
A component is an encapsulationunit with one or more interfaces thatprovide clients with access to itsservices
Adapted from Douglas C. Schmidt, “Patterns, Frameworks, &Middleware: Their Synergistic Relationships”
Middleware Bus
Component Architecture
Naming
LockingLogging
Events
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Comparison
Class Libraries FrameworksMacro-levelMeso-levelMicro-level
Borrow caller’s threadInversion of controlBorrow caller’s thread
Domain-specific or Domain-independent
Domain-specificDomain-independent
Stand-alone compositionentities
“Semi-complete”applications
Stand-alone languageentities
Components
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 16
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
HistoricallyArchitecture was largely ad hoc affair
Designers freely use informal patterns/idioms informal with imprecise semanticsdiagrams + prose, but no rules
Designers use system-level abstractionoverall organization (styles)components and interactions
Designers compose systems from subsystemsbut, tend to think staticallyselect structure by default, rather than by design
Key eventsParnas recognized the importance of system families andarchitectural decomposition principles based on informationhidingDijkstra proposed certain system structuring principles
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
ControlProcess
(CP)
Prop LossModel
(MODP)
ReverbModel
(MODR)
NoiseModel
(MODN)
Architecture was largely ad hoc
is this an architecture?
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 17
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
ControlProcess
(CP)
PropLoss
Model(MODP)
ReverbModel
(MODR)
NoiseModel
(MODN)
Examplewhat is the nature of the components,and what is the significance of theirseparation?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
ControlProcess
(CP)
Prop LossModel
(MODP)
ReverbModel
(MODR)
NoiseModel
(MODN)
Examplewhat is the significance of the links?
what is the significance of the layout?
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 18
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Abstraction techniques in CSProgramming Languages
machine languagesymbolic assemblersmacro processorsearly high-level languagesFortran
data types served primarily as cues for selectingthe proper machine instructions
Algol and it successorsdata types serve to state the programmer’sintentions about how data should be used.
later high-level languagesseparation of a module’s specificationfrom its implementation
introduction of abstract data types.
increasingabstraction
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Abstraction techniques in CSADT
the software structure (which included a representationpackaged with its primitive operators)specifications (mathematically expressed as abstractmodels or algebraic axioms)language issues (modules, scope, user-defined types)integrity of the result (invariants of data structures andprotection from other manipulation)rules for combining types (declarations)information hiding (protection of properties not explicitlyincluded in specifications)
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 19
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
two trendsrecognition of a shared repertoire of methods,techniques, patterns and idioms for structuring complexsoftware systems
concern with exploiting commonalities in specificdomains to provide reusable frameworks for productfamilies
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
two trends recognition of a shared repertoire of methods, techniques, patterns
and idioms for structuring complex software systems“Camelot is based on the client-server model and uses remoteprocedure calls both locally and remotely to provide communicationamong applications and servers.”
“Abstraction layering and system decomposition provide theappearance of system uniformity to clients, yet allow Helix toaccommodate a diversity of autonomous devices. The architectureencourages a client-server model for the structuring ofapplications.”
“We have chosen a distributed, object-oriented approach tomanaging information.”
“The easiest way to make the canonical sequential compiler into aconcurrent compiler is to pipeline the execution of the compilerphases over a number of processors. . . . A more effective way [is to]split the source code into many segments, which are concurrentlyprocessed through the various phases of compilation [by multiplecompilerprocesses] before a final, merging pass recombines theobject code into a single program.”
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 20
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
two trendsconcern with exploiting commonalities in specificdomains to provide reusable frameworks for productfamilies; examples include: the standard decomposition of a compiler standardized communication protocols, e.g., OpenSystems Interconnection Reference Model (a layerednetwork architecture) tools, e.g., NIST/ECMA Reference Model (a genericsoftware engineering environment architecture basedon layered communication substrates) fourth-generation languages user interface toolkits and frameworks, e.g., X WindowSystem (a distributed windowed user interfacearchitecture based on event triggering and callbacks)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Why Important?mutual communication.
software architecture represents a common high-levelabstraction of the system that most, if not all, of thesystem’s stakeholders can use as a basis for creatingmutual understanding, forming consensus, andcommunicating with each other.
transferable abstraction of a system. software architecture embodies a relatively small,intellectually graspable model for how the system isstructured and how its components work together; thismodel is transferable across systems; in particular, itcan be applied to other systems exhibiting similarrequirements, and can promote large scale reuse.
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 21
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Why Important?early design decisions
software architecture represents the embodiment of theearliest set of design decisions about a system, and theseearly bindings carry weight far out of proportion to theirindividual gravity with respect to the system’s remainingdevelopment, its service in deployment, and its maintenancelife.
architectureprovides builders with constraints on implementationdictates organizational structure for development andmaintenance projectspermits or precludes the achievement of a system’s targetedquality attributesHelps in predicting certain qualities about a systemarchitecture can be the basis for traininghelps in reasoning about and managing change
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
elements, form, rationale, viewsarchitecture=elements
processingdataconnectors
formrules which constrainelement placement
style/design rationale
selection of form links to reqmnts & design functional/non-functionalattributes
lexer parser semanticanalyzer
codegenerator
optimizer
chars tokens phrasescorrelatedphrases
correlatedphrases
annotatedcorrelatedphrases
lexer parsersemanticanalyzer
codegenerator
optimizer
hastokens
hasphrases
hascorrelatedphrases
hasannotatedcorrelatedphrases
codegenerator
Process View
Data View
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 22
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
architectural styles/idiomsarchitectural style =
Components: locus of computationfilters, databases, objects, clients, servers, ADTs
Connectors: mediate interactions of componentsprocedure call, pipes, event broadcast
Properties: specify info for construction & analysisSignatures, pre/post conditions, RT specifications
othertopologyunderlying structural model?underlying computational model?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Expected Benefits
© David Garlan CMU
update document
6%
test & debug
28%
define/analyze change
18%
trace logic
23%
implement change
19%
review document
6%
Requirements
Architecture
Design
CodeIntegration
TestAccept
Maintenance
• Clarify intentions•Make decisions and
implications explicit• Permit system level
analysis
• Reduce maintenancecosts, directly andindirectly
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 23
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
independentcomponents
communicatingprocesses event systems
implicitinvocation
explicitinvocation
dataflow
batchsequential
pipes & filters
virtual machine
rule-basedsystem
interpreter
data-centered
repository blackboard
call/return
main prog.& subroutine
object-orientedlayered
taxonomy
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
“Boxology”
Control issuesTopology
geometric form of the control flow for the system:linear (non-branching), acyclic, hierarchical, star,arbitrary
Synchronicity Interdependency of the component control states:
lockstep (sequential or parallel), synchronous,asynchronous, opportunistic
Binding time time the identity of a partner in a transfer-of-control
operation is established: write (i.e., source code)time, compile time, invocation time, run time
Data issuesTopology
geometric shape of the system’s data flow graph:linear (non-branching), acyclic, hierarchical, star,arbitrary
Continuity the flow of data throughout the system: continuous,
sporadic, high-volume (in data-intensive systems),low-volume (in compute-intensive systems)
Data issuesMode
data is made available throughout thesystem: passed (object style from componentto component), shared: copyout-copy-in,broadcast, multicast
Binding time time identity of a partner in a data operation is
established: write (i.e., source code
Control/data interaction issuesShape
control flow and data flow topologiesisomorphic
Directionality If shapes the same, does control flow in the
same direction as data or the oppositedirection.
Type of reasoning nondeterministic state machine
theory, function composition software substructure and analysis
substructure should be compatible.
• Components and connectors• primary building blocks of architectures• abstractions used by designers in defining their architectures• most of these elements are ultimately implemented in terms of processes (as defined by the
operating system) and procedure calls (as defined by the programming language).
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 24
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
validate sort update report tape tapetapetape
data transformation
data flow
computation
sed grep awk
stdin stdout
data flow (ascii stream)
taxonomy:data flow
batch sequentialindependent programs,dataflow in large chunks, noparallelism
pipes & filtersincremental, byte streamdata flow, pipelined“parallelism”, local context,no state persistence
dataflow
batchsequential
pipes & filters
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Boxology: dataflow
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 25
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
*to some extent batch
Analysis: pipes & filters*problem decomposition
advantages: hierarchical decomposition of systemfunctiondisadvantages: “batch mentality,” interactive apps?,design
maintenance & reuseadvantages: extensibility, reuse, “black box” approachdisadvantages: lowest common denominator for dataflow
performanceadvantages: pipelined concurrencydisadvantages: parsing/un-parsing, queues, deadlockwith limited buffers
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Rules of thumb for dataflow/pipes If your problem can be decomposed into sequential stages,
consider batch sequential or pipeline architecturesIf in addition each stage is incremental, so that later stagescan begin before earlier stages complete, then consider apipelined architecture
If your problem involves transformations on continuousstreams of data (or on very long streams) consider a pipelinearchitectureHowever, if your problem involves passing rich datarepresentation, then avoid pipeline architectures restricted toASCII
If your system involves controlling action, is embedded in aphysical system, and is subject to unpredictable externalperturbation so that preset algorithms go awry, consider aclosed loop architecture
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 26
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
main
sub sub sub
sub sub sub sub sub sub
sub sub sub
obj
obj
obj
obj obj
taxonomy: call/returnmain/sub
hierarchicaldecomposition, singlethread of control,structure implicit,correctness depends onsubordinates
layeredhides lowerlayers/services higherlayer, upper=“virtualmachines”/lower =hw,kernel, scoping
object-orientedencapsulation,inheritance,polymorphism
call/return
main prog.& subroutine
object-orientedlayered
basic utilityuseful system
user interface
core
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Analysis: call/return layers
portability, modifiability, reuseadvantages: each layer is abstract machine, each layer interacts
with ≤ 2 other layers, standard interfacesperformance, design
disadvantages: semantic feedback in UI, deep functionality,abstractions difficult, bridging layers
object-orientedportability, modifiability, reuse
advantages: decreased coupling, frameworks -> reusedisadvantages: complex structure
performance, designadvantages: maps easily to “real world”, inheritance, encapsulationdisadvantages: design harder, side effects, identity, inheitance
difficult
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 27
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
app module
shared d b
app module
app module
app module
app module
app module
knowledgesource
blackboard
knowledgesource
knowledgesource
knowledgesource
knowledgesource
knowledgesource
data-centered
repository blackboard
Taxonomy: data-centered
transactional dblarge central data store, control viatransactions
blackboardscentral shared + app-specific datarepresentations, control via data state
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Rules of thumb: objects and repositories
If a central issue is understanding the data of theapplication, its management, and its representation,consider a repository or ADT architecture; if the data islong-lived focus on repositories
If the representation of data is likely to change over thelifetime of the program, ADTs or objects can confinethe changes to particular components
If you are considering repositories and the input data is“noisy” and the execution order can not bepredetermined, consider a blackboard
If you are considering repositories and the executionorder is determined by a stream of incoming requestsand the data is highly structured, consider a DB system.
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 28
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Taxonomy:independent components
communicating processesindependent processes, point-point message passing,asynch/synch, RPC layered ontop
event systemsinterface define allowable in/outevents, event-procedurebindings: procedure“registration”, communiation byevent “announcement”, implicitaction invocation on event, non-deterministic ordering
manager
proc
proc
proc
proc proc
independentcomponents
communicatingprocesses event systems
implicitinvocation
explicitinvocation
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Boxology: independent components
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 29
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
analysisevent systemsportability, modifiability, reuse
advantages: no “hardwired names”, new objects addedby registrationdisadvantages: nameserver/”yellowpages” needed
performance, designadvantages: computation & coordination are separateobjects/more independent, parallel invocationsdisadvantages: no control over order of invocation,correctness, performance penalty from communicationoverhead
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Rules of thumbIf your task requires a high degree of flexibility-configurability, loose coupling between tasks, andreactive tasks, consider interacting processesIf you have reason not to bind the recipients of signalsto their originators, consider an event architectureIf the task are of a hierarchical nature, consider areplicated worker or heartbeat styleIf the tasks are divided between producers andconsumers, consider a client-server style (naïve orsophisticated)If it makes sense for all of the tasks to communicatewith each other in a fully connected graph, consider atoken-passing style
CMPSCI520/620 --Design & SoftwareArchitecture
©Rick Adrion 2005 (except where noted) 30
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
data(program state) program
internalstate
interpretationengine
inputs
outputs
statedata
programinstructionsupdatesdata
selected instr,
selected data
workingmemory
factmemory
rule/dataselection
interpretationengine
inputs
outputs
triggeringdata
rules/factsupdatesdata
selected rules
selected data
rulememory
virtual machine
rule-basedsystem
interpreter
taxonomy: virtual machines
interpreterssimulate functionality which isnot native to the run-timesystem; execution engine“implemented” in software
rule-based systemsspecialization of an interpreter
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005
Analysis: virtual machinesinterpretersportability, modifiability, reuse
disadvantages: map into actual implementation?performance, design
advantages: simulate non-native functionality, cansimulate “disaster” modes for safety analysisdisadvantages: much slower than actual system,additional layer of software to be verified
Rules of thumb: virtual machinesIf you have designed a computation, but have nomachine on which you can execute it, consider a virtualinterpreter architecture.