17- software architectureadrion/520-f03/pdf-links/17-soft-arch.pdf · cmpsci520/620 ”rick adrion...

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


But first

ßA review of UML software development


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


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



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


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


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


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



ControlProcess

(CP)

Prop LossModel

(MODP)

ReverbModel

(MODR)

NoiseModel

(MODN)

Architecture was largely ad hoc

ßis this an architecture?


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?


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?


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



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


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)


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


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



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)


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.


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


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



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?


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


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


“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



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


Boxology: dataflow


*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


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



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


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


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


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



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


Boxology: independent components


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


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



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


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.


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.


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



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


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.)


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


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



example: process view

components

process

style: indep.comonentsnotation: Booch (Ada tasking)

message

unspecified

connectors


terminal process

connectorscontroller process

controller task(low rate)

controller task(high rate)

controller task(Main)


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


components

module

style: layerednotation: Booch

layer

connectors

subsystem

dependency


layer1

layer3

layer4

layer5

layer2

human-computer interfaceexternal systems

.

.

.

.

bindings

example: development view


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



components

processor

style: indep.comonentsnotation: UNAS

hi-bw comm line

comm line

connectors

other device

comm line (non-perm)

uni-dir comm line


KK

C

F F F F

C

KK KK KK KK KK

primary

backupprimary primary

backup

backup

example: physical view


Physical view (with process allocation)example: Alcatel PBX

C

F F

primary

backupprimary

K K K


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


controller terminal numberingplan

conversation

(1) off-hook

(2) dial tone

(3) digit

(4) digit

(5) open conversation

Scenarios

CMPSCI520/620



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


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


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


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



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.


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.


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


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



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.


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


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.


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



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


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


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



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



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


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


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


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



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


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


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.


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



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


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



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



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



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



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).


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


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


17- software architectureadrion/520-f03/pdf-links/17-soft-arch.pdf · cmpsci520/620 ”rick adrion...

Documents