5

Harald Störrle*

Ludwig-Maximilians-Universität Miinchenstoerr le@informatik. uni-muenchen. de

1 Introduction

1.1 Motivation

In recent years, the architecture level of systemshas been identified as a vital factor in the cre-ation and evolution ("maintenance" ) of systemsand the effective reuse of software artifacts. AsTom DeMarco poignantly put it: " Architecture

is a framework for change" .At the same time,the Unified Modeting Language (UML) has be-come the standard for expressing designs of soft-ware systems. Currently, however, there arevery few expressive means for the architecturelevel in the UML. This paper aims at providingjust this. We adopt accepted notations and em-bed it tightly into the conceptual framework ofthe UML. The concepts and notations presentedhere have been used in a practical project withstudents.

1.2 Issues in architectural model-

ing

There are several aspects to modeling the ar-chitecture of software systems. First, there isan obvious need for clear architectural concepts.Second, an appropriate syntax must be providedto represent them. It needs to be expressiveto cover a wide range of systems and architec-tural styles, yet has to be easy to understandand use. Third, the syntax needs to be under-pinned with a precise semantics, so that it ispossible to build tools to support working onthe architecture level. On the one hand, analy-sis tools from validation up to formal analysis ofan architecture are required. On the other hand,documentation and cataloging of components,and automated code generation is essential for

*Thanks ga ta Alexander Knapp far innumerable in-spiring discussians, and ta Bernd Gebhard af BMWandBran Selic af ObjecTime far many helpful suggestians.

effective reuse (see [8]). Fourth, the process ofdeveloping and evolving an architecture needsmethodological guidelines, as a phase in itselfand in relation to the overall software develop-ment process. Fifth, the quaIity of the concepts,syntax, semantics, and development guidelinesis determined by their practical usability, whichis to be assessed by case studies.

1.3 An integrative approach

Obviously, not all of the above issues can betreated exhaustively in this paper. So, we focuson the concepts and syntax. This is a long shotfrom a true method, or a proper and reasonablysized case-study, however. Also, we omit thesemantics completely (see the companion tech-nical report [18] on this issue).

The approach taken here tries to integrateseveral strands of current work. First, there aresome academic approaches: Architecture De-scription Languages (ADLs) such as WRlGHT[1] feature interesting architectural concepts,hut lack convincing graphical representations asweIl as methodological guidelines. Second, thereare commercial approaches such as the ROOMmethod [15] with a track record of success-ful practical applications, but without semanti-cal underpinnings and sufficiently clear and ad-vanced concepts. Third, there is the UML [11],subject to enormous interest both commerciallyand academically, offering a wealth of notionsand notations, and emerging methodologies hutlacking adequate concepts and syntax for thearchitecture level.

Our approach is to take accepted concepts,enhance them, and embed them in the UMLconceptual framework, so as to make all otherUML related work more easily accessible.

1.4 Organization of this paper

Basic concepts for architectural modeling are in-troduced (Section 2), and a novel notion of com-ponent is explained (Section 3). The conceptswe have presented are then embedded in the ter-minological framework of the UML (Section 4).As a concrete syntax for modeling, we intro-duce architectural diagrams, and functionality,realization and implementation views on them(Section 5). First practical experiences with thenotions and notations are reported (Section 6).The paper concludes with a summary of the gen-uine contributions and a discussion of similarapproaches (Section 8).

2 Concepts for architectural

modeling

The three main concepts are architectural com-ponent, architectural interface and architecturaladapter (or just: component, interface andadapter, respectively). A component is an amal-gamation of different facettes, that hold infor-mation for the activities involving the compo-nent (such as retrieval from a store, composi-tion and analysis). As one of its facettes, acomponent holds a set of interfaces, which pro-vide a strong encapsulation of the component.Components may be accessed only via their in-terfaces. Connections between components areestablished by defining adapters between theirinterfaces. An ensemble of components andadapters is called a configuration.

2.1 Components, facettes, views

