ICS 123 Software Architecture ICS 123 Spring 2002 Richard N. Taylor and Eric M. Dashofy* UC Irvine * with very

ICS 123

Software Architecture

ICS 123 Spring 2002Richard N. Taylor and Eric M.

Dashofy*UC Irvine

http://www.isr.uci.edu/classes/ics123s02/

* with very special thanks to David S. Rosenblum for the use of his materials.

ICS 123

2

Topic 2SoftwareArchitecture

Software Architecture(Perry & Wolf 92)

“Architecture is concerned with the selection of architectural elements, their interactions, and the constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.”

(vs. design…)“Design is concerned with the modularization

and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.”

ICS 123

3


Software Architecture(Garlan & Shaw 93)

“Software architecture is a level of design that goes beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.”

ICS 123

4


Software Architecture(Shaw & Garlan 96)

“The architecture of a software system defines that system in terms of computational components and interactions among those components. … In addition to specifying the structure and topology of the system, the architecture shows the correspondence between the requirements and elements of the constructed system, thereby providing some rationale for the design decisions.”

ICS 123

5


Analogies withCivil Architecture

•Architecture vs. Construction

•Multiple views– Civil: Artist renderings, elevations, floor plans, blueprints– Software: Code, object design, boxes-and-arrows, GUI

•Architectural styles– Civil: Classical, Romanesque, Gothic, Renaissance, Baroque, Art Deco– Software: Pipe-and-filter, client/server, layered system

• Influence of style on engineering principle

• Influence of style on choice of materials

Civil Engineering and Civil Architectureare concerned with the engineering and

design ofcivic structures (roads, buildings, bridges,

etc.)

ICS 123

6


Differences Between Civil and Software Architecture

•Physical vs. conceptual

•Static vs. dynamic

•Little evolution vs. frequent evolution

•Different mathematical and scientific bases

•Different notions of “reuse”

ICS 123

7


Elements of Software Architecture

• Perry & Wolf– Structural Elements

» Processing» Data» Connecting (“glue”)

– Form: Weighted Properties and Relationships

– Rationale

• Shaw & Garlan:– Components– Interconnections– Rules of Composition– Rules of Behavior

• Components

• Connectors

• Interfaces

• Configurations

• (implies) Links

This Class

ICS 123

8


Components

•A component is a building block that is …– A unit of computation or a data store, with an interface

specifying the services it provides– A unit of deployment– A unit of reuse

ICS 123

9


The Difference Between Components and Objects

• Lifecycle – Objects are created and destroyed constantly– Components are created and destroyed infrequently

• Purpose of use– Graphics toolkit (component) vs. graphics widget (object)– Data store (component) vs. data structure (object)

• Type system– Objects are instances of a class, with classes arranged in hierarchies

according to inheritance relationships– Components may have their own type system (may be trivial), often

very few components of the same type

• Size– Objects tend to be small– Components can be small (one object) or large (a library of objects or

a complete application)

ICS 123

10


Connectors

•A connector is a building block that enables interaction among components

– Shared variables– Procedure calls (local or remote)– Messages and message buses– Events– Pipes– Client/server middleware

•Connectors may be implicit or explicit– Implicit: procedure calls– Explicit: First-class message buses

ICS 123

11


The Difference Between Components and Connectors

•Task Performed– Components focus on computational tasks– Connectors focus on communication tasks

•Application Semantics– Components generally implement most of the application

semantics– Connectors do not (they may change the form of the message,

but do not generally change its meaning)

•“Awareness”– Components (should be) unaware of who is using them and for

what purpose– Connectors are more aware of components connected to them

so they can better facilitate communication

Not everybody agrees on this!

ICS 123

12


Interfaces

•An interface is the external “connection point” on a component or connector that describes how other components/connectors interact with it

•Provided and required interfaces are important

•Spectrum of interface specification– Loosely specified (events go in, events go out)– API style (list of functions)– Very highly specified (event protocols across the interface in CSP)

• Interfaces are the key to component interoperability (or lack thereof)

ICS 123

13


Configurations

•A configuration is …– The overall structure of a software architecture– The topological arrangement of components and connectors

» Implies the existence of links among components/connectors

– A framework for checking for compatibility between interfaces, communication protocols, semantics, …

