Generating UML Models from Domain Patterns

Dae-Kyoo Kim

kim2@oakland.edu

Department of Computer Science

and Engineering

Oakland University

Rochester, MI 48309

Jon Whittle

jonathw@email.arc.nasa.gov

QSS Group Inc.

NASA Ames Research Center

Moffett Field, CA 94035

Abstract

The development of a family of applications in a domain can be greatly eased if patterns in thedomain are systematically reused. Systematic use of such a pattern can be achieved by tools thatsupport pattern-based development. In this paper, we describe a prototype tool called RBML-Pattern Instantiator (RBML-PI) that generates UML class diagrams and sequence diagramsfrom a pattern specification described in the Role-Based Metamodeling Language (RBML), apattern specification language, that defines a domain-specific sub-language of the UML. We givean overview of the RBML using the Observer design pattern, and demonstrate the tool usingan RBML specification for the CheckIn-CheckOut (CICO) domain pattern that characterizesservices to check in and check out items. We use the CICO pattern specification to generateUML models of a library system and a vehicle rental system using RBML-PI.

Keywords: Design pattern, object-oriented model, pattern specification, pattern tools, UML

1 Introduction

A domain-specific design pattern (henceforth referred to as domain pattern) captures design solu-tions for a family of applications in a software domain. Examples of domain patterns are the CyclicExecution pattern in the real-time domain that describes controling the execution of tasks in adefined sequence [1], and the Remote Operation pattern [14] in the network domain that describesconstructing distributed systems based on a client-server architecture. Systematic use of domainpatterns can reduce development time of applications in the domain [11].

In this paper, we describe a prototype tool, RBML Pattern Instantiator (RBML-PI), thatgenerates UML class diagrams and sequence diagrams from a pattern specification described in theRole-Based Metamodeling Language (RBML) [4, 6], a pattern specification language that definesa domain-specific sub-language of the UML [15]. Use of the sub-languages to build models ofapplications in the domains results in reuse of design experience embedded in the domain patterns.

RBML-PI uses IBM Rational Rose as a base tool. Pattern authors can use the drawing featuresprovided by Rose to build an RBML pattern specification because the RBML is based on the UMLsyntax. Application developers can then use the RBML specification to generate UML modelsusing RBML-PI.

Several tools [3, 10, 12] that generate application models from patterns have been developed.These tools are based on templates and do not allow pattern instantiations to be significantly

different in structure than their defining pattern templates. This is limiting in practice. For exam-ple, models that implement the Observer design pattern may have one or more classes, dependingon the application, that play the Observer role. Current tools do not support structural varia-tions of pattern specifications such as varying the number of classes playing a role in the designpattern. RBML-PI does support such variations through variation points where developers canspecify additional information to tailor the instantiation of the pattern specification.

In our previous work [7, 8], we developed the CheckIn-CheckOut (CICO) domain pattern. Theprimary purpose of applications in this domain is to provide services for checking in and out items.Applications within this domain include video rental, car rental, and library systems. We usedthe CICO pattern as a basis for developing UML models of a library system and a car rentalsystem. These models were developed manually. In this paper, we describe how these models canbe generated using RBML-PI.

We give an overview of the RBML in Section 2. We describe the CICO domain pattern inSection 3. We describe RBML-PI in Section 4 and show how the tool can be used to generatemodels from RBML specifications in Section 5. We give an overview of related work in Section 6and conclude in Section 7.

2 Overview of the RBML

The RBML is a language for specifying patterns as families of UML models. An RBML specificationdefines a specialization of the UML metamodel at the metamodel level (M2) [15] that characterizesUML models of pattern solutions at the model level (M1) as shown in Fig. 1.

defines

specialized

M1

M2

defines

PatternSpecification

SpacePattern Solution

UML Model Space

UML Metamodel

Figure 1: An Overview of RBML Mechanism

The UML metamodel characterizes valid UML models. It consists of a class diagram and a setof well-formedness rules that define the abstract syntax of the UML. Informal descriptions of se-mantics are also included in the metamodel. The metamodel class diagram consists of classes whoseinstances are UML model elements. For example, instances of the metamodel class Association areUML associations. Well-formedness rules that are not expressible in the metamodel class diagramare expressed using the OCL where possible, and in natural language otherwise.

Fig. 2 shows a part of the UML metamodel class diagram (class attributes are not shown) [15].A classifier describes a set of instances that have features in common. A class is a kind of classifiers

2

Feature Classifier

BehavioralFeatureStructuralFeature

Property Operation

Class

Property12..**11* Association

Figure 2: A Part of the UML Metamodel

whose features are attributes and operations. Attributes of a class are represented by instances ofProperty that are owned by the class. Some of these attributes may represent the navigable ends ofbinary associations. In Fig. 2 the multiplicity 2..* at the Property end specifies that an associationmust have at least two association ends (properties). Operations of a class are represented byinstances of Operation. An operation is a behavioral feature of a classifier that specifies the name,type, parameters, and constraints for an associated behavior.

An RBML pattern specification consists of roles [9]. A role defines properties of the patternsolution characterizing a family of model elements. A role has a base metaclass in the UMLmetamodel, and is played by instances of the metaclass that satisfy the properties specified in therole. A model conforms to a pattern specification if the model has elements that play the rolesdefined in the pattern specification.