Currently, there is no clearly defined, gener-ally agreed upon notion of component. In oureyes, the characteristic property of a compo-nent is self-containedness: a component shouldbe self-contained with respect to all activitiesit might be involved in. This spans all phasesof a component's lifecycle. Thus, the activi-ties to be considered include the usual access ofa component's functionality in operational use(i.e. any interactions it is involved in), but alsoe.g. retrieving it from some catalog of off-the-shelf components, and all other software engi-neering activities relevant for component-basedsoftware development (CBSD, see [3] for a briefmotiation). Hence, a component is not only a

?

programming-level entityl, but also an analy-

sis and design entity, and consequently needs tohold all information necessary in these phases,too. Note that this is in accordance with thedemand for components as elementary units offunctionality relevant to the application domain.The notion of encapsulation and its implicationsare discussed in greater detail in Section 3. Thecontents of components is organized in a set of

containers called facettes (see [13]), that can beaggregated to views. While facettes are a se-mantic concept, views are a syntactic abstrac-tion, introduced to support specific usages.

2.2 Interfaces

An important contribution to the self-containment of components is made by itsinterfaces. Any interactions a componentengages in are carried out exclusively via itsinterfaces. Interfaces can be distinguished bythe kind of connection they allow. On the onehand, there are connections between peers,as pointcast or multicast connections. Onthe other hand, connections can be used forbroadcast-type connections. Therefore, wedistinguish between ports for the former type ofconnections, where all communication partners

are known, and service access points (SA Ps),for the latter, where communication partnersmay be anonymous.

2.3 Adapters

Adapters connect interfaces in a completely pas-sive way. Theyare assumed to be of per-fect qualit y (i.e. exhibit no faulty behavior).Adapters specify the sets of signals they maytransmit, as weil as the behavior of the inter-

faces that are connected by adapters. Adaptersconnect at least t wo interfaces.

2.4 Configurations

An architectural configuration is an abstractrepresentation of a system 's structure. It con-sists of a set of architectural components, thatare loosely coupled by adapters. Different stylesof configurations can be achieved. Apart from

1 Of course, a component should also not only hide itsimplementation, but indeed its implementation technol-ogy, i.e. components implemented in non-object-orientedlanguages are perfectly acceptable. Relying on any spe-cific oo-concepts (such as inheritance as specialization)is a breech of the secrecy principle.

arbitrary networks, layered systerns are also fre-quently encountered.

3.1 Requirements

The most important feature of an architecturalcomponent is self-containment. This means,that an architectural component is a unit, thatprovides a strong and rich encapsulation, lead-ing to three major requirements.

As for strength, access to a component mustbe limited to specific interfaces. As a first re-quirement, architectural interfaces must specifynot just a signature, but also a behavior. It canbe seen as a specification of guaranteed behaviorof some interface. So, changes to the internalfeatures of a component that affect its behav-ior can be localized before they invalidate anyusage-relationships the component is already in-volved in. Self-containedness, in other words,is essential for the compositionality of compo-nents.

As a second requirement, the interface mustexert access control in both directions, i.e. itis not enough to restrict access to a compo-nent, but also, the access from a componentmust be controlled. In order to achievetrueself-containedness, this control must be realizedwithin the accessing component, and not indi-rectly by users of a component.

For the third requirement, the richness ofthe encapsulation comes into view. Self-containedness of components should apply toall software engineering activities the compo-nent is involved in, throughout all of its life-cycleand throughout all of a system development life-cycle. Obviously, the creation of an architec-ture occurs early in system development, andso this includes the analysis-phase representa-tion of a component as weIl as (versions of) itsimplementation to any information needed formaintenance and reuse. At least the followingactivities must be supported by a component:

.RetrievaI: For a specific site in an ar-chitecture of some project, suitable com-ponents must be retrieved from (large)databases of off-the-shelf components. Thisrequires specifying a profile of the candidatecomponent

.Match QuaIity Assessment: Once re-

3 Architectural components

1

~

~~r

)

~

l

r

~

3

trieved, it is necessary to assess how wella component matches the specific site un-der consideration. While retrieving compo-nents with a given profile ensures certaincoarse matching criteria (e.g. right hard-ware, right keywords wrt. functionalityandSO on), the matching of interfaces has tobe investigated with greater scrutiny (andgreater computational effort).

