17- software architectureadrion/520-f03/pdf-links/17-soft-arch.pdf · cmpsci520/620 ”rick adrion...
TRANSCRIPT
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 1
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
17- Software Architecture
Rick Adrion
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
But first
ßA review of UML software development
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
O-O System Development
adapted from Bruegge/Dutoit O-O SW Engr
problemstatement
Requirementselicitation
Requirementsanalysis
System design
system designobject model
design goals subsystemdecomposition
functionalmodel
nonfunctionalrequirements
use casediagram
analysisobject model
classdiagram
dynamicmodel
statechartdiagram
sequencediagram
Implementation
sourcecode
Test
deliverablesystem
Object design
object designmodel
classdiagram
RFP
interviews
Project 3
Project2
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
O-O System Development
adapted from Bruegge/Dutoit O-O SW Engr
designview
deploymentview
processview
implementationview
Use -CaseView
Use cases
Components
Classes, interfaces,collaborations
Active classes Nodes
OrganizationPackage, subsystem
DynamicsInteraction
State machine
problemstatement
Requirementselicitation
Requirementsanalysis
System design
system designobject model
design goals subsystemdecomposition
functionalmodel
nonfunctionalrequirements
use casediagram
analysisobject model
classdiagram
dynamicmodel
statechartdiagram
sequencediagram
Implementation
sourcecode
Test
deliverablesystem
Object design
object designmodel
classdiagram
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 2
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Adapted from
ßVarious sources including:ßDavid Garlan, “Software Architecture: a Roadmap,”Proceedings of the conference on The future of Softwareengineering, Limerick, Ireland, June 04 - 11, 2000
ßM. Shaw and P. Clements,”A field guide to boxology:Preliminary classification of architectural styles for softwaresystems,” Proceedings of COMPSAC 1997, August 1997
ßM. Shaw and D. Garlan, Tutorial Slides on SoftwareArchitecture 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 SoftwareArchitecture,” Technical report, The Software EngineeringInstiute, Carnegie Mellon University
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Software Architecture
ßarchitecture of a system describes its gross structure
ßilluminates the top level design decisionsßhow the system is composed of interacting parts
ßthe main pathways of interaction
ßthe key properties of the parts
ßallows high-level analysis and critical appraisal
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Roles of Software Architecture
ßa bridge between requirements and implementationßan abstract description of a system,
ßexposes certain properties, while hiding others.
ßuseful for:ßUnderstanding
ßReuse
ßConstruction
ßEvolution
ßAnalysis
ßManagement
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Roles of Software Architecture
ß Understanding:ß simplifies the understanding of large
systems using an abstractionß constraints on system designß rationale
ß Constructionß a partial blueprint for development:
components and dependencies
ß Evolutionß dimensions along which a system is
expected to evolveß "load-bearing walls" -> ramifications of
changes, cost estimationß separate concerns about the
functionality of a component from theways in which that component isconnected to (interacts with) othercomponents
ßAnalysisßconsistency checkingßconformanceß to constraintsß to quality attributes
ßdependence analysisßdomain-specific analyses for
architectural styles
ßReuseß reuse of large components
and frameworks
ßManagementß leads to a much clearer
understanding of requirements,implementation strategies, andpotential risks
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 3
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
ControlProcess
(CP)
Prop LossModel
(MODP)
ReverbModel
(MODR)
NoiseModel
(MODN)
Architecture was largely ad hoc
ßis this an architecture?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
ControlProcess
(CP)
Prop LossModel
(MODP)
ReverbModel
(MODR)
NoiseModel
(MODN)
Example
ßwhat is the nature of the components,and what is the significance of theirseparation?ßdo they run on separate processors?ßdo they run at separate times?ßdo the components consist ofprocesses, programs, or both?ßdo the components represent ways inwhich the project labor will be divided,or do they convey a sense of runtimeseparation?ßare they modules, objects, tasks,functions, processes, distributedprograms, or something else?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
ControlProcess
(CP)
Prop LossModel
(MODP)
ReverbModel
(MODR)
NoiseModel
(MODN)
Example
ßwhat is the significance of the links?ßdo the links mean the componentscommunicate with each other, controleach other, send data to each other,use each other, invoke each other,synchronize with each other, or somecombination of these or otherrelations?
ßwhat is the significance of the layout?ßwhy is CP on a separate (higher) level?ßdoes it call the other threecomponents, and are the others notallowed to call it?ßwas there simply not room enough toput all four components on the samerow in the diagram?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Historically
ßArchitecture was largely ad hoc affairßDesigners freely use informal patterns/idiomsß informal with imprecise semanticsßdiagrams + prose, but no rules
ßDesigners use system-level abstractionßoverall organization (styles)ßcomponents and interactions
ßDesigners compose systems from subsystemsßbut, tend to think staticallyßselect structure by default, rather than by design
ßKey eventsßParnas recognized the importance of system families andarchitectural decomposition principles based on informationhidingßDijkstra proposed certain system structuring principles
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 4
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Abstraction techniques in CS
ßProgramming Languagesßmachine languageßsymbolic assemblersßmacro processorsßearly high-level languagesßFortranßdata types served primarily as cues for selectingthe proper machine instructions
ßAlgol and it successorsßdata types serve to state the programmer’sintentions about how data should be used.
ßlater high-level languagesßseparation 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 520/620 CI 520/620 FFALL 2003ALL 2003
Abstraction techniques in CS
ßADTß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)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
two trends
ßrecognition 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 520/620 CI 520/620 FFALL 2003ALL 2003
two trends
ß recognition of a shared repertoire of methods, techniques, patternsand idioms for structuring complex software systemsß “Camelot is based on the client-server model and uses remote
procedure calls both locally and remotely to provide communicationamong applications and servers.”ß “Abstraction layering and system decomposition provide the
appearance 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 to
managing information.”ß “The easiest way to make the canonical sequential compiler into a
concurrent 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
”Rick Adrion 2003 (except where noted) 5
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
two trends
ßconcern 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 based onlayered 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 520/620 CI 520/620 FFALL 2003ALL 2003
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, it canbe applied to other systems exhibiting similarrequirements, and can promote large scale reuse.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
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.
ßarchitectureßprovides builders with constraints on implementationßdictates organizational structure for development andmaintenance projectsßpermits or precludes the achievement of a system’s targetedquality attributesßHelps in predicting certain qualities about a systemarchitecture can be the basis for trainingßhelps in reasoning about and managing change
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
elements, form, rationale, views
architecture=
ßelementsßprocessing
ßdata
ßconnectors
ß formß rules which constrain
element placement
ßstyle/design
ß rationaleßselection of form
ß links to reqmnts & design
ß functional/non-functionalattributes
lexer parsersemanticanalyzer
codegenerator
optimizer
chars tokens phrasescorrelatedphrases
correlatedphrases
annotatedcorrelatedphrases
lexer parsersemanticanalyzer
codegenerator
optimizer
hastokens
hasphrases
hascorrelatedphrases
hasannotatedcorrelatedphrases
codegenerator
Process View
Data View
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 6
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
architectural styles/idioms
ßarchitectural style =ßComponents: locus of computationßfilters, databases, objects, clients, servers, ADTs
ßConnectors: mediate interactions of componentsßprocedure call, pipes, event broadcast
ßProperties: specify info for construction & analysisßSignatures, pre/post conditions, RT specifications
ßotherßtopology
ßunderlying structural model?
ßunderlying computational model?
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Expected Benefits
” David Garlan CMU
update document6%
test & debug28%
define/analyze change18%
trace logic23%
implement change19%
review document6%
RequirementsRequirements
ArchitectureArchitecture
DesignDesign
CodeIntegration
CodeIntegration
TestAccept
TestAccept
MaintenanceMaintenance
• Clarify intentions• Make decisions and
implications explicit• Permit system level
analysis
• Reduce maintenancecosts, directly andindirectly
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
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-oriented
layered
taxonomy
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
“Boxology”
ßControl issuesß Topologyß 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 issuesß Topologyß 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 issuesßModeß data is made available throughout the system:
passed (object style from component tocomponent), 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 issuesß Shapeß control flow and data flow topologies
isomorphic
ß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 theoperating system) and procedure calls (as defined by the programming language).
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 7
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
validate sort update report
tape tapetapetape
data transformation
data flow
computation
sed grep awk
stdin stdout
data flow (ascii stream)
taxonomy:data flow
ßbatch sequentialßindependent programs,dataflow in large chunks, noparallelism
ßpipes & filtersßincremental, 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 520/620 CI 520/620 FFALL 2003ALL 2003
Boxology: dataflow
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
*to some extent batch
Analysis: pipes & filters*
ßproblem decompositionßadvantages: hierarchical decomposition of systemfunctionßdisadvantages: “batch mentality,” interactive apps?,design
ßmaintenance & reuseßadvantages: extensibility, reuse, “black box” approachßdisadvantages: lowest common denominator for dataflow
ßperformanceßadvantages: pipelined concurrencyßdisadvantages: parsing/un-parsing, queues, deadlockwith limited buffers
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Rules of thumb for dataflow/pipes
ß If your problem can be decomposed into sequential stages,consider batch sequential or pipeline architecturesßIf 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 pipelinearchitectureßHowever, 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
”Rick Adrion 2003 (except where noted) 8
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
main
sub sub sub
sub sub sub sub sub sub
sub sub sub
obj
obj
obj
objobj
taxonomy: call/returnßmain/subßhierarchicaldecomposition, singlethread of control,structure implicit,correctness depends onsubordinates
ß layeredßhides lowerlayers/services higherlayer, upper=“virtualmachines”/lower =hw,kernel, scoping
ßobject-orientedßencapsulation,inheritance,polymorphism
call/return
main prog.& subroutine
object-oriented
layered
basic utility
useful system
user interface
core
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Analysis: call/return
ß layersßportability, modifiability, reuseßadvantages: each layer is abstract machine, each layer interacts
with ≤ 2 other layers, standard interfaces
ßperformance, designßdisadvantages: semantic feedback in UI, deep functionality,
abstractions difficult, bridging layers
ßobject-orientedßportability, modifiability, reuseßadvantages: decreased coupling, frameworks -> reuseßdisadvantages: complex structure
ßperformance, designßadvantages: maps easily to “real world”, inheritance, encapsulationßdisadvantages: design harder, side effects, identity, inheitance
difficult
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
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 dbßlarge central data store, control viatransactions
ßblackboardsßcentral shared + app-specific datarepresentations, control via data state
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
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 confine thechanges 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
”Rick Adrion 2003 (except where noted) 9
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Taxonomy:independent components
ßcommunicating processesßindependent processes, point-point message passing,asynch/synch, RPC layeredon top
ßevent systemsßinterface define allowablein/out events, event-procedurebindings: procedure“registration”, communiationby event “announcement”,implicit action invocation onevent, non-deterministicordering
manager
proc
proc
proc
procproc
independentcomponents
communicatingprocesses
event systems
implicitinvocation
explicitinvocation
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Boxology: independent components
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
analysis
ßevent systems
ßportability, modifiability, reuseßadvantages: no “hardwired names”, new objects addedby registration
ßdisadvantages: nameserver/”yellowpages” needed
ßperformance, designßadvantages: computation & coordination are separateobjects/more independent, parallel invocations
ßdisadvantages: 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 520/620 CI 520/620 FFALL 2003ALL 2003
Rules of thumb
ßIf your task requires a high degree of flexibility-configurability, loose coupling between tasks, andreactive tasks, consider interacting processesßIf you have reason not to bind the recipients of signals totheir originators, consider an event architecture
ßIf the task are of a hierarchical nature, consider areplicated worker or heartbeat style
ßIf 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 communicate witheach other in a fully connected graph, consider a token-passing style
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 10
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
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
ßinterpretersßsimulate functionality which isnot native to the run-timesystem; execution engine“implemented” in software
ßrule-based systemsßspecialization of an interpreter
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Analysis: virtual machines
ßinterpreters
ßportability, modifiability, reuseßdisadvantages: map into actual implementation?
ßperformance, designßadvantages: simulate non-native functionality, cansimulate “disaster” modes for safety analysis
ßdisadvantages: much slower than actual system,additional layer of software to be verified
ßRules of thumb: virtual machinesßIf you have designed a computation, but have nomachine on which you can execute it, consider a virtualinterpreter architecture.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Problem and Solution
ß Problem:ßSoftware architecture is too complex to be capturedusing a single diagram, and not all aspects of it areinteresting at different moments and to differentstakeholders. How to manage this complexity?
ß Solution:ßRepresent different aspects and different characteristicsof the architecture through multiple views.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Views
ß What is a view?ßA view is a presentation of a model, which is a completedescription of a system from a particular perspective.
ß Proposed views:ßLogical View - captures the object model
ßProcess View - captures the concurrency andsynchronization aspects
ßDevelopment View - captures static organization of thesoftware in its development environment
ßPhysical View - captures the way software is mapped onhardware
ßThe “4+1” view: these plus scenarios
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 11
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
logicalview
physicalview
processview
developmentview
scenarios
end users• functionality
system engineers• system topology• delivery• installation• telecommunication
system integrators• performance• scalability• throughput
programmers• software management
4+1 view of software architecture
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
The Logical Architecture
ß Represented by Logical Viewßof interest to end-user
ßsupports functional requirements
ßpresents key abstractions mostly from the problemdomain
ß Class diagrams show how classes are groupedtogether, class’ interface (functionality) and associationsß“close” to the Development Architecture
ß usually deduced from Scenario View (or Use-Caseview)
ß many case tools support it (UML tools, E-R tools etc.)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
example: logical view
class
class utility
parameterizedclass
class category
associationcontainment,agregationusageinheritanceinstantiation
formal args
style: object-orientednotation: Booch
translationservices
connectionservices
numbering plan
example: Alcatel PBX
conversation
Terminal
Controller
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
The Process Architecture
ß Represented by Process Viewßof interest to system designer, integrator
ßconcerned with performance, availability, S/W faulttolerance, integrity
ßpresents concurrency and distribution of processes, howabstractions from Logical View map to processes
ß Components:Tasks
ßConnectors: rendezvous, broadcasts,…
ßContainers: processß“close” to the Physical Architecture
ßtool support: UNAS/SALE, DADS
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 12
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
example: process view
components
process
style: indep.comonentsnotation: Booch (Ada tasking)
message
unspecified
connectors
example: Alcatel PBX
terminal process
connectorscontroller process
controller task(low rate)
controller task(high rate)
controller task(Main)
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
The Development Architecture
ß Represented by Development Viewßof interest to developer, manager
ßconcerns: organization, reuse, portability, line-of-product
ßpresents actual software module organization
ßsubsystems organized in a hierarchy of layers
ß“close” to the Logical Architectureßusually deduced from Logical Architecture
ßtools: Apex, SoDA
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
components
module
style: layerednotation: Booch
layer
connectors
subsystem
dependency
example: Alcatel PBX
layer1
layer3
layer4
layer5
layer2
human-computer interfaceexternal systems
.
.
.
.
bindings
example: development view
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
The Physical Architecture
ß Represented by Physical Viewßof interest to system designer
ßconcerns: scalability, performance, availability, reliability
ßpresents how processes, objects etc. are mapped ontoprocessing nodes
ß Components:processing nodes
ß Connectors: LAN, WAN, bus,…
ß Containers: Physical Subsystemß“close” to the Process Architecture
ßstrongly influenced by Process Architecture
ßtools: UNAS, DADS
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 13
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
components
processor
style: indep.comonentsnotation: UNAS
hi-bw comm line
comm line
connectors
other device
comm line (non-perm)
uni-dir comm line
example: Alcatel PBX
KK
C
F F F F
C
KK KK KK KK KK
primary
backupprimary primary
backup
backup
example: physical view
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Physical view (with process allocation)example: Alcatel PBX
C
F F
primary
backupprimary
K K K
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Scenarios
ß Instances of Use-Cases, unify all viewsßof interest to end-user, developer
ßconcerns: understandability
ß Textual domain process descriptions, object scenariodiagrams and object interaction diagramsßused as a driver to discover architectural elements,validation of design
ßtools: UML case tools
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
controller terminal numberingplan
conversation
(1) off-hook
(2) dial tone
(3) digit
(4) digit
(5) open conversation
Scenarios
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 14
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
designview
deploymentview
processview
implementationview
Use -CaseView
Use cases
Components
Classes, interfaces,collaborations
Active classes Nodes
OrganizationPackage, subsystem
DynamicsInteraction
State machine
The Rational 4+1 Views
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
UML SW Development Life Cycle
ßUse-case drivenßuse cases are used as a primary artifact for establishing thedesired behavior of the system, for verifying and validating thesystem’s architecture, for testing, and for communicatingamong the stakeholders of the project
ßArchitecture-centricßa system’s architecture is used as a primary artifact forconceptualizing, constructing, managing, and evolving thesystem under development
ß Iterativeßone that involves managing a stream of executable releases
ß Incrementalßone that involves the continuous integration of the system’sarchitecture to produce these releases
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Architectural View Mismatches in UMLArchitectural View Mismatches in UML
ßDifferent UML diagrams present different system views
ßredundant information across views
ßKey challenge is to ensure inter-view consistency
ßRamifications on round-trip engineering
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Round-Trip Software Engineering Using UMLRound-Trip Software Engineering Using UML
Nenad Medvidovic Assessing the Suitability of UMLAssessing the Suitability of UMLfor Modeling Software Architecturesfor Modeling Software Architectures
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 15
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Architecture Description Languages
ßformal notations for representing and analyzingarchitectural designs
ßprovide both a conceptual framework and a concretesyntax for characterizing software architectures
ßtools for parsing, displaying, compiling, analyzing, orsimulating architectural descriptions.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
ADL Examplesß Adageß supports the description of architectural frameworks for avionics navigation
and guidanceß Aesopß supports the use of architectural styles
ß C2ß supports the description of user interface systems using anevent-based style
ß Darwinß supports the analysis of distributed message-passing systems
ßMeta-Hß provides guidance for designers of real-time avionics control software;
ß Rapideß allows architectural designs to be simulated, and has tools for analyzing the
results of those simulations;ß SADLß provides a formal basis for architectural refinement;
ß UniConß has a high-level compiler for architectural designs that supports a mixture of
heterogeneous component and connector types;ßWrightß supports the formal specification and analysis of interactions between
architectural components.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
formal architectural specification.
ßmodule interconnection languagesßstatic aspects of component interactionßdefinition and use of types, variables, and functions amongcomponentsßexamples: INTERCOL, PIC, CORBA/IDL
ßprocess algebrasßdynamic interplay among componentsßconcerned with the protocols by which componentscommunicateßexamples: Wright (based on CSP), Chemical AbstractMachine (based on term rewriting)
ßevent languagesß identification and ordering of eventsßevent is a very flexible, abstract notionßexample: Rapide
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Evaluation & analysis
ßconduct a formal review with external reviewersßtime the evaluation to best advantageßchoose an appropriate evaluation techniqueßcreate an evaluation contractßlimit the number of qualities to be evaluatedßinsist on a system architectßbenefitsßfinancialßincreased understanding and documentation of thesystemßdetection of problems with the existing architectureßclarification and prioritization of requirementsßorganizational learning
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 16
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Benefits
ßexamplesßAT&Tß10% reduction in project costs, on projects of 700 staff daysor longer, the evaluation pays for itself.
ßconsultantsßreported 80% repeat business, customers recognizedsufficientvalue
ßwhere architecture reviews did not occurßcustomer accounting system estimated to take two years,took seven years, re-implemented three times, performancegoals never met
ß large engineering relational database system, performancemade integration testing impossible, project was cancelledafter twenty million dollars had been spent.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Architecture vs FrameworksßFrameworksßan object-oriented reuse techniqueßused successfully for some time & are an importantpart of the culture of long-time object-orienteddevelopers,ßBUT they are not well understood outside theobject-oriented community and are often misused
ßQuestion:ßare frameworks mini-architectures, large-scalepatterns, or they are just another kind ofcomponent?
ßDefinitionsßa framework is a reusable design of all or part of asystem that is represented by a set of abstractclasses and the way their instances interactßa framework is the skeleton of an application thatcan be customized by an application developer
Ralph E. Johnson, “Frameworks= (Components+Patterns).”Communications of the ACM, October 1997/Vol. 40, No. 10
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Frameworks & Class Libraries
ßdevelopers often do not even know they are using aframework, but refer to a “class library”
ßframeworks differ from other class libraries by reusinghigh-level designßmore to learn before a class can be reused
ßcan never be reused in isolation; typically a set ofclasses must be learned at once
ßyou can often tell that a class library is a framework ifthere are dependencies among its components and ifprogrammers who are learning it complain about itscomplexity.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Framework Architecture
Class Library Architecture
ADTs
Strings
LocksIPC
Math
LOCAL INVOCATIONS APPLICATION-
SPECIFICFUNCTIONALITY
GLUECODE
Files
GUIEVENTLOOP
Frameworks & Class Libraries
ßA class is a unit of abstraction& implementation in an OOprogramming language
ßA framework is an integratedset of abstract classes thatcan be customized forinstances of a family ofapplications
Adapted from Douglas C. Schmidt, “Patterns, Frameworks, & Middleware: Their Synergistic Relationships”
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 17
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Components & frameworks
ßFrameworksßwere originally intended to be reusablecomponentsßbut reusable O-O components have not found amarket
ßare a component in the sense thatßvenders sell them as productsßan application might use several frameworks.
ßBUTßthey more customizable than most componentsßhave more complex interfacesßmust be learned before the framework can be used
ßa component represents code reuse, whileframeworks are a form of design reuse
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Components & frameworksßframeworksßprovide a reusable context for componentsßprovide a standard way for components to handleerrors, to exchange data, and to invoke operationson each otherß“component systems’’ such as OLE, OpenDoc, and Beans,are really frameworks that solve standard problems thatarise in building compound documents and other compositeobjects. make it easier to develop new components
ßenable making a new component (such as a userinterface) out of smaller components (such as awidget)ßprovide the specifications for new components anda template for implementing them.
ßa good framework can reduce the amount ofeffort to develop customized applications by anorder of magnitude
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Middleware Bus
Component Architecture
Naming
LockingLogging
Events
Framework Architecture
ADTs
Locks
Strings
Files
INVOKES
Reactor
GUI
DATABASE
NETWORKING
APPLICATION-SPECIFICFUNCTIONALITY CALLBACKS
Frameworks & Components
ßA framework is an integratedset of abstract classes thatcan be customized forinstances of a family ofapplications
ßA component is anencapsulation unit with oneor more interfaces thatprovide clients with access toits services
Adapted from Douglas C. Schmidt, “Patterns, Frameworks, & Middleware: Their Synergistic Relationships”
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Comparison
Class Libraries FrameworksMacro-levelMeso-levelMicro-level
Borrow caller’s threadInversion ofcontrol
Borrow caller’sthread
Domain-specific or
Domain-independent
Domain-specificDomain-independent
Stand-alonecomposition entities
“Semi-complete”applications
Stand-alonelanguage entities
Components
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 18
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Frameworks as Reusable Design
ßAre they like other techniques for reusing high-leveldesign, e.g., templates or schemas?ßtemplates or schemasßusually depend on a special purpose design notationßrequire special software toolsßframeworksßare expressed in a programming languageßmakes them easier for programmers to learn and toapplyßno tools except compilersßcan gradually change an application into a frameworkßbecause they are specific to a programming language,some design ideas, such as behavioral constraints,cannot be expressed well
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Frameworksand domain-specific architectures
ßA framework is ultimately an object-oriented design, while adomain-specific architecture might not be.
ßA framework can be combined with a domain-specificlanguage by translating programs in the language into a setof objects in a frameworkßwindow builders associated with GUI frameworks areexamples of domain-specific visual programming languages
ßUniformity reduces the cost of maintenance
ßGUI frameworks give a set of applications a similar look andfeel
ßusing a distributed object framework ensures that allapplications can communicate with each other.
ßmaintenance programmers can move from one application tothe next without having to learn a new design
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Overview of Patterns
ßPatternsßpresent solutions to common software problemsarising within a certain context
ßhelp resolve key software design issuesßFlexibility, Extensibility, Dependability, Predictability,Scalability,Efficiency
ßcapture recurring structures & dynamics amongsoftware participants to facilitate reuse ofsuccessful designs
ßcodify expert knowledge of design strategies,constraints and best practices
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
software patterns
ßrecord experience of good designersßdescribe general, recurring design structures in apattern-like formatßproblem, generic solution, usageßsolutions (mostly) in terms of O-O modelsßcrc-cards; object-, event-, state diagramsßoften not O-O specificßpatterns are generic solutions; they allow for design andimplementation variationsßthe solution structure of a pattern must be “adapted” toyour problem designßmap to existing or new classes, methods, ...ßa pattern is not a concrete reusable piece of software!
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 19
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
qualities of a pattern
ßencapsulation and abstractionßeach pattern encapsulates a well-defined problem and itssolution in a particular domainßserve as abstractions which embody domain knowledge andexperience
ßopenness and variabilityßopen for extension or parametrization by other patterns so thatthey may work together
ßgenerativity and composabilityßgenerates a resulting context which matches the initial contextof one or more other patterns in a pattern languageßapplying one pattern provides a context for the application ofthe next pattern.
ßequilibriumßbalance among its forces and constraints
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Active Object, Bridge,Proxy, WrapperFaçade, & Visitor
Capture the static & dynamic roles &relationships in solutions that occurrepeatedly
Design patterns
Half-Sync/Half-Async,Layers, Proactor,Publisher-Subscriber,& Reactor
Express a fundamental structuralorganization for software systems thatprovide a set of predefined subsystems,specify their relationships, & include therules and guidelines for organizing therelationships between them
Architecturalpatterns
Optimize for commoncase, passinformation betweenlayers
Document rules for avoiding commondesign & implementation mistakes thatdegrade performance
Optimizationprinciple patterns
Scoped lockingRestricted to a particular language, system,or tool
Idioms
ExamplesDescriptionType
Taxonomy of Patterns & Idioms
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Frameworks and Patterns
ßframeworks represent a kind of patternße.g., Model/View/Controller is a user-interface frameworkoften described as a patternßapplications that use frameworks must conform to theframeworks’ design and model of collaboration, so theframework causes patterns in the applications that use it.
ßframeworks are at a different level of abstraction thanpatternsßframeworks can be embodied in code, but only examplesof patterns can be embodied in code.ßa strength of frameworks is that they can be written downin programming languages and not only studied butexecuted and reused directlyßin contrast, design patterns have to be implemented eachtime they are used.
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Frameworks and Patterns
ßdesign patterns are smaller architectural elements than frameworksßa typical framework contains several design patterns but the reverse
is never trueßdesign patterns are the micro-architectural elements of frameworks.ß e.g., Model/View/Controller can be decomposed into three major design
patterns, and several less important onesßMVC uses the Observer pattern to ensure the view’s picture of the model is
up-to-date, the Composite pattern to nest views, and the Strategy patternto cause views to delegate responsibility for handling user events to theircontroller.
ßdesign patterns are less specialized than frameworks.ß frameworks always have a particular application domain.ßdesign patterns can be used in nearly any kind of application.ßmore specialized design patterns are certainly possible, even these
wouldn't dictate an application architecture
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 20
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Frameworks
ßare firmly in the middle of reuse techniques.
ßare more abstract and flexible than components,
ßare more concrete and easier to reuse than a puredesign (but less flexible and less likely to be applicable)
ßare more like techniques that reuse both design andcode, such as application generators and templates.
ßcan be thought of as a more concrete form of a patternßpatterns are illustrated by programs, but a framework isa program
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Application-specific functionality
Framework Characteristics
ßFrameworks exhibit“inversion of control” atruntime via callbacks
ßFrameworks provideintegrated domain-specific structures &functionality
ßFrameworks are “semi-complete” applications
Networking DatabaseGUI
MissionComputing
ScientificVisualizationE-commerce
Adapted from Douglas C. Schmidt, “Patterns, Frameworks, & Middleware: Their Synergistic Relationships”
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Using Frameworks Effectively
ßFrameworks are powerful, but hard to develop & useeffectively by application developersßIt’s often better to use & customize COTS frameworksthan to develop in-house frameworksßComponents are easier for application developers touse, but aren’t as powerful or flexible as frameworksßSuccessful projects are often organized using the“funnel” model
Adapted from Douglas C. Schmidt, “Patterns, Frameworks, & Middleware: Their Synergistic Relationships”
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Relation to Middleware
ßone of the strengths of frameworks is that they arerepresented by traditional object-oriented programminglanguages.ßBUT, this is also a weakness of frameworks, however,and it is one that the other design-oriented reusetechniques do not share.ßMiddlewareßCOM, CORBA, etc. address this problem, since they letprograms in one language interoperate with programs inanother
ßOther approachesßsome frameworks have been implemented twice so thatusers of two different languages can use them, such asthe SEMATECH CIM framework
CMPSCI520/620
”Rick Adrion 2003 (except where noted) 21
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Hardware
Domain-SpecificServices
CommonMiddleware Services
DistributionMiddleware
Host InfrastructureMiddleware
Operating Systems& Protocols
Applications
Evolution of Middleware
ßHistorically, mission-critical apps werebuilt directly atop hardware & OSßtedious, error-prone, & costly overlifecycles
ßThere are layers of middleware, just likethere are layers of networking protocolsßStandards-based COTS middleware
helps:ßControl end-to-end resources & QoSßLeverage hardware & softwaretechnology advancesßEvolve to new environments &requirementsßProvide a wide array of reuseable, off-the-shelf developer-oriented services
Adapted from Douglas C. Schmidt, “Patterns, Frameworks, & Middleware: Their Synergistic Relationships”
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Middleware
ß Infrastructure middleware.ßencapsulates core OS communication and concurrency services to
eliminate many tedious, error-prone, and non-portable aspects ofdeveloping and maintaining distributed applications using low-levelnetwork programming mechanisms, such as socketsßExamples: the Java Virtual Machine (JVM) and the ADAPTIVE
Communication Environment (ACE).ßDistribution middlewareßbuilds upon the lower-level infrastructure middleware to automate
common network programming tasks, such as parametermarshaling/demarshaling, socket and request demultiplexing, andfault detection/recoveryßExamples: Object Management Group's (OMG's) Common Object
Request Broker Architecture (CORBA), Microsoft's Distributed COM(DCOM), and JavaSoft's Remote Method Invocation (RMI).
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Middleware
ß Common middleware servicesß augments the distribution middleware by defining domain-independent
services, such as event notifications, logging, multimedia streaming,persistence, security, transactions, fault tolerance, and distributedconcurrency control
ß applications can reuse these services to perform common distribution tasksthat would otherwise be implemented manually.
ß Domain-specific Servicesß tailored to the requirements of particular domains, such as
telecommunications, e-commerce, health-care, or process automation
ß are generally reusable, and thus are the least mature of the middleware layerstoday
ß embody domain-specific knowledge, however, they have the most potential toincrease system quality and decrease the cycle-time and effort required todevelop particular types of networked applications
UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI 520/620 CI 520/620 FFALL 2003ALL 2003
Progress
ßsignificant progress in QoS-enabled middleware,stemming in large part fromthe following trends:ßyears of iteration,refinement, & successfuluseßmaturation of middlewarestandardsß .NET, J2EE, CCMßReal-time CORBAßReal-time JavaßSOAP & Web Services
ßmaturation of componentmiddleware frameworks &patterns
Year1970 2005
ARPAnet
RPC
Micro-kernels
CORBA & DCOM
Real-timeCORBA
Component Models (EJB)
CORBA ComponentModel (CCM)
Real-time CCM
DCE
Web Services
Adapted from Douglas C. Schmidt, “Patterns, Frameworks, & Middleware: Their Synergistic Relationships”