•“If links had semantics, they’d be connectors.”

•Usually constructed according to an architectural style

ICS 123

14


Graphically…

Clock Component

Interfaces

Bus1

Connector

Interfaces

ICS 123

15


Graphically (cont).

Clock

Bus1

LCDDriver

Links

Configuration

ICS 123

16


Example:Architectures for a Compiler

Scanner ParserSemanticAnalyzer

CodeGenerator

File File File

Parse Tree

Scanner ParserSemanticAnalyzer

CodeGenerator

Component ConnectorLegend:

ICS 123

17


What does architecture buy you?

•On its face, nothing!

•A bad architecture can imply a spaghetti code system

– See “Big Ball of Mud,”http://www.devcentre.org/mud/mudmain.htm

•How can we use architecture to improve the qualities (-ilities) of our software systems?

•Answer: Architectural Styles

ICS 123

18


Architectural Styles

•An architectural style is …– A set of constraints you put on your development to elicit

desirable properties from your software architecture.– These constraints may be:

» Topological» Behavioral» Communication-oriented» etc. etc.

– Working within an architectural style makes development harder

– BUT architectural styles help you get beneficial system properties that would be really hard to get otherwise

ICS 123

19


The Classical Style of Civil Architecture

The PantheonRome, Italy

ICS 123

20


The Gothic Style

Nôtre-Dame CathedralParis, France

ICS 123

21


The Mediterranean Style

Irvine, California

ICS 123

22


Common Software Architectural Styles (Shaw & Garlan 96)

•Dataflow Systems– Batch sequential– Pipes and filters

•Call-and-Return Systems– Main program and subroutines– Object-oriented systems– Hierarchical layers (onion layers)

• Independent Components– Communicating processes (client/server and peer-to-peer)– Event systems– Implicit invocation

ICS 123

23


Common Software Architectural Styles (Cont.)

•Virtual Machines– Interpreters– Rule-based systems

•Data-Centered Systems (Repositories)– Databases– Hypertext systems– Blackboards

ICS 123

24


Pipe and Filter Example

•You, too, are a software architect!

• ls –l *.java | grep “foobar” | lpr –P gaston

– Components: Filters– Connectors: Stream-based pipes– Interfaces: One in, one out on each pipe or filter, exchange

byte streams– Links: Implicit in above command line– Configuration: Specified by ordering on the command line

ICS 123

25


Pipe & Filter Constraints

•All communication via byte streams

•One “in,” one “out” interface on each component

•Only connectors are pipes

•A pipe is mandatory between each pair of sequential filters

•Filters must be ordered sequentially, starting and ending with a filter

•What software qualities are brought out by this style?

ICS 123

26


Pipe & Filter Qualities

• Configurability: Any set of filters may be combined in any order

– Although reasonable semantics are not guaranteed by this style

• Efficiency: All data does not have to be processed for the next filter to start working

• Customizability: Filters can be easily inserted, removed into the software architecture

• Domain-specific: Works very well for text-processing problems.

ICS 123

27


The Vision: Architecture-Based Composition & Reuse

•A framework for design and implementation of large-scale software systems

•A basis for early analysis of software system properties

•A framework for selection and composition of reusable off-the-shelf components

•A basis for controlled evolution of software

•A basis for runtime evolution of software

ICS 123

28


The Reality:Architectural Mismatch

•Architectural mismatch refers to a mismatch between assumptions made by different components about the structure of the system and the nature of the environment in which they operate

•Assumptions about the nature of the components

– substrate on which a component is built– control model– data model

•Assumptions about the nature of the connectors– protocols– data model

ICS 123

29


Architectural Mismatch (Cont.)

•Assumptions about the global configuration– topology– presence of certain components or connectors– absence of certain components or connectors

•Assumptions about the system construction process

– order in which elements are instantiated– order in which elements are combined

•Assumptions about the operating environment

– Threading concerns– Availability or characteristics of lower-level functionality (OS-

level, network)

ICS 123

30


Standards: The Solution?

•Standards define a set of “assumptions” that all components must adhere to

– Component interface standards (e.g., JavaBeans, ActiveX, Netscape Plug-in API)

– Component interoperability standards (e.g., CORBA, DCOM, Java RMI)

– Standard component frameworks (e.g., Microsoft Foundation Classes)