The RBML provides three types of specifications: 1) Static Pattern Specifications (SPSs) specifyclass diagram views of pattern solutions, 2) Interaction Pattern Specifications (ISPs) specify inter-action diagram views of pattern solutions, and 3) State Machine Pattern Specifications (SMPSs)specify state diagram views of pattern solutions.

In this work, we do not use SMPSs, and thus SMPSs are not described. Interested readers arereferred to [9, 6].

2.1 Static Pattern Specifications (SPSs)

An SPS consists of classifier and relationship roles whose bases are Classifier and Relationshipmetaclasses (or their subclasses) in the UML metamodel. A classifier role is connected to otherclassifier roles by relationship roles. An SPS role is associated with well-formedness rules andconstraint templates expressed in the Object Constraint Language (OCL) [16]. Well-formednessrules are metamodel-level constraints that specialize the UML metamodel so that it specifies onlymodels of pattern solutions. A constraint template specifies model-level constraints (e.g., pre- andpost-conditions) produced by binding role names in the template to conforming model elements.

Fig. 3(a) shows a partial SPS that specifies solutions of a restricted Observer pattern variant[5]. The SPS characterizes class diagrams in which subjects are associated with one or moreobservers. Each subject can consist of one or more structural features (i.e., attributes) that conformto SubjectState, and one or more behavioral features (i.e., operations) that conform to Attach.The Subject role is also associated with a Notify and a Detach behavioral role (not shown inthe diagram for the sake of brevity). Each observer must have only one structural feature that

3

1

|ObservesAssociation Role

|Update(|s:|Subject) 1..1

|ObserverState: DataType 1..1

|Sub 1..*

|Attach(|o:|Observer) 1..*

|SubjectState: DataType 1..*

Class Role

Class Role

|Obs 1..1

1..*|Observer

1..*|Subject

defines 1

Subject

Attach

1

1

1

1..*

ObserverState

(a) A Partial SPS

11..*ObsSub

(b) Partial View of the Specialized UML Metamodel

Parameter

1

1 1

AssociationEnd

StructuralFeature

1

1

Class

BehavioralFeature

1o

Association

Observes

Observer

Figure 3: An SPS for Simplified Observer Pattern and its Specialized UML Metamodel

conforms to ObserverState, and one behavioral feature that conforms to Update behavioral role.The symbol “|” is used to indicate roles. A text label (e.g., Class Role) on a role denotes the baseof the role in the UML metamodel. The roles define subtypes (specializations) of classes in theUML metamodel as shown in Fig. 3(b).

currTemp: IntcurrPress: Int

pressure:Inttemp:Int

Kiln

TempObsPressureObs

obsPress

obsTemp

