12 Design Software Architecture - www … · 12 Design ⇒ Software Architecture Introduction to...

CMPSCI520/620 --Design & SoftwareArchitecture

©Rick Adrion 2005 (except where noted) 1

UUNIVERSITYNIVERSITY OFOF M MASSACHUSETTS ASSACHUSETTS AAMHERSTMHERST •• D DEPARTMENTEPARTMENT OF OF CCOMPUTER OMPUTER SSCIENCE CIENCE •• CCMPMPSSCI CI 520/620520/620 FFALL ALL 20052005

12 Design ⇒ Software Architecture Introduction to Design Readings

[GJM03] Fundamentals of Software Engineering by Carlo Ghezzi, Mehdi Jazayeri, andDino Mandrioli, Second Edition, Prentice Hall; Chapter 4

[dlP72] Parnas David L., “On the criteria to be used in decomposing systems intomodules,” CACM, Dec., 1972

[dlP76] Parnas David L., “On the design and development of program families,” IEEETrans.SE., vol. SE-2, pp.1-9, Mar. 1976

[dlP79] Parnas, D.L. Designing software for ease of extension and contraction. In IEEETrans. SE, Mar. 1979

Science of Design: Software-Intensive Systems A National Science FoundationWorkshop Airlie Center, November 2-4, 2003http://www.cs.virginia.edu/~sullivan/sdsis/workshop%202003.htm

Software Architecture Readings David Garlan, “Software Architecture: a Roadmap,” Proceedings of the conference on

The future of Software engineering, Limerick, Ireland, June 04 - 11, 2000 M. Shaw and P. Clements,”A field guide to boxology: Preliminary classification of

architectural styles for software systems,” Proceedings of COMPSAC 1997, August1997

M. Shaw and D. Garlan, Tutorial Slides on Software Architecture http://www-2.cs.cmu.edu/afs/cs/project/tinker-arch/www/html/Tutorial_Slides/Soft_Arch/quick_index.html

Garlan, David & Shaw, “An Introduction To Software Architecture,” Technical report, TheSoftware Engineering Institute, Carnegie Mellon University


Modular DecompositionHow to define the structure of a modular system?

A module is a well-defined component of a software systemA module is part of a system that provides a set of services toother modules

What are desirable properties of a decomposition?CohesionCouplingComplexityCorrectnessCorrespondence

Strategies for decompositionInformation HidingLayering




Cohesion & CouplingCohesion: The reason that elements are found togetherin a moduleEx: coincidental, temporal, functional, …The details aren’t critical, but the intent is usefulDuring maintenance, one of the major structuraldegradations is in cohesion

Coupling: Strength of interconnection between modulesHierarchies are touted as a wonderful couplingstructure, limiting interconnectionsBut don’t forget about composition, which requiressome kind of coupling

It’s easy to......reduce coupling by calling a system a single module…increase cohesion by calling a system a single module


Coupling

Coupling also degrades over time“I just need one function from that module…”

Unnecessary coupling hurtsPropagates effects of changes more widelyHarder to understand interfaces (interactions)Harder to understand the designComplicates managerial tasksComplicates or precludes reuse




CouplingNo satisfactory measure of couplingEither across modules or across a systemCruickshank and Gaffney Coupling metric

Mj = sum of thenumber of input andoutput items sharedbetween components i& jZi = average number ofinput and outputitems shared over mcomponents withcomponent in = number ofcomponents in thesoftware product


Complexitysimpler designs are better, all else beingequalno useful measures of design/programcomplexity existAlthough there are dozens of such measuresLOC seems to be the most reliable predictorwhen single domains are considered, e.g.data processingnumerical processingsymbolic processing e.g., compilersconcurrent/distributed systems e.g., operating

systems




CorrectnessVery difficult (we’ll come back to this briefly laterin the course)Even if you “prove” modules are correct, how doyou proveComposition of the modules within and outside thesystem to be designedSystem software that must interpret/compile andrun the composed modulesHardware on which the complied modules run, etc.

Leveson and others have shown clearly that asystem can fail even when each of the pieceswork properly


Correspondence “Problem-program mapping” The way in which the design is associated with the

requirements The idea is that the simpler the mapping, the

easier it will be to accommodate change in thedesign when the requirements change

See M. Jackson: problem frames

Requirements Design Implementationcorrespondence correspondence




Functional decompositionDivide-and-conquer based on functions

input;