•But standards also reduce design flexibility

ICS 123

31


More Reality: “Architectural Drift”

•How are architectures implemented now?

Brilliant SoftwareArchitecture

Semi-Cohesive Object Design in UML

Python 1.5.2 (#1, Apr 18 1999, 16:03:16) Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import asynchat # create an instance >>> channel = asynchat.async_chat() # access to attributes from an instance >>> channel.ac_in_buffer '' >>> channel.ac_in_buffer_size 4096 # now let's look at the name spaces >>> channel.__dict__['ac_in_buffer'] '' >>> channel.__dict__['ac_in_buffer_size'] Traceback (innermost last): File "<pyshell#11>", line 1, in ? channel.__dict__['ac_in_buffer_size'] KeyError: ac_in_buffer_size # not found in the instance's namespace! # check the class namespace >>> asynchat.async_chat.ac_in_buffer_size 4096

IncomprehensiblePython Code

ICS 123

32


Why does drift happen?

•Eventually, software must become code– Programming languages and operating systems provide poor

support for entities at the architecture level of abstraction

• Induces “architectural drift” (Garlan & Allen)– As the system gets built and (especially) maintained, the

system drifts further away from its original intended design/architecture

– Increases software costs and failures dramatically

ICS 123

33


Solutions for Drift

•Maintain a persistent view of architecture at implementation time

•Co-evolve requirements and architecture

•Use architecture as the basis for:– System Design– Maintenance– System evolution– Deployment

•Much of this is still “research!”

ICS 123

Architecture Tools and“Real” Technologies

ICS 123Richard N. Taylor and Eric M. Dashofy

UC Irvinehttp://www.isr.uci.edu/classes/

ics123s02/

ICS 123

35


Overview

•Architecture-centric Development Environments

– ArchStudio

•Architecture Description Languages– xADL 2.0

•Architecture Frameworks– c2.fw and others

ICS 123

36


The Vision

•Architecture-driven Software Development– Architecture as the primary abstraction for design– The architecture is defined very early in the development

cycle (possibly in parallel with the requirements)– The architecture persists into the implementation and

maintenance phases of development

•Gap analysis: how do we get there from here?– Ways to represent, manipulate, and visualize architectures– Tool support for designing, implementing and evolving

architectures– Development of Architecture-centric Development

Environments» Think “Visual Studio” but for architectures, rather than

codeCan you name some tools that would go in a

{code-based/architecture-based} environment?

ICS 123

37


Contrast: IDE vs. Architecture-based DE

Code-based IDE Tools:

•Text editor

•GUI Builder

•Compiler

•Debugger

•Static Analysis Tools

•Project Management

•Source file configuration management

Architecture-based Tools:

•Visual Editor

•Composition assistants

•Code generator

•Instantiation & Evolution Management

•Various analysis tools

•Style-specific constraint management

•Component-based configuration management

ICS 123

38


ArchStudio

•ArchStudio is an extensible architecture-centric development environment

– Tools within the environment have special support for the C2 architectural style

– The environment itself is built in the C2 style

•ArchStudio Tools (integrated in various versions):

– Editors (visual, syntax-directed, and command-line)– Analysis tools (static & dynamic analysis, design critics)– Off-the-shelf integrations

» Code-based IDEs (Eclipse, Metamata, etc.)» OOAD tools (Rational Rose)» Hypermedia systems (Browsers, Chimera)

– And more…

ICS 123

39

Topic 2SoftwareArchitectureArchStudio 3 Today

Holds architecture descriptions

Critics watch architecture for problems

Architecture-to-implementation mappings

Manages open issues

Manages design critics

GUIs for various high-level tools

Graphical and syntax-directed editors

Manages open files and tools

ICS 123

40


Architecture Description Languages

•How do we “write down” a software architecture?

•An architecture description language (or architecture definition language, or ADL) is a formal notation for describing the structure and behavior of a software architecture

•ADLs provide– a concrete syntax– a formal semantics– a conceptual framework– for explicitly modeling the conceptual architecture of a system

•Contrast with programming languages, which define the implementation of a system

ICS 123

41


What Goes in a Software Architecture Description?

•From Medvidovic and Taylor, 2000:– “An ADL must explicitly model components, connectors, and

their configurations; furthermore, to be truly usable and useful, it must provide tool support for architecture-based development and evolution. These four elements of an ADL are further broken down into constituent parts.”

– “In order to infer any kind of information about an architecture, at a minimum, interfaces of constituent components must also be modeled. Without this information, an architectural description becomes but a collection of (interconnected) identifiers, similar to a “boxes and lines” diagram with no explicit underlying semantics.”

What else would you model about a software system you were designing?

ICS 123

42


What people have put in their descriptions

Events

Dynamic Systems

Configuration Management

Distributed Systems Behaviora

l Properties

Implementation Mappings

Mobile, Dynamic

Architectures

ProductFamilies

ICS 123

43


What really goes in an ADL?

•“There is, however, still little consensus in the research community on what an ADL is, what aspects of an architecture should be modeled by an ADL…”

•This can be a good thing!– Model only what you will find useful.– Model things that your tools can work with or analyze.– Model critical aspects of your software system in more detail.

•This can be a bad thing!– Limits on architectural interchange.– Limits applicability of tools on divergent notations.

Do you think this occurs in the programming language domain?

ICS 123

44


Problem and (Potential) Solution

•Problem: How can we exploit commonalities and experiment with different features in an ADL without duplicating effort?

•Solution: An extensible ADL– Start with a core of “common” features

» Components, Connectors, Interfaces, Links (configurations)– Extend that core by adding features as necessary

•Benefits– Shared features may imply shared tools– “Pick and choose” features that model aspects you care about– Reuse other people’s modeling constructs and the effort

therein

ICS 123

45


xADL 2.0: An Extensible ADL

•xADL 2.0 is an example of an extensible ADL•Has a core set of features (called xArch) that

model the usual core ADL features:– Components, Connectors, Interfaces, Links– BUT! These are “semantically neutral”—nothing is said about

what these things are/do.

•Has several extensions that you can choose and incorporate into your modeling efforts if you want.

– Design-time/Run-time separation– Type system for components, connectors, interfaces– Implementation Mappings– Variants, Options, and Versions (Product Families and

Architecture CM)– More on the way!

ICS 123

46


How does extensibility work in xADL 2.0?

•xADL 2.0 is built as an XML-based language

•Uses extensibility constructs from XML schemas (more on this later in the quarter)

•Simplified explanation :Architecture{ comp*:Component; conn*:Connector; link*:Link;}

Component{ id:String; if:Interface*}

Interface{ id:String}

ComponentWithVersion extends Component{ add{ versionID: String; } remove{ }}

ArchitectureWithVersions extends Architecture{ add{ vtree*:VersionTree } …}

ICS 123

47


Design-Time vs. Run-Time

Comp2

Comp3

Comp1

Comp1_Beh{ If(recv(evt(q))){ doProcess(q) emit(evt(b)); }}

Behavior informationfor static analysis

CompInst 2

CompInst 3

CompInst 1

aba - -

Event queue contents

Machine = magisterPid = 242CPU = 1Port = 8080…

Information aboutdistributed components

State= BLOCKED

Waiting on event “A”

Run-time State

Conn1

ConnInst 1

Constraints

Invariant a{ comp1.interface .type = top -> comp1.interface .link.type = bottom}

Design-oriented Properties

Author=AndréAuthor=DickLast Update: 08/18/2001

ICS 123

48



Adding information about implementations to component, connector, and interface types is essential if the architecture is to be instantiated.

Foo.class

Bar.jar

Baz.dll

.NETService

Comp2

Comp1

Comp3

Comp4

Conn1

Helps prevent architectural

drift!

ICS 123

49


Product Families & Architecture Evolution

Comp4

ComponentWith Variant Type

OptionalComponent & Link

1.0

1.1

2.0 1.1.1

3.0

1.1.2

Version Graphfor Type T

Comp1

Comp2

Comp3

Can you think of an example of where a lack of this sort of support has caused you

problems?

ICS 123

50


xADL 2.0 Feature Dependencies

Instances

Structure & Types

Versions Options Variants AbstractImplementation

JavaImplementation

ArchitectureDiffing

MessagingInterfaces

TypeRelationships

ICS 123

51


xADL 2.0 Tool Support

• xADL 2.0 is meant to be read & written by people and computers

– Contrast with a formal notation like Z (“Zed”)…– People need some way of creating, editing xADL 2.0 documents– Programs need some way of creating, editing xADL 2.0 documents

programmatically

• Several tools available– XML Tools off-the-shelf

» XML Spy, Tibco XML Authority, Apache Xerces, Xalan, etc.– xADL 2.0 Tools

» Apigen: Can generate Java objects for xADL 2.0 (and extensions!) constructs based entirely on the language definition

» Data Binding Library: Java objects for xADL 2.0 constructs, generated by Apigen

» ArchEdit: Syntax-directed Editor for xADL 2.0» Visio for xADL: Graphical box & arrow editor for xADL 2.0

documents

ICS 123

52


xADL 2.0 Tool Relationships

Apigen

xADL 2.0Schemas

DataBinding Library

generates

ApacheXerces

uses uses

xArchADT

changes theinterface to events

ArchEdit

Visio forxADL

uses

uses

ArchStudio Components

DesignCritics

use

ICS 123

53


Gratuitous Graphics: ArchEdit

ICS 123

54


Gratuitous Graphics: Visio

ICS 123

55


Gratuitous Graphics: Critics

ICS 123

56


Architecture Frameworks

•How do you implement a software architecture?

•Programming language constructs are often insufficient

Programming Language:

•Objects

•Procedure calls, callbacks

•Threads of control

•Design Patterns

Architecture:

•Components

•Connectors, Events

•Threading Policy

•Architectural Styles

Can you think of a concrete example fromyour favorite programming language?

ICS 123

57


Architecture Frameworks

•An architecture framework is software that assists developers in building implementations of a software architecture faithful to the target style by providing services and tools that are not available in the existing development environment.

•Frameworks can vary in:– Fidelity– Platform/Language– Any –ility– Size– Reliance on other software

Architecture-Based Application

OS/Filesystem/Network

Architecture Framework

Middleware (JMS, CORBA)

Programming LanguageEach layer may make use of

services provided by any layer below, although should

concentrate on upper layers.

ICS 123

58


C2 Frameworks

• Original C2 Frameworks (Java & C++, UCI)– Highly faithful to C2 concepts– Some dynamism support, support for various threading policies

• oC2 Framework (Java, USC)– Version of the Original C2 Java Framework optimized for performance

• eC2 Framework (Java, USC)– Built to be lightweight for embedded devices (Palms, iPAQ, etc.)– Used central message queues, limited number of threads, low

resource consumption (memory, etc.)

• c2.fw Framework (Java, UCI)– Highly flexible C2 framework– Supports pluggable message queuing, threading, topology managers– More message types allowed– Improved support for distribution, dynamism

ICS 123

59


A closer vision: architecture- based evolution and reuse

ADL Framework

Architecture Evolution Manager

Analysis Tools

Feedback and

Planning

Implementation Issues

ProcessSupportTools?

ICS 123

Other Architecture Approaches and Tools

ICS 123Richard N. Taylor and Eric M. Dashofy

UC Irvinehttp://www.isr.uci.edu/classes/

ics123s02/

ICS 123

61


Recall…

•Architecture Description Languages are ways of writing down software architectures.

•ADLs include, at minimum– Components– Connectors– Interfaces– Configurations ( links)

•Not everybody agrees on what else goes in an ADL

•xADL 2.0 is an attempt at an extensible ADL

ICS 123

62


A Quick Look at ADLs…

Events

Dynamic Systems

Configuration Management

Distributed Systems Behaviora

l Properties


Mobile, Dynamic

Architectures

ProductFamilies

xADL 1.0

Darwin

Mae

Koala

Wright

Rapide

Darwin,C2SADL ????

ICS 123

63


A Brief Look at Three Other Approaches

•Rapide (Stanford, D. Luckham)

•Darwin (Imperial College London, J. Kramer & J. Magee)

•ACME (Carnegie-Mellon, D. Garlan)

ICS 123

64


Rapide

•Key foci– Model behaviors of components, interactions– Events are the method of communication– Events organized in POSETs (Partially Ordered SETs)– Specified systems can be simulated by Rapide toolset– Simulations can be visualized in a graph format

ICS 123

65


POSETs

•Consider events that a person might emit at a gas station:

– Pull up– Leave– Use Credit Card Machine– Wash Windows– Pump Gas

Pull Up Leave

Wash

Credit Card Pump Gas

Credit Card

Wash

Pump Gas

Pump GasCredit Card

What are the orderings between these events?

ICS 123

66


A Rapide Interface

type Pump is interface

action in On(), Off(), Activate(Cost : Dollars);

out Report(Amount : Gallons;

Cost : Dollars);

behavior

Free : var Boolean := True;

Reading, Limit : var Dollars := 0;

action In_Use(), Done();

begin

(?X : Dollars)(On ~ Activate(?X)) where $Free => Free := False;

Limit := ?X;

In_Use;;

In_Use => Reading := $Limit; Done;;

Off or Done => Free := True; Report($Reading);;

-- constraint

end Pump;

“disjoint AND”

ICS 123

67


A Rapide Configuration

architecture gas_station1() return root

is

O : Operator;

P : Pump;

C1, C2 : Customer;

connect

(?C : Customer; ?X : Dollars) ?C.Pre_Pay(?X) => O.Request(?X);

(?X : Dollars) O.Schedule(?X) => P.Activate(?X);

(?X : Dollars) O.Schedule(?X) => C1.Okay; -- change this

(?C : Customer) ?C.Turn_On => P.On;

(?C : Customer) ?C.Turn_Off => P.Off;

(?X : Gallons; ?Y : Dollars)P.Report(?X, ?Y) => O.Result(?Y);

end gas_station1;

ICS 123

68


The Result

Can you identify apotential problemrevealed by this

event trace?

ICS 123

69


The Result

Could this be a problem?

Ability to specify Constraints (patterns that should or should not happen) are important in finding these issues.

ICS 123

70


Darwin

•Key foci– Model distributed systems– Model dynamic systems

ICS 123

71


Darwin Examplecomponent filter{

provide output<stream char>;

require input<stream char>;

};

component pipeline(int n){

provide output;

require input;

array F[n]: filter;

forall k:0..n-1{

inst F[k] @ k+1;

when k < n-1;

bind F[k+1].input -- F[k].output;

}

bind

F[0].input -- input;

output -- F[n-1].output;

}

}