AttachTempObs ( o:TempObs)o:PressObs)AttachPressObs (

UpdatePress ( k:Kiln) UpdateTemp (k:Kiln)|Update (|s:Subject) 1..1

|Attach (|o:|Observer) 1..*

|Sub 1..*

conforms to

1..11..1k2

k1

p t **1..*

1..*

(a) The SPS in Fig.3

|ObserverState: DataType 1..1

(b) A Conforming Class Diagram

|Obs 1..1

|SubjectState: DataType 1..*

|Observes

Class Role

Class Role|Observer

Association Role

|Subject

Figure 4: A Conforming Class Diagram

4

Obtaining a conforming application model from a Role Model involves binding model elementsto roles. Fig. 4(b) shows part of a model obtained by binding model elements to roles in the partialObserver SPS in Fig. 3(a). The class diagram shown in Fig. 4(b) describes a system in whicha kiln sensor (instance of Kiln) that records the temperature and pressure in a kiln is linked totemperature and pressure observers that monitor kiln temperature and pressure. Dashed arrowsshow a mapping between roles in the SPS and model elements in the conforming model. Forexample, both the AttachTempObs and the AttachPressObs operations play the Attach role. Thetwo association ends on Kiln class conform to Sub role whose base is AssociationEnd metaclass.The multiplicities (1..1) on the association ends are defined in well-formedness rules (not shown)of the Sub role. Stereotype symbols may be used in conforming models to denote the roles that themodel elements play. A more formal notion of SPS conformance is described [6].

2.2 Interaction Pattern Specifications (IPSs)

IPSs are used to constrain interactions between pattern participants. An IPS consists of an inter-action role that defines a specialization of the UML metamodel class Interaction. An interactionrole is a structure of lifeline and message roles whose bases are Lifeline and Message metaclasses.Each lifeline role is associated with a classifier role in an SPS: a participant that plays a lifelinerole is an instance of a classifier that conforms to the classifier role. A message role is associatedwith a behavioral feature role in an SPS: a conforming message specifies a call to an operation thatconforms to a behavioral feature role. In this work, the UML 2.0 sequence diagram notation isused for a richer set of constructs, including constructs for packaging and referencing interactions.

Fig. 5(a) shows the IPS that describes the interaction between a subject and its observers thattakes place as a result of invoking the subject’s Notify operation. The Notify behavior results incalls to operations that conform to the Update role for each observer associated with the subject.Each observer then calls the operation that conforms to GetState in the subject. In the figure, thelifeline role |s : |Subject represents instances of a class that conforms to the classifier role Subject

in Fig. 3(a) and the message role Update represents synchronous calls to operations that conformto the feature role Update. NumOfObservers is a function that returns the number of observerslinked to the participant that plays the lifeline role labeled |s : |Subject.

Formally, an IPS defines a specialized UML metamodel that specifies a family of sequencediagrams as shown in Fig. 5(b). For example, the interaction role NotifyInteraction defines aspecialization of the UML metamodel class Interaction, and the lifeline role labeled |s : |Subject

defines a specialization of the UML metamodel class Lifeline labeled s : Subject in Fig. 5(b).Fig. 6 shows a conforming sequence diagram obtained by binding roles in the NotifyInteraction

IPS shown in Fig. 5. The sequence diagram conforms to the IPS in that it preserves the relativeorder of the conforming messages, NotifyObs, UpdateTemp, and GetKilnTemp as specified in theIPS. The application specific lifeline m receiving LogUpdateRecd message is added during realization.A more formal notion of IPS conformance is described [6].

3 The CICO Domain Pattern

The CICO domain pattern characterizes a family of checkin-checkout applications that manageitem check in or check out. Applications within this domain include video rental, car rental andlibrary systems. Some features of CICO applications characterized by the domain pattern are givenbelow:

5

|st := |GetState()

|o[k]:|Observer

|s:|Subject

(a) Example of an IPS

|Update (|s)

(b) The Specialized UML Metamodel

Update

o:Observer

1

1..*

NotifyInteraction

1..*

1..*

1111

GetState

|Notify()

Message|NotifyInteraction 1..*

loop<k=1..NumOfObservers>defines

Interaction

st

s

1

1

1

1s:Subject

Lifeline

ValueSpecification

Figure 5: An IPS for the Observer Pattern and its Specialized UML Metamodel

st := GetKilnTemp()

UpdateTemp (s)

s:Kiln

t[k]:TempObsloop<k=1..NumOfObservers>

NotifyObs()

sd KilnInteraction

Figure 6: An IPS and a Conforming Sequence Diagram

1. Items that can be checked out and in have unique identifiers.

2. Items are maintained in one or more collections (e.g., a library system can have a collectionof journals, a collection of references, and a collection of general books).

3. CICO applications maintain a list of registered users, that is, users that are authorized tocheck in or out items. Users can be grouped into different categories (e.g., a university librarysystem may group users into faculty and student categories).

4. A user can checkout an item (referred to as lending in this section) if it is available and thecheck out does not violate lending policies (e.g., a policy may constrain the number of itemsa user in a particular category can have checked out at any time).

6

5. A checked out item can be checked in. The CICO domain pattern covers only those applica-tions in which an item can be checked in only if it was previously checked out.

3.1 CICO SPS

|LendingItemAssociation Role

|IC 1..*

|ID 1..*

|IB 1..*|LB 1

|LendingUser

|ContColUser

|UC 1..*

Classifier Role|CollectionUser

|CA 1..*

|CB 1..*

|UB 1..*

Association Role

|UA 1..* |LD 1..*

Association Role|ColLendingLending

|EB1..*

|ContItemAssociation Role

|ContLending

|ContUser

Association Role|ColUserUser

|ItemClassifier Role

Hierarchy

|IA 1..*

|DA 1..*

|ItemDescAssociation Role

Class Role|Description

|ColItemItemAssociation Role

|OB 1..*

|OA 1..*

|ContColItemAssociation Role

Association Role

|EA 1..*

|CollectionItemClassifier Role

|UserClassifier Role

Hierarchy

|LendingClassifier Role

|CollectionLendingClassifier Role

|ControllerClassifier Role

|TB 1

|TG 1

|TF 1

|TD 1

|TA 1

|LC 1..*

Association Role

Association Role

|ContColLending

Association Role

|LA 1..*

|TC 1

Figure 7: The CICO SPS

Fig. 7 shows the SPS characterizing static structure diagrams that conform to the CICO domainpattern. The SPS consists of roles that specify domain-specific concepts such as registered user(User), collection of registered users (CollectionUser), item check out details (Lending), item (Item),item description (Description), and checkin/checkout manager (Controller).

The folded form of role hierarchies in Fig. 7 is used to represent item and user role hierarchies.Fig. 8(a),(b) show the unfolded forms of the User and Item role hierarchies. These role hierarchiesspecify class generalization hierarchies. Fig. 8 also shows the CICO domain pattern classifier roleswith their feature roles.

The following is an overview of the properties defined in each classifier and hierarchy roleshown in Fig. 7. Constraint templates for some of the more interesting feature roles are described.Multiplicity and other properties specified in association-end roles are not given in this section.

Item role hierarchy (Fig. 8(a)): Item role has ItemID, ItemStatus, VerifyStatus and Updat-eStatus feature roles. The ItemID role specifies a structural feature that uniquely identifies items,and the ItemStatus role specifies a structural feature that is used to indicate whether an item ischecked in or checked out.

The types associated with structural features that conform to ItemID must be instances of theDataType metaclass. The types associated with structural features that conform to ItemStatusmust conform to ItemStatusEnum.

7

Generalization Role|ItemGeneralization

* *

|UserGeneralizationGeneralization Role

* *

Class Role|Description

|ItemID : |DataType 1..1|ItemStatus : |ItemStatusEnum 1..*

|VerifyStatus() : |DataType 1..*|UpdateStatus (|s : |ItemStatusEnum) 1..*

(a) Item Role Hierarchy

(i) Enumeration Roles

(b) User Role Hierarchy

|UserID : |DataType 1..1|UserStatus : |UserStatusEnum 1..*

|AVAILABLE 1..1|CHECKEDOUT 1..1

|ItemStatusEnum

|HOLD 1..1|ELIGIBLE 1..1

|UserStatusEnum

|FindItem (|iid : |DataType) : |Item 1..*

1..*Class Role|CollectionItem

1..*Class Role|Item

|FindUser (|uid : |DataType) : |User 1..*

1..*Class Role|CollectionUser

1..*

|VerifyStatus() : Boolean 1..*

1..1

1..1Enumeration Role

Enumeration Role

Class Role|User

(d) CollectionItem Role (e) CollectionUser Role

(g) Controller Role

(f) CollectionLending Role

(c) Lending Role

1..1Class Role|Lending

|LendingID : |DataType 1..1

|AddNewLending (|ld : |DataType) 1..*

1..*Class Role|CollectionLending

(h) Description Role

|CheckIn (|iid : |DataType) 1..*|CheckOut (|uid : |DataType,

1..1Class Role|Controller

|DetailOfItem : |DataType 1..*

1..*

|iid : |DataType) 1..*

Figure 8: CICO Role Hierarchies

The V erifyStatus behavioral role specifies a behavior that returns true if the item is availablefor checkout and false otherwise:

context |Item :: |VerifyStatus (): |DataTypepre : truepost: if |ItemStatus = |AVAILABLE then result = true

else result = false

UpdateStatus specifies a behavior that changes the status of an item. For example, whenever anitem is checked out (or checked in), an update behavior is performed to change the status of theitem:

context|Item :: |UpdateStatus (|s : |ItemStatusEnum)pre : truepost: |ItemStatus = |s

User role hierarchy (Fig. 8(b)): The User role has UserID, UserStatus, and V erifyStatus

feature roles where V erifyStatus specifies a behavior that returns true if a user can check out an

8

item and false otherwise.

Lending role (Fig. 8(c)): The Lending role characterizes classes defining information about aparticular item checkin or checkout. The role has LendingID structural feature role.

CollectionItem role (Fig. 8(d)): The CollectionItem characterizes classes defining groups ofitems. It includes a behavioral role FindItem specifying a behavior that locates an item given theitem’s ID.

CollectionUser role (Fig. 8(e)): The CollectionUser role characterizes classes representingcollections of users. It includes a behavioral role FindUser specifying a behavior that locates auser given the user’s ID.

CollectionLending role (Fig. 8(f)): The CollectionLending role characterizes classes describ-ing objects that maintain a collection of checkin and checkout details. It has a AddNewLendingbehavior role that characterizes a behavior that adds new lending information to the collection.

Controller role (Fig. 8(g)): The Controller characterizes classes that manage the checkin andcheckout of items. The role includes two behavioral roles, CheckIn and CheckOut representingcheckin and checkout behaviors, respectively. Constraint templates for the CheckIn and CheckOutare given below.CheckIn Precondition: The item must have been checked out.CheckIn Postcondition: The FindItem operation is called and if the operation returns the itemand if the item’s status indicates that the item has been checked out, the item’s status is changedto indicate it is now available for checkout by calling the item’s UpdateStatus() operation:

context |Controller :: |CheckIn (|id : |ID)pre : item.|ItemStatus = |CHECKEDOUTpost: let message: OclMessage =

|CollectionItem^^|FindItem(|id) → any(true)inmessage.hasReturned() and message.result() = itemand item@pre.|VerifyStatus() = falseand item^|UpdateStatus(|AVAILABLE)

CheckOut Postcondition: The FindUser and FindItem operations are called. If the retrieved useris eligible to checkout the item and the item is available, a record of the checkout is included inCollectionLending and the item status is updated to indicate that it has been checked out:

context |Controller :: |CheckOut (|uid:|ID, |iid:|ID)pre : truepost: let itemMessage: OclMessage =

|CollectionItem^^|FindItem(|iid) → any(true),userMessage: OclMessage = |CollectionUser^^|FindUser(|uid)→ any(true)inuserMessage.hasReturned() and userMessage.result() = user

9

and user@pre.|VerifyStatus() = trueand itemMessage.hasReturned() and itemMessage.result() = itemand item@pre.|VerifyStatus() = trueand |Collectionlending → exists (lendinfo | lendInfo.oclIsNew()and lendInfo.|User = user and lendInfo.|Item = item)and item^|UpdateStatus(|CHECKEDOUT)

It is important to keep in mind that the above specifications describe patterns and no attempt ismade to specify complete CICO behavior. For example, the above templates can be used to createinitial specifications for checkin and checkout operations, which can then be extended by designersto meet application-specific requirements not captured by the pattern. This is further discussed inSection 5.

3.2 CICO IPSs

Fig. 9(a) shows an IPS for a checkin scenario. The item is found in the item collection, and itsstatus is checked to determine whether it is checked out. If the item is checked out the status of theitem is updated. opt is a predefined operator in UML 2.0 sequence diagram to represent optionalbehavior.

Fig. 9(b) shows an IPS for a checkout scenario. An instance of a classifier that conforms toController invokes FindUser with the user ID uid to obtain a matching user u from a collectionof users. The status of the user is verified, and if the user is allowed to checkout the item therequested item is retrieved. The status of the item is queried to determine if it can be checked out.If the item can be checked out, a lending record is created. The record is then added to a collectionof lendings (CollectionLending). The status of the item is updated to indicate that it has beenchecked out.

4 RBML Pattern Instantiator (RBML-PI)

RBML-PI is a tool that generates UML class diagrams and sequence diagrams from an RBMLpattern specification. RBML-PI is developed on top of IBM Rational Rose as an add-in componentwritten in C++. We evaluated several other UML modeling tools (Together, ArgoUML, Poseidon,Microsoft Visio) as a base tool of RBML-PI, and chose Rose for the following reasons:

• RBML-PI was developed in collaboration with NASA Ames Research Center for an Air TrafficControl System project. They developed a tool based on Rose that generates state machinesfrom scenarios (i.e., sequence diagrams). In this research, Rose was chosen to be compliantwith their tool, so that the two can work together. RBML-PI generates sequence diagramsthat conform to a pattern specification, and the generated sequence diagrams can be fed toa statemachine generator to obtain statemachines.

• Rose provides a good API called Rose Extensibility Interface that allows one to access theUML metamodel (precisely speaking the Rose metamodel) for manipulation of UML models.

• Within the consideration of the above two reasons, Rose provides maximum support forsequence diagrams. Other tools lack features or do not support sequence diagrams. Forexample, support for redirection of message source and target may not be allowed or verylimited. It should be noted that the current version of Rose does not support the UML 2.0.

10

|it := |FindItem (|iid)

opt

|v := |VerifyStatus()

|c : |Controller

|CheckOut(|uid, |iid)

(a) An IPS for CheckIn Scenario

|UpdateStatus (|AVAILABLE)

|e := |VerifyStatus()

|u := |FindUser (|uid)

|it := |FindItem (|iid)

|e := |VerifyStatus()

|it : |Item

|CheckIn (|iid)

opt

|c : |Controller

(b) An IPS for CheckOut Scenario

|cu : CollectionUser

|ci : CollectionItem

|UpdateStatus (|CHECKEDOUT)

create

|AddNewLending (|ld)

|ci : |CollectionItem

|it : |Item

|u : |User

|ld : |Lending {new}

|cl : CollectionLend

opt

[|v = true]

[|e = true]

[|e = false]

Figure 9: IPSs for CheckIn and CheckOut Scenarios

One of the limitations of using Rose is that add-ins must be COM-compliant object which limitsone to MS/Windows.

The development of the tool benefited from the UML syntax used as a base of the RBML.First, drawing features provided by Rose can be used to build RBML specifications. Second,processing RBML specifications can be supported by the UML modeling tool through the providedAPI, because RBML specifications can be treated as UML models. Third, generated models canbe manipulated in Rose like other UML models built by Rose. For example, changing a class oran operation in an instantiated class diagram requires corresponding changes in related sequencediagrams. Such changes can be supported by Rose.

The core structure of RBML-PI is shown in Fig. 10. It consists of EventHandler, RBMLHan-dler, SPSHandler, IPSHandler, MetaConstraintsHandler, and OperatorInfo. EventHandler inter-cepts the event of clicking RBML menu and initializes RBML-PI. RBMLHandler initiates calls tothe SPSHandler and IPSHandler in sequence (because IPSs are dependent on an SPS) to generatea class diagram and sequence diagrams. SPSHandler and IPSHandler read metamodel-level con-straints specified in the pattern specification from MetaConstraintHandler. OperatorInfo supportsmetamodel-level sequence diagram operators (e.g., loop). For example, if a loop operator is definedin an IPS, RBML-PI instantiates the messages in the loop box until the condition defined in the

11

Figure 10: RBML-PI Class Diagram

loop is met. Currently only loop operator is supported by RBML-PI. The UML also provides otherpredefined operators (e.g., opt, alt) which are not currently supported by RBML-PI because of lackof support by Rose, the base tool of RBML-PI.

Pattern Author

Domain Engineering

Application Engineering

storebuild pattern

specifications

select pattern pattern imported

instantiate pattern

model generated

build modelfrom pattern

Application Developer

RBML PatternInstantiator

Pattern LibraryRose

Rose

Figure 11: Overview of Tool Use

Fig. 11 shows how RBML-PI can be used. A pattern author uses Rose to build RBML patternspecifications and puts them into a pattern library, which is a folder that contains pattern specifi-cations. An application developer chooses a pattern to use from the library and loads it into Rose.After loading, the application developer can further constrain the properties (e.g., realization mul-tiplicities) of the pattern specification to specify application-specific structural requirements. In thecurrent version of RBML-PI, modifications need to be made directly to the pattern specification.However, this can be done through an interface hiding the detail of the pattern specification fromthe application developer. The application developer does not have to know the RBML, but shouldhave knowledge of the pattern that s/he is using. The pattern specification is instantiated usingRBML-PI to generate UML models by binding the generated model elements to the applicationconcepts of the system. Application-specific elements that are not part of the pattern specification

12

may be added to complete the model. Pattern properties that are not specified, but found to benecessary during the application of the pattern are fed to the pattern author for adjustment.

5 Building Design Models from Pattern

This section demonstrates how RBML-PI can be used to develop models of a library system and avehicle rental system from the CICO pattern presented in Section 3.

5.1 CICO Pattern Specification

The CICO pattern specification is built in a package using Rose that contains an SPS and IPSs ofthe CICO pattern. The package is then exported into a pattern library. Fig. 12 shows the SPS ofthe CICO pattern. The SPS consists of roles that define domain concepts; registered user (User),collection of registered users (CollectionUser), item check out details (Lending), item (Item), itemdescription (Description), and checkin/checkout manager (Controller).

Figure 12: CICO SPS

Fig. 13(a) shows examples of the metamodel-level constraints for the ItemGeneralization rela-tionship role. They describe that the base metaclass of the ItemGeneralization role is Generalizationand there can be zero or more (0..*) generalizations that play the role. These constraints are usedto determine the generalization/specialization structure of items in an instantiated model.

Constraint templates in the RBML define model-level constraints. They can be instantiatedto obtain application-specific model constraints during instantiation. Fig. 13(b) shows the post-condition of the CheckIn behavior in Controller. They are used to generate post conditions for an

13

CheckIn operation. Currently RBML-PI provides limited support for instantiation of constrainttemplates that it simply copies constraint templates into an instantiated model.

Figure 13: CICO Constraints

Figure 14: CICO CheckIn IPS

Fig. 14 shows an IPS for a check-in scenario. It describes that the item is found in the item

14

collection, and its status is checked to determine whether it was checked out before. If the itemwas checked out, the return date is set and the status of the item is updated to available.

Figure 15: CICO CheckOut IPS

Fig. 15 shows an IPS for a check-out scenario. An instance of a Controller classifier invokesFindUser with the user ID uid to obtain a matching user u from a collection of users. The statusof the user is verified. If the user is allowed to check out the item, the requested item is retrieved.The status of the item is checked to determine if the item can be checked out. If the item canbe checked out, a lending record is created. The record is then added to a collection of lendings(CollectionLending), and the status of the item is updated to unavailable.

5.2 CICO Pattern Instantiation

An application developer imports the CICO pattern package from the pattern library into thecurrent project for instantiation. In Rose, the directory structure of the project is shown on theleft-hand side where the CICO package is imported under the Logical View folder as shown inFig. 16.

The instantiation process includes 1) generating an instantiated model using RBML-PI, 2) re-naming of generated model elements specific to the application, and 3) adding additional application-specific model elements to complete the model.