compute;

output

Then proceed to decompose computeThis is stepwise refinement (Wirth, 1971)There is an enormous body of work in this area,including many formal calculi to support theapproachClosely related to proving programs correctMore effective in the face of stable requirements


Properties of a modular structureAlmost all the literature focuses on logical structures in

design, but physical structure plays a big role in practiceSharingSeparating work assignmentsDegradation over time

To what degree do you consider your systemsas having modules?as consisting of a set of files?a question of physical vs. logical structure of programs

In some languages/environments, they are one and the same, e.g.,Smalltalk-80

How to define the structure of a modular system?A module is a well-defined component of a software systemA module is part of a system that provides a set of services toother modules where services are computational elements that other modules may use

Why so littleattention paid to this?




Modules and relationsLet S be a set of modules

S = {M1, M2, . . ., Mn}A binary relation★ R on S is a subset of

R ⊆ S x S If Mi and Mj are in S, <Mi, Mj> ∈ R can be written as

MiR Mj

Transitive closure R+ of R Mi R+ Mjiff MiR Mj or ∃ Mk in S s.t. MiR Mk and MkR+ Mj

R is a hierarchy iff there are no two elements Mi, Mj s.t.MiR Mj ∩ MjR Mi

Relations can be represented as graphs; a hierarchy is a DAG(directed acyclic graph)

★we assume our relations to be irreflexive


The uses relationA uses B; examples

A requires the correct operation of BA can access the services exported by B through its interfaceA depends on B to provide its servicesexample: A calls a routine exported by B

A is a client of B; B is a serverthe correctness of A depends on the presence of a correctversion of Brequires specification and implementation of A and thespecification of B

Criteria for uses(A,B)A is essentially simpler because it uses BB is not substantially more complex because it does not use AThere is a useful subset containing B but not AThere is no useful subset containing A but not B




The uses relationuses should be a hierarchy

Hierarchy makes software easier to understandProceed from leaf nodes (who do not use others)upwardsThey make software easier to buildThey make software easier to test

A non-hierarchical uses relation makes it difficultto produce useful subsets of a system -- ParnasIt also makes testing difficult(What about upcalls?)So, it is important to design the uses relation

Can uses be mechanically computed? uses not the same as invokes


The is_component_of RelationUsed to describe a higher level module asconstituted by a number of lower level modulesA is_component_of B

B consists of several modules, of which one is AB comprises AIf MS,i={Mk|Mk∈S ∧ Mk is_component_of Mi}

then we say that MS,i implements Mi

Careful recording of (hierarchical) uses andis_component_of relations supports design ofprogram families




A graphical view of is_component_of

M7

(is_component_of) (comprises)

They are a hierarchy

M8 M9 M5 M6

M2 M3 M4

M1 M7 M8 M9 M5 M6

M2 M3 M4

M1


Hierarchy

Organizes the modular structure throughlevels of abstractionEach level defines an abstract (virtual)machine for the next levellevel can be defined preciselyMi has level 0 if no Mj exists s.t. Mi R Mj

let k be the maximum level of all nodes Mj

s.t. Mi R Mj … then Mi has level k+1




Interface designInterface should not reveal what we expect maychange laterIt should not reveal unnecessary detailsInterface acts as a firewall preventing access to hiddenparts

PrototypingOnce an interface is defined, implementation can bedonefirst quickly but inefficientlythen progressively turned into the final version

Initial version acts as a prototype that evolves into thefinal product


Interface vs. implementationTo understand the nature of uses, we need to knowwhat a used module exports through its interfaceThe client imports the resources that are exported by itsserversModules implement the exported resourcesImplementation is hidden to clients

Clear distinction between interface and implementationis a key design principleSupports separation of concernsclients care about resources exported from serversservers care about implementation

Interface acts as a contract between a module and itsclients




Information hidingperhaps the most important intellectual tool developed to

support software design; makes anticipation of change acenterpiece in decomposition into modules

are OO & IH the same?OO classes are chosen based on the domain of the problem(in most OO analysis approaches), not necessarily based onchange, but they are obviously related (e.g., separatinginterface from implementation)

Notkin’s IH “Central Premises”1. can effectively anticipate changes2. changing an implementation is the best change, since it’sisolated

3. semantics of a module must remain unchanged whenimplementations are replaced

4. one implementation can satisfy multiple clients5. information hiding can be recursively applied


