A Set Approach to Role Modeling

Luong T. Nguyen', Liping Zhao2, and Bill Appelbe'

'Department of Computer Science, RMIT, Australia

{ tluong, bill} @cs.rmit.edu.au

2Department of Computation, UMIST, UK liping @co.umist.ac.uk

Abstract

Most existing role modeling techniques use graphic notations for role description. There are a number of shortcomings with the graphic notations. First, they are ambiguous. Second they cannot effectively represent dynamic aspects of roles. This paper reports our initial effort on a formal notation for role description and modeling. The notation is based on the set operations. By using the set approach, role binding or unbinding to or from an object can be specified unambiguously by set union and set difference. We can also specifi role constraints so that roles can be bound or unbound sequentially, alternatively, repeatedly, or simultaneously. Similarly, roles of roles can be specified by set inclusion in relation to a new context. Role specialisation or generalisation can be described by set intersection of roles. Role compositions can be specified as set unions of part roles. In addition to the set notation, we have also adapted the formal method EMS to support static and dynamic description of roles. First, all classhole relationships are captured step by step. Second, all classhole structures are described by an Object-Z-like notation, class by class and role by role. Third, all system obligations are specified using Petri Net transitions, where pre and post conditions of transactions are expressed formally. Lustly, services and communications required for the objectshole instances involved in the system operations are described.

Keywords Role modeling, roles, object modeling, set, formal specification, Object-Z.

1. Introduction

Object-oriented modeling traditionally uses classification, generalisation, and aggregation as the basic modeling abstractions. While these are essential constructs for object structures, they are static. Particularly, in the classification of real world entities, the relation between an instance and its class is exclusive and permanent. This means that once an instance is created it belongs to only one class and for its lifetime. Object-oriented modeling, therefore, is appropriate only if real world entities to be modeled can be partitioned into disjoint sets of objects by their classes, which can be organised in hierarchies.

For applications, which are dynamic and encompass entities evolving over time or over contexts, the object-oriented modeling seems to be insufficient and has difficulties in modeling the real world. For example, Gottlob G. et. al. suggested the Person scenario [2]. A person may

158 0-7695-0918-5/00 $10.00 0 2000 IEEE

159

take on different roles: becoming a student, an employee, a department manager, a project manager, and so forth. Representing and maintaining evolving objects using class hierarchies is a difficult task. Each time a person takes on a new role, a new instance must be created, relevant information must be copied, references must be updated, and the obsolete instance must be deleted. The problem is even more serious if a person can take on several roles. In order to support an exclusive classification of objects, a separate class must be defined for every potentially possible combination of classes. These intersection classes are usually defined by means of multiple inheritance or composition. Either way, an explosion of class hierarchies can easily be encountered.

Role modeling is a complementary technique in the development of object-oriented modeling whose purpose to capture the dynamic aspect of objects in a system. It is based on the view that the dynamic nature of objects is largely due to their role changes [15]. Several approaches have been developed for role modeling. Gottlob G. et. al. [2] proposed to extend class hierarchies with role hierarchies whose nodes represent role types that an object classified in a root of role hierarchies may take on. At any point in time, a real world entity is represented by an instance in the root and an instance of every role type whose role it currently plays. This work also suggests a way to extend the Smalltalk language to implement the proposed model. A similar method, called object slicing, was used by Martin J. and Odell J. [9]. In this method a real world entity is represented by a conceptual object with its roles as specialised objects. The object slicing method is essentially a role hierarchy of height two where the conceptual object is in the root and the specialised objects are its descendants. One limitation in both of these methods is that the role composition has not been considered. Also lack of the composibility means that specialisation hierarchies may become exclusive and hard to maintain as the number of roles increases.

Anderson E. [l] looked at roles of objects in the context of activities that were transverse to classes of the involved objects. According to Anderson, a role model describes a particular activity in which objects are involved and how these objects interact during this activity. The role modeling process begins with choosing an activity, disregarding all irrelevant objects in the context. This is then followed up by identifying responsibilities for each object with respect to carrying out the activity. As a result, a joint description of the roles that can be played by objects during this activity and their relative positioning is specified. The method represents the behaviour of the role models using a Hare1 Statecharts-like approach [5]. The method can also produce a system-wide model through role model operations such as class composition, role model composition, and substitution.