When generating an instantiated model, RBML-PI takes the metamodel-level constraints spec-ified in the specification to determine the structure of the model being generated. For example,RBML-PI uses the lower bound of the multiplicity in Fig. 13(a) to determine the number of gen-eralizations to generate. In this example, no generalizations are generated since the lower bound

15

is set to zero. Upper bounds are not used in instantiation, but they are used in checking whetherthe complete model still conforms to the pattern specification (conformance checking has not beenimplemented yet). For example, if the Item in Fig. 12 has a multiplicity of 1..3, the complete modelcannot have more than three Item classes.

Figure 16: Further Restiction of Pattern Property

Realization multiplicities can be further constrained by the application developer during in-stantiation, but cannot be weakened. If multiplicities are weakened, then pattern conformance isbroken. For example, if a library system requires at least two types (Book and Multimedia) of Copy,then the application developer may further restrict the multiplicity 0..* of ItemGeneralization to2..* as shown in Fig. 16. There might be situations where generated model constructs are notneeded. However, it is recommended not to remove them for the sake of conformance.

Fig. 17 shows a class diagram generated from the CICO SPS in Fig. 12. The following are someof notable points in the diagram:

• The class DescriptionG0 contains four instantiated attributes resulting from the multiplicity4..* (not shown) defined in the DetailOfItem structural feature role in Description in Fig. 12.The multiplicity is further restricted from the original multiplicity 1..*.