Layering [Parnas 79]Focus on information hiding modules isn’t enoughOne may also consider abstract machines

In support of program familiesSystems that have “so much in common that it pays tostudy their common aspects before looking at the aspectsthat differentiate them”

Still focusing on anticipated changeLots of language support for information hiding modules

C++ classes, Ada packages, etc.We have essentially no language support for layering

Operating systems provide support, primarily forreasons of protection, not abstractionBig performance cost to pay for “just” abstraction




Categories of modulesFunctional modules

traditional form of modularizationprovide a procedural abstractionencapsulate an algorithm

Librariesa group of related procedural abstractionse.g., mathematical libraries

implemented by routines of programming languages

Common pools of datadata shared by different modulese.g., configuration constants

the COMMON FORTRAN construct


Abstract Modules

Abstract objectsObjects manipulated via interface functionsData structure hidden to clients

Abstract data typesMany instances of abstract objects may begenerated




Abstract objectsExamples

calculator of expressions expressed in Polish postfixform: a*(b+c) abc+*a stack where the values of operands are shifted untilan operator (assume only binary operators) isencountered in the expressionInterface of the abstract object STACK

exportsprocedure PUSH (VAL: in integer);procedure POP_2 (VAL1, VAL2: out

How does the design anticipate change in type ofexpressions to be evaluated?e.g., it does not adapt to unary operators


indicates that details of thedata structure are hidden to clients

Abstract data types (ADTs)Example: stack ADT

ADTs correspond to Java and C++ classes & may alsobe implemented by Ada private types and Modula-2opaque types

module STACK_HANDLER

exports

type STACK = ?;

This is an abstract data -type module; the data structure

is a secret hidden in the implementation part.

procedure PUSH (S: in out STACK ; VAL: in integer); procedure POP (S: in out STACK ; VAL: out integer); function EMPTY (S: in STACK) : BOOLEAN;

.

.

.

end STACK_HANDLER




module FIFO_CARSuses CARSexports

type QUEUE : ?;procedure ENQUEUE (Q: in out QUEUE ; C: in CARS);procedure DEQUEUE (Q: in out QUEUE ; C: out CARS);function IS_EMPTY (Q: in QUEUE) : BOOLEAN;function LENGTH (Q: in QUEUE) : NATURAL;procedure MERGE (Q1, Q2 : in QUEUE ; Q : out QUEUE);This is an abstract data-type module representingqueues of cars, handled in a strict FIFO way;queues are not assignable or checkable for equality,since “:=” and “=” are not exported.…

end FIFO_CARS

Abstract data types (ADTs)Aother example: simulation of a gas station


Software Architecturearchitecture of a system describes its gross structure illuminates the top level design decisions

how the system is composed of interacting partsthe main pathways of interactionthe key properties of the parts

allows high-level analysis and critical appraisala bridge between requirements and implementation

an abstract description of a system,exposes certain properties, while hiding others.

useful for:UnderstandingReuseConstructionEvolutionAnalysisManagement




Roles of Software Architecture Understanding:

simplifies the understanding oflarge systems using an abstraction

constraints on system design rationale

Construction a partial blueprint for

development: components anddependencies

Evolution dimensions along which a system

is expected to evolve "load-bearing walls" ->

ramifications of changes, costestimation

separate concerns about thefunctionality of a component fromthe ways in which that componentis connected to (interacts with)other components

Analysis consistency checking conformance

to constraints to quality attributes

dependence analysis domain-specific analyses for

architectural styles Reuse

reuse of large components andframeworks

Management leads to a much clearer

understanding of requirements,implementation strategies, andpotential risks


Software Architectures Architectural taxonomy (“boxology”) Architectural patterns & idioms Design patterns & idioms Reuse

Class libraries Components Frameworks Middleware

Requirements

DetailedDesign

High-levelDesign




Framework Architecture

Class Library Architecture

ADTs

Strings

LocksIPC

MathLOCAL

INVOCATIONS APPLICATION-SPECIFIC

FUNCTIONALITY

GLUECODE

Files

GUIEVENTLOOP

Frameworks & Class LibrariesA framework is an integrated set ofabstract classes that can becustomized for instances of a familyof applications

A class is a unit of abstraction &implementation in an OOprogramming language

A component is an encapsulationunit with one or more interfaces thatprovide clients with access to itsservices

Adapted from Douglas C. Schmidt, “Patterns, Frameworks, &Middleware: Their Synergistic Relationships”

Middleware Bus

Component Architecture

Naming

LockingLogging

Events


Comparison

Class Libraries FrameworksMacro-levelMeso-levelMicro-level

Borrow caller’s threadInversion of controlBorrow caller’s thread

Domain-specific or Domain-independent

Domain-specificDomain-independent

Stand-alone compositionentities

“Semi-complete”applications

Stand-alone languageentities

Components




HistoricallyArchitecture was largely ad hoc affair

Designers freely use informal patterns/idioms informal with imprecise semanticsdiagrams + prose, but no rules

Designers use system-level abstractionoverall organization (styles)components and interactions

Designers compose systems from subsystemsbut, tend to think staticallyselect structure by default, rather than by design

Key eventsParnas recognized the importance of system families andarchitectural decomposition principles based on informationhidingDijkstra proposed certain system structuring principles


ControlProcess

(CP)

Prop LossModel

(MODP)

ReverbModel

(MODR)

NoiseModel

(MODN)

Architecture was largely ad hoc

is this an architecture?




ControlProcess

(CP)

PropLoss

Model(MODP)

ReverbModel

(MODR)

NoiseModel

(MODN)

Examplewhat is the nature of the components,and what is the significance of theirseparation?


ControlProcess

(CP)

Prop LossModel

(MODP)

ReverbModel

(MODR)

NoiseModel

(MODN)

Examplewhat is the significance of the links?

what is the significance of the layout?




Abstraction techniques in CSProgramming Languages

machine languagesymbolic assemblersmacro processorsearly high-level languagesFortran

data types served primarily as cues for selectingthe proper machine instructions

Algol and it successorsdata types serve to state the programmer’sintentions about how data should be used.

later high-level languagesseparation of a module’s specificationfrom its implementation

introduction of abstract data types.

increasingabstraction


Abstraction techniques in CSADT

the software structure (which included a representationpackaged with its primitive operators)specifications (mathematically expressed as abstractmodels or algebraic axioms)language issues (modules, scope, user-defined types)integrity of the result (invariants of data structures andprotection from other manipulation)rules for combining types (declarations)information hiding (protection of properties not explicitlyincluded in specifications)




two trendsrecognition of a shared repertoire of methods,techniques, patterns and idioms for structuring complexsoftware systems

concern with exploiting commonalities in specificdomains to provide reusable frameworks for productfamilies


two trends recognition of a shared repertoire of methods, techniques, patterns

and idioms for structuring complex software systems“Camelot is based on the client-server model and uses remoteprocedure calls both locally and remotely to provide communicationamong applications and servers.”

“Abstraction layering and system decomposition provide theappearance of system uniformity to clients, yet allow Helix toaccommodate a diversity of autonomous devices. The architectureencourages a client-server model for the structuring ofapplications.”

“We have chosen a distributed, object-oriented approach tomanaging information.”

“The easiest way to make the canonical sequential compiler into aconcurrent compiler is to pipeline the execution of the compilerphases over a number of processors. . . . A more effective way [is to]split the source code into many segments, which are concurrentlyprocessed through the various phases of compilation [by multiplecompilerprocesses] before a final, merging pass recombines theobject code into a single program.”




two trendsconcern with exploiting commonalities in specificdomains to provide reusable frameworks for productfamilies; examples include: the standard decomposition of a compiler standardized communication protocols, e.g., OpenSystems Interconnection Reference Model (a layerednetwork architecture) tools, e.g., NIST/ECMA Reference Model (a genericsoftware engineering environment architecture basedon layered communication substrates) fourth-generation languages user interface toolkits and frameworks, e.g., X WindowSystem (a distributed windowed user interfacearchitecture based on event triggering and callbacks)


Why Important?mutual communication.

software architecture represents a common high-levelabstraction of the system that most, if not all, of thesystem’s stakeholders can use as a basis for creatingmutual understanding, forming consensus, andcommunicating with each other.

transferable abstraction of a system. software architecture embodies a relatively small,intellectually graspable model for how the system isstructured and how its components work together; thismodel is transferable across systems; in particular, itcan be applied to other systems exhibiting similarrequirements, and can promote large scale reuse.




Why Important?early design decisions

software architecture represents the embodiment of theearliest set of design decisions about a system, and theseearly bindings carry weight far out of proportion to theirindividual gravity with respect to the system’s remainingdevelopment, its service in deployment, and its maintenancelife.

architectureprovides builders with constraints on implementationdictates organizational structure for development andmaintenance projectspermits or precludes the achievement of a system’s targetedquality attributesHelps in predicting certain qualities about a systemarchitecture can be the basis for traininghelps in reasoning about and managing change


elements, form, rationale, viewsarchitecture=elements

processingdataconnectors

formrules which constrainelement placement

style/design rationale

selection of form links to reqmnts & design functional/non-functionalattributes

lexer parser semanticanalyzer

codegenerator

optimizer

chars tokens phrasescorrelatedphrases

correlatedphrases

annotatedcorrelatedphrases

lexer parsersemanticanalyzer

codegenerator

optimizer

hastokens

hasphrases

hascorrelatedphrases

hasannotatedcorrelatedphrases

codegenerator

Process View

Data View




architectural styles/idiomsarchitectural style =

Components: locus of computationfilters, databases, objects, clients, servers, ADTs

Connectors: mediate interactions of componentsprocedure call, pipes, event broadcast

Properties: specify info for construction & analysisSignatures, pre/post conditions, RT specifications

othertopologyunderlying structural model?underlying computational model?


Expected Benefits

© David Garlan CMU

update document

6%

test & debug

28%

define/analyze change

18%

trace logic

23%

implement change

19%

review document

6%

Requirements

Architecture

Design

CodeIntegration

TestAccept

Maintenance

• Clarify intentions•Make decisions and

implications explicit• Permit system level

analysis

• Reduce maintenancecosts, directly andindirectly




independentcomponents

communicatingprocesses event systems

implicitinvocation

explicitinvocation

dataflow

batchsequential

pipes & filters

virtual machine

rule-basedsystem

interpreter

data-centered

repository blackboard

call/return

main prog.& subroutine

object-orientedlayered

taxonomy


“Boxology”

Control issuesTopology

geometric form of the control flow for the system:linear (non-branching), acyclic, hierarchical, star,arbitrary

Synchronicity Interdependency of the component control states:

lockstep (sequential or parallel), synchronous,asynchronous, opportunistic

Binding time time the identity of a partner in a transfer-of-control

operation is established: write (i.e., source code)time, compile time, invocation time, run time

Data issuesTopology

geometric shape of the system’s data flow graph:linear (non-branching), acyclic, hierarchical, star,arbitrary

Continuity the flow of data throughout the system: continuous,

sporadic, high-volume (in data-intensive systems),low-volume (in compute-intensive systems)

Data issuesMode

data is made available throughout thesystem: passed (object style from componentto component), shared: copyout-copy-in,broadcast, multicast

Binding time time identity of a partner in a data operation is

established: write (i.e., source code

Control/data interaction issuesShape

control flow and data flow topologiesisomorphic

Directionality If shapes the same, does control flow in the

same direction as data or the oppositedirection.

Type of reasoning nondeterministic state machine

theory, function composition software substructure and analysis

substructure should be compatible.

• Components and connectors• primary building blocks of architectures• abstractions used by designers in defining their architectures• most of these elements are ultimately implemented in terms of processes (as defined by the

operating system) and procedure calls (as defined by the programming language).




validate sort update report tape tapetapetape

data transformation

data flow

computation

sed grep awk

stdin stdout

data flow (ascii stream)

taxonomy:data flow

batch sequentialindependent programs,dataflow in large chunks, noparallelism

pipes & filtersincremental, byte streamdata flow, pipelined“parallelism”, local context,no state persistence

dataflow

batchsequential

pipes & filters


Boxology: dataflow




*to some extent batch

Analysis: pipes & filters*problem decomposition

advantages: hierarchical decomposition of systemfunctiondisadvantages: “batch mentality,” interactive apps?,design

maintenance & reuseadvantages: extensibility, reuse, “black box” approachdisadvantages: lowest common denominator for dataflow

performanceadvantages: pipelined concurrencydisadvantages: parsing/un-parsing, queues, deadlockwith limited buffers


Rules of thumb for dataflow/pipes If your problem can be decomposed into sequential stages,

consider batch sequential or pipeline architecturesIf in addition each stage is incremental, so that later stagescan begin before earlier stages complete, then consider apipelined architecture

If your problem involves transformations on continuousstreams of data (or on very long streams) consider a pipelinearchitectureHowever, if your problem involves passing rich datarepresentation, then avoid pipeline architectures restricted toASCII

If your system involves controlling action, is embedded in aphysical system, and is subject to unpredictable externalperturbation so that preset algorithms go awry, consider aclosed loop architecture




main

sub sub sub

sub sub sub sub sub sub

sub sub sub

obj

obj

obj

obj obj

taxonomy: call/returnmain/sub

hierarchicaldecomposition, singlethread of control,structure implicit,correctness depends onsubordinates

layeredhides lowerlayers/services higherlayer, upper=“virtualmachines”/lower =hw,kernel, scoping

object-orientedencapsulation,inheritance,polymorphism

call/return

main prog.& subroutine

object-orientedlayered

basic utilityuseful system

user interface

core


Analysis: call/return layers

portability, modifiability, reuseadvantages: each layer is abstract machine, each layer interacts

with ≤ 2 other layers, standard interfacesperformance, design

disadvantages: semantic feedback in UI, deep functionality,abstractions difficult, bridging layers

object-orientedportability, modifiability, reuse

advantages: decreased coupling, frameworks -> reusedisadvantages: complex structure

performance, designadvantages: maps easily to “real world”, inheritance, encapsulationdisadvantages: design harder, side effects, identity, inheitance

difficult




app module

shared d b

app module

app module

app module

app module

app module

knowledgesource

blackboard

knowledgesource

knowledgesource

knowledgesource

knowledgesource

knowledgesource

data-centered

repository blackboard

Taxonomy: data-centered

transactional dblarge central data store, control viatransactions

blackboardscentral shared + app-specific datarepresentations, control via data state


Rules of thumb: objects and repositories

If a central issue is understanding the data of theapplication, its management, and its representation,consider a repository or ADT architecture; if the data islong-lived focus on repositories

If the representation of data is likely to change over thelifetime of the program, ADTs or objects can confinethe changes to particular components

If you are considering repositories and the input data is“noisy” and the execution order can not bepredetermined, consider a blackboard

If you are considering repositories and the executionorder is determined by a stream of incoming requestsand the data is highly structured, consider a DB system.




Taxonomy:independent components

communicating processesindependent processes, point-point message passing,asynch/synch, RPC layered ontop

event systemsinterface define allowable in/outevents, event-procedurebindings: procedure“registration”, communiation byevent “announcement”, implicitaction invocation on event, non-deterministic ordering

manager

proc

proc

proc

proc proc

independentcomponents

communicatingprocesses event systems

implicitinvocation

explicitinvocation


Boxology: independent components




analysisevent systemsportability, modifiability, reuse

advantages: no “hardwired names”, new objects addedby registrationdisadvantages: nameserver/”yellowpages” needed

performance, designadvantages: computation & coordination are separateobjects/more independent, parallel invocationsdisadvantages: no control over order of invocation,correctness, performance penalty from communicationoverhead


Rules of thumbIf your task requires a high degree of flexibility-configurability, loose coupling between tasks, andreactive tasks, consider interacting processesIf you have reason not to bind the recipients of signalsto their originators, consider an event architectureIf the task are of a hierarchical nature, consider areplicated worker or heartbeat styleIf the tasks are divided between producers andconsumers, consider a client-server style (naïve orsophisticated)If it makes sense for all of the tasks to communicatewith each other in a fully connected graph, consider atoken-passing style




data(program state) program

internalstate

interpretationengine

inputs

outputs

statedata

programinstructionsupdatesdata

selected instr,

selected data

workingmemory

factmemory

rule/dataselection

interpretationengine

inputs

outputs

triggeringdata

rules/factsupdatesdata

selected rules

selected data

rulememory

virtual machine

rule-basedsystem

interpreter

taxonomy: virtual machines

interpreterssimulate functionality which isnot native to the run-timesystem; execution engine“implemented” in software

rule-based systemsspecialization of an interpreter


Analysis: virtual machinesinterpretersportability, modifiability, reuse

disadvantages: map into actual implementation?performance, design

advantages: simulate non-native functionality, cansimulate “disaster” modes for safety analysisdisadvantages: much slower than actual system,additional layer of software to be verified

Rules of thumb: virtual machinesIf you have designed a computation, but have nomachine on which you can execute it, consider a virtualinterpreter architecture.

12 Design Software Architecture - www … · 12 Design ⇒ Software Architecture Introduction to...

Documents

Transcript of 12 Design Software Architecture - www … · 12 Design ⇒ Software Architecture Introduction to...