Reenskaug T. et. al. developed the OOram (Object-Oriented Role Analysis and Modeling) method where a role model was considered as the basic object abstraction used in the technology dimension of the whole software development process [ 131. According to Reenskaug, a role is an archetypical representation of objects occupying a particular corresponding position in an object system. A role model describes the subject of the object interaction, the relationships between objects, the messages that each object may send to its collaborators, and the model information processes. Eight steps for creating a role model have been suggested in the OOram method. To avoid the fragmentary problem of role models, OOram uses role model synthesis to build complex models out of simple ones in a safe and controlled manner. Through role model synthesis, derived role models whose objects play multiple roles are constructed from several base role models.

Riehle D. used role modeling as an enabling technology for framework design and integration [14]. According to Riehle, a role type describes the view one object holds of another object. An object plays a role specified by a role type if it acts according to the type specification. He claims that a class defines a set of role types, the role type set, according to

160

which its instances may play a role. The class specifies how these role types combine in its instances. The set of role types of a class fully determines the roles an instance may play at run time. The union of all operations defined by the role types constitutes the class interface. Riehle considers a role model as a description of a (possibly infinite) set of object collaborations using role types. The description focuses on a single purpose of object collaboration. In a role model, each role type specifies the behaviour of one particular object with respect to the model’s purpose. Riehle also uses class models as sets of classes that relate to each other either by class inheritance or by object relationships defined by role types, to combine role models.

Significant work on role modeling has been done by Kristensen B. [6, 71. He considers that a role of an object is a set of properties, which specifies the object behaviour in a certain way expected by a set of other objects. An object without any roles is called an intrinsic object. Its methods are the intrinsic methods, whereas roles are said to be extrinsic. An intrinsic object has or plays a role when a role instance of that role is allocated to the object. Kristensen identifies six characteristics of roles: visibility, dependency, identity, dynamicity, multiplicity, and abstractivity. Similar to object-oriented modeling he applies three abstraction principles to the role modeling, with a graphical notation for roles to be used in object-oriented analysis and design. The graphical notation supports the description of both static and dynamic aspects of the role modeling.

However, apart from Kristensen who seeks to represent run-time role dynamics, most existing role modeling approaches are mainly for system analysis and design purposes. Our work attempts to investigate a formal representation method that can be used to specify role behaviour in system implementation. We share the same view as Kristensen on the role concept and its characteristics. The main difference is however that we look into a set approach to role behaviour specification and adapt a formal method to specify a system with objects and roles. This paper presents our initial effort on a set approach to role modeling and specification. The rest of this paper is organised as follows. Section 2 describes the basic role concept and its characteristics from the set viewpoint. Section 3 describes how most of the important concepts of role modeling such as bindinghnbinding roles to/from objects, roles of roles, roles specialisation, role composition can be viewed based on set theory. A notation for those concepts is also proposed in this section. Section 4. presents the way we adapt the EMS method [lo, 11, 121 for role modeling. Finally, section 5 summarises our approach and proposes further work.

2. Role concept from set viewpoint

“A role of an object is a set of properties, which are important for an object to be able to behave in a certain way expected by other objects” [7]. From this definition, it is clear that a role always adheres to an object (“a role of an object”), it never exists alone. We denote role R of object 0 as Ro. Furthermore, a role is a set of properties. This set may be empty. Also, there may be several such sets associated with the same object. In addition, the motivation for the role is the expectations of the object behaviour as viewed by other objects. This means that other objects want to see the object in a certain restricted way, and probably, can only see it in this way.

An object is associated with a set of roles. An object is called an intrinsic object that has or plays a role when a role instance of that role is allocated to the object. An object with any set (or bag) of role instances bound to it is referred to as a subject [7]. As such, an intrinsic object itself is a subject because it has the empty set of role instances bound to it.

161

Kristensen suggested the following characteristics for roles [6]: (i). Visibility; (ii) Dependency; (iii) Identity; (iv) Dynamicity; (v) Multiplicity; (vi) Abstractivity.

A role is a set of properties. If a property p is included in role R (or role R has a property p) we denote p E R. Otherwise, if p is not included in role R (or R has not p) then we denote p e R.

Two roles R1 and R2 are equivalent if they include the same properties.

Role R1 is said to be included in role R2 (R1 c R2), or role R2 includes role R1 (R2 2 Rl) , if Vp E R1 p E R2. Accordingly, for all objects playing role R1 and role R2, and thus forming subject S1 and subject S2, we say that subject S1 is included in subject S 2 (S1 c S2), or subject S 2 includes subject S1 (S2 2 S l ) .

Role R1 is equivalent to role R2 if and only if role R1 is included in role R2 and vice versa.

A role with no properties is called empty role and is denoted by 8. Thus, an intrinsic object

Two roles R1 and R2 are said to be compatible if there can exist an object playing two these

Let R1 and R2 be compatible roles. Role union is defined as

Let R1 and R2 be compatible roles. Role intersection is defined as

Let R1 and R2 be compatible roles. Role difference is defined as

We denote [WO as a set of roles currently played by object 0 and

R l = R 2 w ( V p ~ R1 * P E R ~ ) A ( V ~ E R 2 . p ~ Rl)'

(R1 c R2) A (R2 c R1) w R 1 = R2

is a subject with the empty role.

roles simultaneously.

R l u R 2 = { p I p ~ R l v p ~ R 2 )

R l n R 2 = ( p I p ~ R ~ A ~ E R2)

R l R 2 = { p I p ~ R l ~ p e R2) as a bag of

corresponding role instances bound to object 0. Therefore, RO E [WO means that the object 0 currently plays the role RO and the object 0 has at least one role Ro instance (ro) bound to it.

We denote WO is the set of all possible roles that can be played by the object 0. Therefore, Ro: WO means that Ro is a (potential) role of object 0. Statically looking at WO we can see that for every pair of roles Rlo, R20: WO, there exists one of the following constraints between them:'

Rlo + R20 : object 0 playing role R l o must always play role R20 (but not necessarily the other way). This fact can be expressed as R l o E [WO * R20 E [WO. We say that the role R l o implies the role R20. Rlo t) R20 : object 0 playing role R l o must always play role R20 and vice versa. This fact can be expressed as R l o E [WO w R20 E [WO. We say that the role R l o couples with the role R20.

Rlo 1 R20 : object 0 playing role R l o never plays role R20 and vice verse. This fact can be expressed as (Rlo E [WO * R20 e [WO) A (R20 E [WO * RIO e [WO). We say that the role Rloprohibits the role R20.

Rlo 0 R20 : object 0 plays roles R l o and R20 independently. No constraints impose on the object 0 playing roles R l o and R20. We say that the role R l o is independent of (or does not care about) the role R20;

' In 2 notation, a general form applied for universal and existential quantifiers is as follows: [9] W declaration I constraint *predicate (In this notation I constraint may be omitted).

This is analogous to (static) role constraints described in [14].

Thus, two roles are compatible if and only if they do not prohibit each other (one does not prohibit the other).

Suppose that object 0 plays role Ro (Ro E Ro). According to the above definition, there exists an instance r, of role RO (ro: Ro) currently bound to the object 0. A subject formed by the object 0 with the role instance ro is called a corresponding subject (to the object 0 and the role &).

A qualijied role of an object is a role, which can be played by the object multiple times simultaneously. Accordingly, for qualified roles there may be multiple corresponding subjects. As we will see in the next sections, qualified roles will be represented by double circles in the ClasdRole Relationship model and by double dash schemas in the ClassRole Structure model.

We denote Xc as a set of all possible roles that can be played by every instances of class C. Consequently, R: 31‘ means that VO: C R E X o , and we say that R is a role for the class C.

: 1 name CompanyName

3. Using the set notation for role modeling

above3. We illustrate the set approach to the role modeling using the Person example described

Company

3.1. Role binding and unbinding

Suppose instances of the class Person take on a role Employee in relation to instances of class Company (for simplicity we assume that a person works for only one company). We can describe this binding process graphically as in Figure l., where classes, as in the UML, are represented by rectangles, and roles - by circles.

This binding process can be specified by the set union operation. Suppose Employee is a role of an object aPerson: Person, but not currently played by aPerson. We have Employee: XaPerson, Employee (WaPerson, binding the role Employee to the object aPerson means that Reerson U {Employee}. At the instance level we have 3anEmployee: Employee R’a~enon = Reenon U {anEmployee), where RtaPenon is a bag of role instances assigned to aPerson after the binding.

Figure 1. Binding Employee role to instances of class Person

Similarly, unbinding roles from objects can be specified by the set difference operation. Suppose Employee is currently played by aPerson, Employee E RaPerson, unbinding the role Employee from the object aPerson means that Raperson \ {Employee}. At instance level we have VanEmployee: Employee f % ’ a ~ ~ ~ ~ ~ = Rapenon \ { anEmployee)

The Person example was initially used in [2].

163

Bindinglunbinding roles to/from objects can occur independently, sequentially, alternatively, repeatedly, or simultaneously. To express the constraint that role Rlo has to be taken on by an object 0 in the existence of the role R20 for all its lifetime we include the following assertion in the specification of the Rlo role: Rlo -+ R20

Suppose Rlo E WO and R20 E WO. Rlo is played by object 0 simultaneously if and only if

Let b be a role of object 0 (b E WO), p(x) is a predicate. The object 0 taking on the role R0 when p(x) is true can be expressed formally as p(x) ~ [ W ’ O = [WO U {b}

Suppose Rlo, R20, ..., Rno are roles of object 0 (Rlo E 30, R20 E WO, ..., Rno E WO). The fact that Rlo, R20, ..., Rno must be taken on by the object 0 sequentially may be specified as Rlo .-+ R20 .--t ... -* RQ.

Let b be a role of object 0 (b E WO). The fact that Ro must be taken by object 0 repeatedly n times can be denoted as RZ’. Thus, b(”) = RO ---* Ro -* . . . .--* RO (n times). If RO is a qualified role then lifetimes of RO Occurrences may overlap, otherwise they are distinct intervals of time.

Rlo t) R20.

3.2. Roles of objects and roles of roles

Suppose that Rlo, R20 E Ro and Slo, S20 are arbitrary corresponding subjects. R20 is a role of Rlo means that Slo E S20. We denote the fact that the role R20 is a role of role Rlo as R20 rof RIo. Roles of roles occur when new contexts, new activities, or new relationships appear (are considered) on the ground of the previous roles’ contexts, activities, or relationships. From another perspective, when an intrinsic object takes on a role, we have a role of object, and when a subject takes on a role, we have a role of role. Typically, when an object plays a new role on the ground of the previous role’s context, and hence the new role is the role of the previous role, the object gets additional properties to fulfill the expectation in the new context.

For example, ProjManager is the role of objects from the class Person and the role of the Employee role in relation to Project. This relation between roles can be captured graphically in Figure 2.

projName skills responsibilities

Figure 2. ProjManager is role of the Employee role

In addition to the properties of the role Employee, the role ProjManager has supplementary properties such as projName, skills, responsibilities.

Obviously, R20 rofRlo j R20 + Rlo. In other words, if role R20 is role of role Rlo then the lifetime of role R20 is included in the lifetime of role Rlo. From the Person example it can easily be seen that role Employee must be taken before (or at the same time) of role ProjManager and exists for all duration while role ProjManager is being played.

164

1 ~

3.3. Role specialisation

University

Suppose that RIo, R20 E [WO. If Rlo and R20 are in the same context and Rlo c R20 then R20 is said to be a specialised role of Rlo and Rlo is a generalised role of R20. Let’s take an example of a person playing role Student in relation to a university. In the same relation to the university, this role Student can either be Overseastudent or Localstudent (but not both). Both Localstudent and Overseastudent are Student. The only difference is that Localstudent has data hecs liability as an extra property and Overseastudent has additional properties: countly and tuitionFee. These specialised roles can be pictured as in Figure 3.

Specialisation of roles is an abstraction process applied to the role concept. It reflects the ’is a’ relationship between roles. A specialised role is a generalised role, and probably, plus some more properties. We denote the fact that role R20 is a specialised role of Rlo by R20 isa Rlo .

R20 + RIO. In other words, if role R20 is a specialised role of role Rlo then R20 implies Rlo. In our Person example, taking on the Overseastudent role aPerson plays the role Student as well.

Obviously, R20 isa Rlo

Figure 3. Localstudent and Overseastudent are specialised roles of Student

Classes with roles per se may be specialised as well. A role for a class is also a role for any subclass of the class, but generally not vice versa. Class Person can be specialised to two subclasses: Male and Female. The role Employee for class Person is also the role for any subclass: Male or Female.

3.4. Role composition

Suppose that Rlo, R20, R30 E X0. Role R30 is said to be a composite role of Rlo and R20 (and Rlo, R20 are part roles of R30) if (R30 + Rlo) A (R30 + R20) A (Rlo U R20 E R30). In other words, role R30 is a composite role of roles Rlo and R20 if taking on the role R30 object 0 also takes on both roles Rlo and R20, and role union of Rlo and R20 is included in

Role Professor is a composite role of roles Lecturer and Researcher. A person taking on a role Professor actually acquires both roles Lecturer and Researcher. Obviously, all properties of roles Lecturer and Researcher are included in the role Professor. This composition of roles can be illustrated graphically as in Figure 4.

R30.

165

ResearchF'roj ResearchF'roj

Figure 4. Professor is a composite role of Lecturer and Researcher

4. Role modeling process

Along with the means provided by the set theory, this research also adapts the formal method EMS [ 10, 11, 121 to support static and dynamic description of roles. First, all class/role relationships are captured step by step in the Class/Role Relationship model. This process supports the idea of separation of concerns, which omits all irrelevant classes/roles in the context. Second, all classes/roles structures are described in the Class/Role Structure model by Object-Z-like notation [4], class by class and role by role. Third, all system obligations are specified in the System Obligation model using Petri Net transition [3], where pre and post conditions of transactions are expressed formally. Lastly, services and communications required for the objectshole instances involved in the system operations are worked out and collected in the Object-Z** model. What we'll end up with is the complete specification of the system.

4.1. ClasdRole Relationship model

The purpose of this model is to capture graphically class and role relationships we have in the system. In particular, they are: (i) the classes we have in our system, and their properties; (ii) the relationships among the classes (inheritance, aggregation, association); (iii) the roles for the classes with their properties; (iv) the kinds of other objects and their relationships present in the contexts where roles are being taken.

Classes, relationships, and cardinality are represented using the UML notation. Roles are represented by circles, qualified roles -by double circles with their names and properties also included in them.

This process can be done step by step to support the idea of separation of concerns. For a large system, it's hard to capture all class and role relationships at once.

For the Person system, the Class/Role Relationship model includes figures 1 ,2 ,3 ,4 and some others.

4.2. Class/Role Structure model

The purpose of this model is to specify formally (in Object-Z-like) datu structure of classes and roles involved in the system. This step makes use of the Class/Role Relationship model, and involves three major activities. First, the relationships explicitly identified in the previous model are represented as class attributes. Second, the roles that can possibly be bound to objects of each class are specified. Third, a new class is set up to represent the whole system,

166

i.e. an instance of this class is the whole system. This class serves two purposes: (i) it clearly describes what we actually have in the system; (ii) it transparently specifies the state of the system. A decision that must be made at this stage is what properties the system object should have. The decision would determine the access entry points and access paths available to access objects in the system.

Identifying static and dynamic constraints is also very important in this step. Especially, the constraints between roles for each class should be specified clearly. The satisfaction of such constraints is critical for the proper functioning of the system.

In this model, classes are represented as schemas with solid lines; roles are represented as schemas with dash lines, and qualified roles - double dash lines.

Suppose that the following types are given: [SSNO, NAME, DATE, PHONE, UNIVERSITY, STID, COURSE, DEPARTMENT, PROJNAME,

SKILL, RESPONSIBILITY, COUNTRY, SUBJECT] The ClassRole Structure model of the Person System has the form as in Figure 5.

I I I

..... . I !

- Personsystem

addRole I--- . . . . . . . . . .

..........

Figure 5. Class/Role Structure model for the Person System

167

4.3. System Obligation model

The System Obligation model describes for each operation exactly what the system has to fulfill. The description is given in terms of a special kind of Petri Net, which is referred to as "System Obligation Nets" (whose formal semantics is given in terms of Coloured Petri Nets). This is based on and widens the use of Petri Nets for object oriented modeling as proposed by Dillon and Tan [3].

T

ssNo?: SSNO role?: 3-

preT I* Person intrinsic object with sslio? exists; Person object not playing role prohibited by role? *I

3p E persons p.ssNo = ssNo?

postT I* The Person object plays the role? and all roles implied by role? *I

3p E persons, 3r. role? p.ssNo = ssNo?

Vrp: R, role? 7 R, 3 r, e R',= R,U (1)

VR, E (R: &, I role? + R) 3,: R, AI, E Rp

Figure 6. System Obligation Net for addRofe operation

The System Obligation Net specifies unambiguously: (i) what input the system receives from the environment; (ii) under what condition the system will allow the operation to go ahead; (iii) what changes the system may undergo; and, (iv) what output the system will send back to the environment.

All these details can be precisely specified on the basis of the formal description of the objects, role instances and their structures as given in the ClassRole Structure model.

Two major activities are involved in this step. First, the operations of the system have to be identified and listed. It is sufficient to consider all the update system operations and some predefined queries (in some systems, ad hoc queries are unavoidable and cannot be completely listed). Then, for each system operation, a System Obligation Net is drawn. The collection of all such Obligation Nets forms the complete System Obligation model.

The issues of encapsulation, responsibilities and interactions among the objects/roles will be ignored in this step. They will be taken into account in the next step, where the complete role model of the system is being built.

We demonstrate the update operation addRoZe of the Person system in Figure 6.

4.4.Object-Z** model

The aim of this model is to specify all the classhole methods and instance methods of the classes/roles involved in the system. It is written in Object-Z-like, which is Object-Z with some simple syntactic modifications to suit for role description [4].

168

- takeRole

role?: XPerson

Vr: Rlhis role? -, Rthis * r E R,,,,, b lookUp(role?) b PsnRole!.init() R ' ~ $ = Rhir U (psnRoleIns!) VR E (R: Xhi, I role? + R ) b takeRole(R)

3.

4.

Figure 7. Person instance method takeRole(role?)

It can be seen from the specification of the method Person.takeRole(role?) in the previous step that aPerson must have an access to a lookUp(role?) function, which retrieves the role? in Xperson That PsnRole! then invokes some means to create its instance. init() method is one of these means of the PsnRole!. It is fully corresponds to our definition of role and role instance.

169

5 . Then, the newly created psnRoleIns! is added to the bag of instances of theperson,

6. Last, the method calls itself for each of the implied roles. h i s .

We have just described fully how we identify all the services and interactions (or simply speaking, all the methods) required for the system operation addRole.

Once this step has been carried out for all the system operations, we simply collect all of them together, class by class, role by role. Ultimately, we would end up with the complete specification which describes completely and precisely all the classes/roles structures and methods.

5. Conclusion

This work extends exiting role modeling techniques with a formal specification. In particular, this work attempts to investigate the set notation for role behaviour specification. Other description methods have also been sought and incorporated, such as EMS and Object- Z. The proposed set notation, in fact, provides facilities to specify clearly and unambiguously all static and dynamic aspects of a system being modeled. Using the set notation the proposed modeling process steps further to shorten the gap between the conceptual role model and implementation. While this work has shown that the set notation provides rich semantics for role modeling, the extensive use of the mathematical symbols for role modeling may prevent its real world application. As we refine our work, a simple, easy to use notation will be sought.

Our future work will also include validating the proposed method and mapping the role models into an implementation language.

References

[ I ] E. Anderson, “Conceptual Modeling with Objects. A Role Modeling Approach”. PhD. Thesis. Department of

[2] G. Gottlob, M. Shrefl, and B. Rock, “Extending Object-Oriented System with Roles”, ACM Transactions on

[3] T. S. Dillon, P. L. Tan. “Object Oriented Conceptual Modeling”, Prentice Hall, Australia. 1993 [4] R. Duke, G. Rose, “Formal Object-Oriented Specification Using Object-Z, Macmillan, 2ooO. [5] D. Harel, “Statecharts: A Visual Formalism for Complex Systems”, Science of Computer Programming, Vo1.8,

[6] B. Kristensen, “Object-Oriented Modeling with Roles”, Proceedings of the 2nd Intemational Conference on 00

[7] B. Kristensen, 0sterbye K. Roles: “Conceptual Abstraction Theory & Practical Language Issues”, Theory and

[SI D. Lightfoot, “Formal Specification Using Z”, THE MACMILLAN PRESS LTD, 1991. [9] J. Martin, J. Odell, “Object Oriented Analysis and Design”, Prentice Hall, Englewood Cliffs, N.J., 1992 [IO] K. Nguyen, “Formal Specification of Object Oriented Databases applications using Object-Z, Technology of

Object-Oriented Languages and Systems TOOLS 18, Prentice Hall, Sydney, Australia, 1995. [ 1 I] K. Nguyen, “Teaching Object Oriented System Development Using Formal Notation and Smalltalk”,

Technology of Object Oriented Languages and System TOOLS 21, Prentice Hall, Sydney, Australia, 1996. [I21 K. Nguyen, “A Practical Formally-Based Modeling Method for Object Oriented Information Systems”,

Intemational Conference on Object Oriented Information Systems, Brisbane, Australia, 1997. [I31 T. Reenskaug, et. al., “Working with objects”, Manning Publication Co. Greenwich. 1996 [I41 D. Riehle, T. Gross, “Role Model Based Framework Design and Integration”, Proceedings of the OOPSLA’98.

[I51 L. Zhao, T. Foster, “Modeling Roles with Cascade”, IEEE Software, Sep/Oct. 1999.

Computer Science, University of Oslo, 11/1997.

Information Systems, 14(3), pp. 268-296, 1996.

No.3, 1987, p.231-274.

Information System, Dublin, Ireland, 1995.

Practice of Object System (TAPOS), 1996.

ACM Press, 1998, p. 117-133.