• The class ControllerG0 contains two instantiated operations CheckOutG0 and CheckOutG1

16

Figure 17: An Instantiated Class Diagram for a Library System

resulted from the multiplicity 2..* (not shown) defined in the CheckOut role in Fig. 12. Themultiplicity is further restricted from the original multiplicity 1..*.

• There are two specializations ItemGC0 and ItemGC1 created in the diagram as specified inFig. 16.

• The stereotype on model elements denotes the role from which they are instantiated. It canbe used to verify which model elements in the complete model map to which roles in theCICO SPS.

The sequence diagrams that are instantiated from the CheckIn and CheckOut IPSs are shown inFig. 18 and Fig. 19, respectively. Each instantiated message in the diagrams has its own activationbar because the Rose API does not support hierarchical message sequences.

The instantiation is not complete yet. The instantiated model elements have automaticallygenerated names, which need to be bound to application elements. For example, in the completedlibrary class diagram shown in Fig. 20, the instantiated model ItemG0 is bound to Copy in thelibrary system, and its specializations ItemGC0 and ItemGC1 are bound to Multimedia and Book.

The application developer may add application-specific model elements to the instantiated classdiagram. In Fig. 20, the Reservation class is added to provide reservation service, the name andaddress are added to maintain contact information of members. Other model elements that are notstereotyped are also application-specific. Fig. 21 shows a sequence diagram for check-in scenarioand Fig. 22 shows a sequence diagram for reservation scenario which is another form of check-out.