.Tailoring: Typically, the selection wilyield a non-perfect match, its qualit y beinlrevealed by the previous assessment. Supposing that the selected component is to b~used anyway, it needs to be adapted. Thenare basically three complementary types oadaptations to be considered. First, components may have switches and parameterithat could be used for customization. Sec.ond, there are simple adaptations like alias.ing of signals, transposition and projec.tion of parameters, or simple pre. or post.processing that can be done by a wrapperThird, a component may need real modifi.cations, like a restructuring. This is besjaccomodated as a specialisation.

.Design Debugging: Next, the choice andadaptation of component has to be eval.uated. While a successful match qualit~assessment and tailoring ensure that inter-faces match locally, the global interplay ojcomponents needs to be assessed as well.For instance, often a load balancing analy-sis is required.

.Cataloging: Finally, components need tobe stored for retrieval, i.e. according tosome cataloging scheme. It is highly de.sirable, that there be automated catalogingprocedures.

To accomodate these activities, architecturalcomponents need to incorporate much more in-formation than is present in today's components(like JavaBeans, COM or CORBA components).Also, this information must be represented se-mantically, so that automated tools will be ableto make use of these informations. At the sametime, there must be abstractions of componentsto support the activities of human users. Theset wo requirements can be realised by structuringcomponents as a set of facettes, that store theinformation for the activities listed above, andaggregating them into views as needed.

3.2 Facettes

Facettes can be used as a means for classify-ing iterns, specifically those that are subject toreuse [13]). In the setting of CBSD, reuse is ofcourse the primeval purpose, so that it appearsto be a rather adequate name for the partitionsof cornponents.

.Functionality: The functionality facettecaptures the purpose(s) of a cornponent, itssystem boundaries, and the dependenciesto adjacent systerns.

.Interfaces: The interfaces facette containsa set of interfaces, i.e. contracts about thecornponent's behaviour. It corresponds toa port in the ROOM terminology. An In-terface consists of a signature (i.e. the setsof ingoing and outgoing singals ) and a be.haviour specification.

3.3 Viewse Realisation: A realisation facette could

be either a structural refinement or a Some simple examples of views and their appli-behaviour specification. This facette is cation are the following.very much like the capsules/connectors of e a functional view documents a system'sUML/RT, the actors/connectors of ROOM, boundaries and external functionality. Itor the component/connectors of WRlGHT. can be used for a top-Ievel architectural

.presentation of a system, as it is necessarye Platforms: ThIS facette .holds the re- for designing an architecture, but also for

~uirements of the .executlon platfor~, a classical functional decomposition in thel.e. hardware, operatmg system, a partlc-

t 1 f t t d thods.s ye o s ruc ure me .ular process- or scheduling model and ad-ditional required software like libraries. e an architectural view may present the sys-

tem boundaries, its external interfaces, thee Implementations: This facette contains substructure of the system's components

a family of executables for various plat- and the specification of behaviour for ba-forms and environments, and possibly also sic components without further structuralsubsequent revisions of executables for refinement. This view can be used to sup-downward compatibility. port the transition from a functional to a

structural view of a system. Separating in-e Parameters: Many components need to dependent subsystems it is also a valuablebe/can be paramterized for different co~- help for concurrent en~neering.texts. Also, many components need calli-bration. The parameters facette holds data e an implementation view may present theof this kind. executable code that implements a compo-

nents architecture together with dependen-e Qualit y of Service: This facette spec- cies among code units. This view may be

ifies required qualities of underlying ser- used to determine compile- and load depen-vices, such as network bandwith, memory dencies, i.e. it can be used to generate make-capacityetc. files or similar structures.

C m nents may be generalised to compo- 2For a discussion of the differences between objectsO pO and components in the sense of e.g. Java Beans, see [12].

nent types, tempIates or prototypes, that can 3Recently, there have also been advances in specifying

be instantiated or cloned. In a sense, compo- the behaviour of aJgebraic specifications in a more finelynents correspond to objects as in object-oriented grained way, e.g. by co-algebraic approaches.

4

programming languages (and the usual design-notations including the UML). However, thereare important differences.2 First, objects arevery fine grained entities, mostly of a technicalnature. Components, on the other hand, mustbe able to represent very large real-world enti-ties. Second, objects clearly violate the threerequirements we have put up. Thus, objects arean inapropriate concept for architectural mod-elling. An algebraic specification does better inthat it specifles the behaviour of an interface bya set of axioms3, and offers an abstract repre-sentation fo the component (cf. [20]). It stillviolates the second, though, and is very bardto use for the vast majority of designers. Also,it focusses exclusively on the transformationalaspect of a component, and leaves out any in-formation for other phases in a component 's life-cycle.