ICS 123

72


Darwin: Specifying Change

MERGE::

unlink pa[1] from pa[(1 mod N))+1], pa[(1 mod N))+1] from pa[1],

pb[1] from pb[(1 mod M))+1], pb[(1 mod M))+1] from pb[1];

link pa[1] to pb[1], pb[1] to pa[1];

pa[(1 mod N))+1] to pb[ (1 mod M))+1],

pb[ (1 mod M))+1] to pa[(1 mod N))+1];

Adding a node to a ring of components (dining philosophers, in this case)

ICS 123

73


Darwin: Tools

ICS 123

74


ACME

•Key Foci:– Genericity (Usual Suspects + Name-Value Properties)– Function as an “architecture interchange language”

•Later Developments– Constraints on elements– Constraint based type system

ICS 123

75


ACME Example*

Component Type ClientT = { Port sendReq; … };Component Type ServerT = { Port receiveReq; … };Connector Type RPCT = { Roles {caller; callee}; … };

System SimpleClientServer = {Component viewer : ClientT;Component database : ServerT;Connector conn : RPCT;Attachments = {

viewer.sendReq to conn.caller;viewer.receiveReq to conn.callee;

};};

viewer

database

*Slides From Bob Monroe’s ICSE’99 Tutorial

ICS 123

76


ACME Example (cont).

Component Type ServerT = { Port receiveReq : ODBCPortT = {

Property supportsODBCLevel : int = 2;Property supportsConcurrentTrans : boolean = true;

};Property maxConcurrentTrans : int = 20;Property averageTransProcessingLatency : float;Property ODBCComplianceLevel : int;

};

*Slides From Bob Monroe’s ICSE’99 Tutorial

Can you identify potential drawbacks to using this approach for architectural

interchange?

ICS 123

77


Summary

•No “one true approach”

•Flexibility, interchange, evolvability of ADLs is still unachieved

– But we’re getting there, and hopefully will be there soon!

Documents

ICS 123 Software Architecture ICS 123 Spring 2002 Richard N. Taylor and Eric M. Dashofy* UC Irvine * with very