Another example of a vehicle rental system created by RBML-PI is given in Appendix A.

17

Figure 18: Instantiated CheckIn Sequence Diagrams for a Library System

Figure 19: Instantiated CheckOut Sequence Diagrams for a Library System

6 Related Work

Florijn et al. [3] demonstrate a tool developed in Smalltalk that supports generating programelements from a pattern template by instantiation, and integrating the instance with the existingprogram by binding program elements to roles in the pattern, and checking whether the resultinginstance meets the properties of the patterns. Structure of patterns is represented by a tree-like graph where a node represents program elements (e.g., class, association) which is associated

18

Figure 20: A Library Class Diagram

with roles that contain references pointing to program elements. Pattern descriptions are purelystructural, and little attention has been has been paid to behavioral aspects of patterns. Theirtechnique is based on a non-standard notation, and thus tools that support the notation have tobe developed.

Eden [2] proposes LePUS, a formal language to define patterns in terms of program properties,and demonstrates a supporting tool developed in PROLOG that applies patterns to programs andfinds patterns. A program is said to implement a pattern if the program conforms to the patternconstraints. LePUS focuses on structural properties of patterns and its application to programsrather than designs, which restricts to a particular programming language, Eiffel.

Pagel and Winter [12] present a metamodel for describing patterns using Object ModelingTechnique (OMT) [13], and a tool that implements the metamodel and a pattern repository. Theirapproach lies along the same line as ours in that they focus on the use of patterns to supportthe development of designs. Their pattern descriptions are templates which are similar to RMBLtemplates. However, their tool does not fully support instantiation of the templates.