All three of these views may be either flat,i.e. representing only one layer of functional-ity, realisation or implementation, respectively,or the recursive sub-functionality, -realisationor -implementation, respectively, to arbitrarydepths.

Note that the implementation view corre-sponds to the information conveyed by com-ponents in the sense of Java Beans, COM,CORBA, or UML components. The realisationview corresponds to a model similar to those ofUML/RT and ROOM.

Other applications and activities might re-quire further views and facettes. For instance,there might also be a deployment view, a hard-ware/software distribution view, a samples view(e.g. pointers to sample applications with thecomponent, experience reports), a performanceview ( e.g. load figures relative to number of usersand so on), a test view (e.g. test cases, partitionsof input data, error densityand so on).

4 Mapping of concepts to

the UML Abstract Syntax

In this section, the concepts introduced aboveare embedded into the conceptual frameworkof the UML. This is done by introducing newclasses of the UML's meta-model as stereotypesof existing classes. This mechanism is the pre-ferred way of extending the UML, accordingto the UML semantics definition ( compare thechapter on extension mechanisms, [11, p. 2-65]).Figures 1 shows an excerpt of the UML meta-model, and the concepts we have introduced be-fore.

"

Protocol Protocols have a fixed set of at leastt wo roles, a collaboration between these, andpossibly same matching interactions. A role isan UML actor with a UML state machine andt wo UML interfaces, tagged as in and out, re-

spectively.

Architectural interface Architectural inter-faces have an protocol and a tagged valuemyProtocolRoles (a non-empty set of rolenames), that indicates which of the roles the in-terface plays in the protocol.

Architectural facette An ArchitecturalFacette is an UML package with a tagged value

.The implementations facette contains a setofbinaries (possibly also sources) for a com-

5

called FacetteKind that can take on any of thevalues Functionality, lnterfaces, Realisation,Platfonns, lmplementations, Parometers orQ oS. Facettes with different FacetteKinds canbe seen as subclasses of the class Architectural-Facette. Each facette has individual restrictionsdepending on the value of FacetteKind:

.The functionality facette contains a set ofUML octors and use cases. Actors are un-derstood in the original sense of OOSE- orROOM-octors, i.e. theyare arbitrary ex-ternal systems, including human users andother software and hardware components.

.The interfaces facette is a collection of ar-chitectural interfaces. It can be representedby a package for each interface (i.e. portor SAP), containing t wo types (abstractclasses without data members) to specif ythe ingoing and outgoing signals tagged inand out, its protocol (a UML state ma-chine), the role mapping (i.e. which role inthe protocol this port plays) and switchesmarking an interface as optional or foculta-tive etc.

.The realisation facette roughly correspondsto the realisation elements of a UML sub-system. It contains either an architecturaldesign or a behavioural specification, thelatter being a plain UML state mochinethat uses only the operations of the inter-faces in the interfoces facette. The for-mer consists of an architectural configu-ration that is connected to the interfacesof the component by links specified in theadapters focette. A realisation facette alsocontains a set of extension and customisa-tion points, i.e. a description of the parame-ters and switches that may be used to adaptthe component to a particular applicationsite.

.The platforms facette indicates the requiredplatform a component needs to be exe-cuted, i.e. a certain type of hardware, oper-ating system etc. In order to structure thisfacette, the tagged values Hardware, Oper-atingSystem, Compiler, ComputingPower,Memory and StorageCapacity are prede-fined. Further aspects may be added asneeded.

UML Meta-Model Architecturol Modeling Concepts

Figure 1: Generalisation hierarchy of the main concepts for architectural modelling (in UMLnotation). UML-Metaclasses are in slanted type.

ponent, tagged with information like the of well-separated facettes with distinct purposestarget platform, version numbers etc. Ev- and speciflc constraints. Architectural compo-ery implementation may consist of a set of nents have the additional boolean attribute is-UML components, possibly again grouped Static, that is false, if any interface has a mul-in UML packages, and any uses- imports or tiplicity other than the fixed value 1. Compo-refinement-relations between them. nents also have the boolean attribute hasSer-

vices, that is false, if they have no broadcast.The parameters face t te can be realised by interfaces. Static components without broad-

an application speciflc set of tagged values. cast interfaces can be used as layers in a layered

system..The quality-of-service facette specifles any

guarantees a component makes with re-spect to the quaIity of the services it pro- Architectural adapter Architecturalvides, e.g. the response times for certain ~dapters are connections betw~n architecturalpairs of incoming/outgoing signals. Cur- ffiter~ac:s. They correspond ~l~ectly to ~MLrently, the UML offers little expressive assoclatl.ons, but add the ~dltlonal. attnbutemeans to model quaIities of service. For type, WhlCh refers to an architectural ffiterface.

the time being, it could be represented bya set of tagged va!ues. Architectural Configuration An Architec-

tura! configuration consists of a collaboration of

Architectural views Architectura! views are cornponents. Layered systerns can be ffiodelled

UML packages. by an acyclic graph of static cornponents with

broadcast interfaces between theffi.

Architectural components The concept ofarchitectural coroponents is a refinement and ex-tension of the UML notion of subsystem. UMLsubsysteros offer UML interfaces and operations(roore generally: UML features), its contentsis divided into specification and realisation el-ements, both of which are represented by ar-bitrary ModelElements. Architectural coropo-nents, in contrast, offer architectural interfacesonly. Their contents is organised into a number

6

5 Architectural diagraffis

In this section we present a concrete syntax forthe concepts presented above. These diagramsare called architectural diagrams. Since all con-cepts presented here are mapped to the UML,the corresponding usual graphical representa-tion in the UML should be used where possi-ble. So, all concepts presented here have an ex-

plicit representation which follows the conven-tions of the UML concepts theyare mapped to.However, most coDcepts also need different rep-resentations for different pragmatic situations,i.e. the representation depends on the usage COD-text, i.e. on the view a concept appears in. Here,we try to stick to other accepted notations, suchas those of the ROOM method (see [15]) andUML/RT (see [7] for a concise description of thesyntax). In some places, however, slight propri-etary modifications are unavoidable.

~

Interfaces As an explicit representation, theusual UML packages can be used; the signal setsare simply UML interfaces tagged as in and out,respectively. In the context of a realisation view,the UML/RT conventions are adopted (see Fig-ure 3 (c,d), where pointcast interfaces appearas little boxes on the edges of bigger boxes). Inthe context of an implementation view, inter-faces should be represented in the lolly-notation(see Figure 3 (f)). Broadcast interfaces have nodirect equivalent, neither in UML nor in ROOM,so we made up the symbol] [ for this purpose.Dynamic structure is represented by stacked in-terfaces symbols as known from ROOM.

Components, facettes and views Compo-nents are represented by boxes with a smallcompartment holding its name, much like UMLclasses. The other representational features aredetermined by the view olle has on a specificcompoent.

.The functionality view can be adequatelyrepresented by the usual use case diagram.Associated documents with natural lan-guage descriptions of roles, use cases, andinterfaces can be represented by documenticons associated to model elements of theuse case diagrams.

.The architecture view is represented in thesyntax known from ROOM and UML/RT(see [7] for a concise description). Of-ten, there is a dedicated controller sub-component for a component. Semantically,this can be represented by a subcomponentwith a broadcast port to its peers. As somesyntactical sugar , the notation known fromROOM can be adopted.

.The implementation view is represented bythe usual UML syntax, i.e. by package andcomponent diagrams.

7

Figure 4: Alternative notation for connectionswith trivial behaviour.

All three views can showaflat component or anumber of subsequent levels of refinement. SeeFigure 3 for some examples of flat and deep rep-resentations of functionality, architecture andimpementation views. In general it is possi-ble to mix views, both for peer and for sub-components.

Adapters Adapters are represented as planlines between the components they connect.Frequently, adapters need to perform simple ac-tions such as renaming, transposing or project-ing from the signals transmitted by them. Inthe conceptual body presented here, this can bedone only by an intermediate component. Sucha component, however, has a trivial structure,so that often it is convenient to use syntacticsugar instead. Similarly, sometime one needs tomodel non-perfect connections. Again, interme-diate components clutter up architectural dia-grams and should be replaced by an alternativenotation. See Figure 4 for some suggestions.

Configurations Configurations are repre-sented as collaborations of components, wherethe representation of components depends onthe view chosen on the respective component.Layered systems can be represented by an alter-native syntax (see Figure 2).

6 Practical experiences

The concepts and notations introduced abovehave been used in conducting a one-term prac-tical assignment with undergraduate students.Architecture diagrams have been used for the

: Layer_Namefr~tocol- 1

~ ~~;?t 2

: -S~b=L~y~~_)i~~; :~~ -> "'-~~»