Mapelsden et al. [10] propose the DPML, a visual modeling language, that provides a set ofconstructs (e.g., interface, method) to specify design patterns, and demonstrate a tool that allows

19

Figure 21: A Library CheckIn Sequence Diagram

to build UML design models and pattern specifications which is described in non-standard notationand to instantiate them. A pattern instance is a part of a UML object model that is instantiatedfrom a UML design model. Participants in a pattern instance are bound to objects in the objectmodel. In their approach patterns are defined at design level, and thus bindings are done at objectlevel. Like Florijn et al. using non-standard notation, the DPML requires exclusive tool supportfor its notation. No mechanisms are described as to how to specify behavioral aspects of patterns.

Rational Rose supports design patterns by generating a basic structure of a pattern with aminimum number of participants and their relationships. For example, applying the Observerpattern results in a structure of one client, one subject, and one observer. The client is associatedwith the subject class, and the subject is associated with the observer. In order to have an Observerrealization where a subject is monitored by multiple observers, the developer would have to eithergenerate the basic structure or create observers as many times as the number of observers needed.However, both ways are impractical. The first way requires removing duplicate clients and subjectsand reestablishing their relationships. The other way requires defining the observer properties (e.g.,observerState, update) every time an observer is added. Rose does not support behavioral aspectsof patterns.

7 Conclusions and Further Work

We have demonstrated a prototype tool, RBML-Pattern Instantiator (RBML-PI), that generatesUML models from RBML pattern specifications. The tool has proved the potential of the RBMLto support the development of tools that enables systematic use of patterns.

RBML-PI was used to generate UML class diagrams and sequence diagrams of a library systemand a vehicle rental system from the RBML specification of the CheckIn-CheckOut (CICO) pattern.The same examples were used in the work [7] where the models are built manually. It was very time-

20

Figure 22: A Library Reservation Sequence Diagram

consuming and tedious. Even a small change like changing a multiplicity for a classifier role from(1..*) to (2..*) was painstaking to find a room for the new classifier in the instantiated diagrams.Technically RBML-PI can generate models with any number of model elements using multiplicityconstraints where one can specify the number of instantiations. However, it has not been triedwith more than ten instantiations for a single classifier role because of the clutter that would havebeen created in the diagram which makes the diagram unreadable. In collaboration with NASA,we used RBML-PI to generate a model of a weather forecasting system using the Observer designpattern.

There is a lot of work left to be done. The following describes limitations of RBML-PI thathave to be removed in the future versions:

• RBML-PI only supports single-level hierarchies. A class structure might have a multi-levelhierarchy of generalizations, realizations, or a combination of both. For example, the V ehicle

hierarchy in Fig. 23 can have a second-level hierarchy by further specializing Leisure into Vanand Sedan. Such multi-level hierarchies should be supported.