ao-Bod~:~

~ -> <-~>,

00:- ib(X~: W I

(b)(a)

Figure 2: (a) defiition of a protocol; (b) alternative notation for layered systerns.

initial definition and subsequent evolution of thesystem 's architecture. So far , they have beenused only on a paper-and-pencil basis, i.e. with-out editors or analysis tools.

Still, all participants have found architecturediagrams helpful and indeed very adequate fordocumentation of and communication about theoverall system. The concepts were generallyacclaimed as being readily understandable anduseful, even in the absence of automated tools.Unsurprisingly, the syntax revealed some de-ficiencies, in particular wrt. to timing anno-tations and dynamic structure. It proved tobe necessary to guide the students very tightlythrough the development process, though the in-cidential occurrences of "diagram abuse" largelyresulted from UML diagrams rather than fromarchitectural diagrams.

The most valuable effect is the ability to de-fine behavioural interfaces of subsystem, and ap-ply the usual techniques and procedures suchas UML Interaction Diagrams and interactiverole plays and walkthroughs on the architecturelevel. This provided effective support for con-current engineering, and thus was pivot al for theoverall system development process.

7 Other approaches

There are a number of textual ArchitectureDescription Languages (ADLs), most notablyWRIGHT [1], UNICON [19], Rapide [6] andSARA [4] (see [9] for an overview). Some of

8

thero also have ad-hoc graphical notations andassociated tools for code generation or analy-sis. None of thero relates to the UML, how-ever, or is integrated with a broader notationaland roethodological framework as is present anderoerging with the UML, respectively. The sameapplies for other forroalisros, such as S DL andHOOD [14].

The UML itself offers only very scarce facili-ties for roodelling on the architecture level. Thepresent version (1.1) has only the iropleroan-tation diagraros (package, coroponent and de-ployroent diagraros) and traditional Use cases.The forthcoroing version ( at the tiroe of writ-ing, the roost recent revision is 1.3 beta 7) alsooffers subsysteros, but their seroantics and inte-gration with the rest of the UML is largely un-clear. A real-tiroe profile for the UML has beendiscussed, adopting notions froro the ROOMroethod (see [16, 7]), though no publication onthis issues is currently available.

The novel notion of coroponent presented inthis paper4, on the other hand, features strongencapsulation, direct support for the activi-ties relevant in CBSD, and an integration withaccepted design notations .There are quitea nurober of publications on the definition of

software engineering processes for CBSD (seee.g. [2, 5, 10]). Surprisingly, however, none ofthero discusses the requireroents on the under-

lying notion of coroponent generated by the ac-

4 A previous versjon of the component notjon has been

presented jn [17].

(a) (b)

(c) (d)

/Component Name\

/Con.,o..-It--\

(e) (f)

Figure 3: Some views on a component: flat and deep representations (left to right); functionality,realisation and implementation views (top to bottom).

tivities used in the process, let alone introducea similar notion of component as is presentedhere.

8 Summary

This paper provides an embedding of practicallyproven concepts into the conceptual frameworkof the UML. It also enhances the notion of com-ponent so as to better accomodate the activitiesspecific to CBSD. The concepts and notationshave been used in a practical project with stu-dents, though so far, insufficient data has been

9

gathered.Therefore, future work will concetrate on im-

plementing a tool to support the diagrams andthe CBSD-related operations. Also, furhterwork is required on the semantical foundationsof architectural modelling (see the companiontechnical report [18] for a semantics of ROOM-diagrams).

References

[1] Robert Allen and David Garlan. A FormalBasis for Architectural Connection. ACM

TOSEM, 6(3):213-249,1997. [10] Jim Q. Ning. A Component-Based Soft-.ware Development Model. In Proc. 2Oth

[2] Klaus Bergner, Andreas Rausch, Marc Slh- Annual Intl. Cornputer Software and Ap-ting, and Alexander Vilbig. A component- plications Con!. (COMPSAC'96}, 1996.ware development methodology based onprocess patterns. In ?? , editor, Proceed- [11] OMG. OMG Unified Modeting Lan-ings of the 5th Annual Conference on the guage Specification (draft, version 1.3betaPattem Languages of Progmms, (PLOP}, Rl). Technical report, Object Management1998. Group, 1998. available at uml.shl.com.

[3] Francois Bronsard, Douglas Bryan, [12] Cuno Pfister and Clemens Szyperski. W hyW. Voytek Kozaczynski, Edy S. Lion- Objects Are Not Enough. In Hans Blubber,gosari, Jim Q. Ning, Asgeir Olafsson, and editor, Proceedings First Intl. CornponentJohn W Wetterstrand. Toward software User Conference (CUC'96}, July 1996.plug-andplay. In Mehdi Harandi, editor, ...Proc. 1997 Symp. on Software Reusability [13] Ruben Pneto-Dtaz. ImplementIng facete~(SSR'97}, 1997. classification for software reuse. Communl-

cations of the ACM, 34(5), may 1991.[4] G. Estrin, R.S. Fenchell, and M.K. Ra- ...

wuk, R.R. Vernon. SARA (System Archi- [14] Peter ~. Robl.nson. H?OD -H~emrchl-tects Apprentice): Modelling, Analysis and cal ObJect-Onented DesIgn. Prentlce Hall,Simulation Support for Design of Concur- 1992.

rent Systems. IEEE Trans. Softw. Eng., [15] Bran Setic, Garth Gullekson, and Paul T.12(2):293-311, 1986. Ward. Real Time Object Oriented Model-

[5] Wolfgang Hesse. From WOON to EOS: ing. Wiley & Sans, Inc., 1994.New development methods require a ne,,:, [16] Bran Setic and James Rumbaugh. Us-software process model. In A. Smolyanl- ing UML for Modeling Complex Real- Timenovand A. Shestialtynow, editors, Proc. Systems. Technical report Rational Saft-WO ON '96/WOON'97, 1. and 2. Interna- ware Corp. & ObjecTime Ltd., 1998.tional Conference on 00 Technology, pages88-101,1997. [17) Harald Störrle. A different notion of com-

.ponents. In Andreas Schiirr and Peter Hof-[6] D.C. Luckham, L.M. AugustIn, J.J. Ken- mann, editors, Object-Oriented Modelling

ney, J. Vera, D. Bryan, and W. Mann. ofReal-Time Systerns (OMER'99} 1999.Specification and Analysis of System Archi- ,

tecture using Rapide. IEEE Trans. Softw. [18] Harald Störrle. A formal semantics ofEng., 21(4):336-355, April 1995. ROOM with apptications. forthcoming,

[7) Andrew Lyons. UML for Real-Time 1999.

(Overview). Technical report, ObjecTime [19] Jan van Leeuwen, editor. FormulationsINC., see www.objectime.com, 1998. and Formalisms in Software Architecture,

.volume 1000 of LNCS, pages 307-323.[8] Masao Matsumoto, Satoshl Hayano, S. 1995

Takahiro Kudo, Hideo Yoshida, Shunzo pnnger, .

Imai, and Kiyoshi Ohshima. Specifications [20] Martin Wirsing. Algebraic specification. InReuse Process Modening and Case Study- Jan van Leeuwen, editor, Handbook of the-Based Evaluations. In Proc. 15th Annual oretical Cornputer Science, pages 675-788.Intl. Cornputer Software and Applications Elsevier, 1990.Con!. (COMPSAC'91}, 1991.

[9] Richard N. Taylor Nenad Medvidovic. Aframework for classifying and comparingarchitecture description languages. Num-ber 1301 in LNCS. Springer, 1997. also ap-pearwd in SE Notes, Vol. 22, No.6, pages60-75.

10