• Limited support for OCL constraint templates. RBML-PI simply copies OCL constrainttemplates into the application model, which requires the developer to manually bound theparameters to model elements. We are investigating OCL tools that can be integrated withRose, so that the parameters are automatically bound to model elements as roles are boundto the model elements.

21

• RBML-PI does not check whether user modifications violate the pattern properties or not.RBML-PI lets users remove instantiated model elements, which may violate pattern con-straints. Ideally, RBML-PI should prevent the developer from making changes that do notconform to the pattern specification. We are also developing a model checker to verify theconformance of the resulting model.

• RBML-PI allows only one pattern to use. In practice, however, there are cases where multiplepatterns need to be used to solve a problem. One way to use multiple patterns is to applythem one by one. Another approach is to combine the patterns into one big pattern, andapply it once. Whether the overall effect of these approaches is the same or not is anotherresearch area. In our research, we use the first approach for simplicity.

• Limited support for interaction operators in UML 2.0. Currently RBML-PI supports onlyloop operator. Implementation of this single operator required a lot of efforts because thecurrent version of Rose does not support UML 2.0, and we had to build all utility functions.We expect that a near future version of Rose supports UML 2.0, and plan to add moreoperators in the next version of RBMP-PI.

• Currently RBML-PI only supports SPSs and IPSs. Support for SMPSs should be developed.

Subsequent work will focus on developing tools that can verify pattern conformance, and incor-porate patterns properties into models (pattern-based model refactoring).

References

[1] B. P. Douglass. Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Sys-tems. Addison-Wesley, 2002.

[2] A. Eden. Precise Specification of Design Patterns and Tool Support in Their Application. PhDthesis, University of Tel Aviv, Israel, 1999.

[3] G. Florijn, M. Meijers, and P. van Winsen. Tool Support for Object-Oriented Patterns. InProceedings of the 11th European Conference on Object Oriented Programming, volume 1241of Lecture Notes in Computer Science, pages 472–495. Springer-Verlag, 1997.

[4] R. France, D. Kim, S. Ghosh, and E. Song. A UML-Based Pattern Specification Technique.IEEE Transactions on Software Engineering, 30(3):193–206, 2004.

[5] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of ReusableObject-Oriented Software. Addison-Wesley, 1995.

[6] D. Kim. A Meta-Modeling Approach to Specifying Patterns. PhD thesis, Colorado StateUniversity, Fort Collins, CO, 2004.

[7] D. Kim, R. France, and S. Ghosh. A UML-Based Language for Specifying Domain-SpecificPatterns. Journal of Visual Languages and Computing, Special Issue on Domain Modelingwith Visual Languages, 15(3-4):265–289, June 2004.

22

[8] D. Kim, R. France, S. Ghosh, and E. Song. Using Role-Based Modeling Language (RBML)as Precise Characterizations of Model Families. In Proceedings of the 8th IEEE InternationalConference on Engineering of Complex Computer Systems (ICECCS), pages 107–116, Green-belt, MD, 2002. IEEE Computer Society Press.

[9] D. Kim, R. France, S. Ghosh, and E. Song. A Role-Based Metamodeling Approach to Speci-fying Design Patterns. In Proceedings of the 27th IEEE Annual International Computer Soft-ware and Applications Conference(COMPSAC), pages 452–457, Dallas, Texas, 2003. IEEEComputer Society Press.

[10] D. Mapelsden, J. Hosking, and J. Grundy. Design Pattern Modelling and Instantiation usingDPML. In Proceedings of the 40th International Conference on Technology of Object-OrientedLanguages and Systems (TOOLS), pages 3–11. ACS, 2002.

[11] H. Mili, A. Mili, S. Yacoub, and E. Addy. Reuse-Based Software Engineering: Techniques,Organization, and Controls. John Wiley & Sons, 2002.

[12] B.-U. Pagel and M. Winter. Towards pattern-based tools. In Proceedings of EuropLop,Munchen, 1996.

[13] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modelingand Design. Prentice Hall, 1991.

[14] J. Tessier and R. K. Keller. Manager-Agent and Remote Operation: Two key patternsfornetwork management interfaces. In Collected Papers from the PLoP’96 and Euro-PLoP’96Conferences, pages 4.8.1–4.8.14, Washington University Department of Computer Science,wucs-97-07, February 1997.

[15] The Object Management Group (OMG). Unified Modeling Language: Superstructure. Version2.0 Formal/05-07-04, OMG, http://www.omg.org, August 2005.

[16] J. Warmer and A. Kleppe. The Object Constraint Language, Second Edition. Addison-Wesley,2003.

23

Appendix: A Vehicle Rental SystemFig. 23 shows a car rental class diagram generated from RBML-PI using the CICO SPS. The

diagram describes a design in which customers rent vehicles. Unlike the Library system, the Userrole is bound to a generalization hierarchy: the Customer class is specialized by RegisteredCustomerand UnregisteredCustomer, and separate vehicle collections (CollectionTruck, collectionLeisure) arecreated for Truck and Leisure. Vehicle rental scenarios generated from the CICO IPSs are shownin Fig. 24 and Fig. 25.

Figure 23: Vehicle Rental Class Diagram

24

Figure 24: Vehicle Rental CheckIn Sequence Diagram

Figure 25: Vehicle Rental CheckOut Sequence Diagram

25