Component-based software development processes cur- rently lack ... software development. We propose ...... Houston and Norris use subsystems in the UML.
Software Component Specification Using Role-Based Modeling Language Dae-Kyoo Kim, Sudipto Ghosh, Robert France, Eunjee Song Computer Science Department Colorado State University Fort Collins CO 80523 {dkkim, ghosh, france, song}@cs.colostate.edu
Abstract
of software and has the potential to overcome this barrier. However, the UML notion of a component is its implementation that is deployable, and not its specification. Thus, the UML component is not appropriate for use at the specification level. There have been several efforts [2, 11] to overcome this barrier successfully. However, the reuse of component specifications has got little attention. Our work on reuse related research focuses on developing specification techniques that are capable of capturing properties of software components at the specification level for reuse. In this paper we present a technique that can be used to specify component requirements as sub-languages of the UML. The technique uses a notation called the metaRole Based Modeling Language (RBML) to describe component specification from the structural and behavioral perspectives [5]. A meta-Role Model consists of meta-Roles which are characterizations of the UML meta-model constructs. Thus, the meta-Role model characterizes a family of UML diagrams, that is, it defines a sub-language for a particular kind of UML diagram. Henceforth, we refer to meta-Roles as Roles. A component specification is defined as a package of Role Models, expressed using the RBML. Components can thus specified from a variety of perspectives using Role Models. Component designers make use of the Role Models to design component specifications as encapsulations of domain patterns. Using the Role Models for domain patterns is presented in [12]. In this paper, we extends usability of the Role Models for components specificaitons as encapsulations of domain patterns. An encapsualtion means that a component specification is a set of Role Models with crosscutting constraints. Component developers reuse the design experiences to develop application-specific components. Reuse of the design experiences occurs whenever the Role Models defined by a domain pattern is used to develop application-specific components. Since domain patterns are incorporated as specializations of the UML, our work is based on the UML meta-model. This allows component specifications to be
Component-based software development processes currently lack adequate notations for the specification of components and tool support for the reusability of component specifications. Although the UML has established itself as a widely accepted standard for specifying analysis and design models, and has powerful tool support, it is not adequate to support multiple viewpoints in component-based software development. We propose an approach to specify components using the RBML, a meta-Role Based Modeling Language. The RBML is a specialization of the UML. Role models described using the RBML are property-oriented characterizations of a family of UML models. Role models are composed of metaRoles that describe sets of properties. Using the RBML to specify components facilitates the development of tools for automating the process of reusing components in the software development process. Keywords: Role-Based Modeling Language (RBML), requirements, software component, specification, software reuse, UML design models.
1. Introduction Component-based software development (CBSD) processes are emerging as viable approaches for promoting reusability, productibility, scalability and cost-effectiveness in the development of large-scale systems. Currently components are viewed as reusable units of implemetation , which produces a restrict view of reusability at code level. While there has been a recognition to the need of component reuse above code level [10, 13], a major hindrance to reuse at a higher level is the lack of suitable notations and semantics. This in turn, makes it harder to develop techniques for reuse and composition of components at the design level. The Unified Modeling Language (UML) is a widely accepted object-oriented (OO) notation for specifying models 1
2.1. Static Role Models (SRMs)
incorporated into UML modeling tools that allow component developers to specialize the UML notation. Such tools need to provide access to their internal representations of the UML metamodel.
A SRM consists of roles and relationships between roles. In this subsection we describe SRM roles and the relationships that can exist between them.
We illustrate our approach by using the RBML to create a component-based specification of a Checkin-Checkout (CICO) application domain [12]. Applications within this domain include video-rental applications, car rental applications and library systems. Applications in this domain, provide services for checking in and checking out items. The applications need to maintain information about the items that can be checked in or checked out.
2.1.1 SRM Roles A SRM role characterizes a set of UML static modeling constructs (e.g., class, and association constructs). For example, a SRM classifier role (i.e., a SRM role with the UML metamodel class Classifier as a base) defines properties that classifier constructs (e.g., classes, interfaces) must have if they are to realize the role, while a SRM relationship role defines properties that UML relationship constructs (e.g., associations, generalizations) must have if they are to realize the role. The structure of a SRM role is shown in Fig. 1(a). The top compartment has three parts: a role base declaration of the form Base Role , where Base is the name of the role’s base (i.e., the name of a metamodel class); a role name declaration of the form /RoleName, where RoleName is the name of the role; and a realization multiplicity that specifies the allowable number of realizations that can exist for the role in a realization of the SRM that includes the role. The remaining compartments contain specifications of the properties that realizations of the role must possess. The second compartment contains metamodel-level constraints and the third, optional, compartment contains feature roles that determine a family of application-specific properties (e.g., properties represented by attributes and operations defined in application-specific classes). Metamodel-level constraints are well-formedness rules, expressed in the Object Constraint Language (OCL) [20], that determine the form of UML metamodel class instances that can realize the role. Specifically, the UML wellformedness rules and the metamodel-level constraints defined in a SRM role determine the form of its realizations. Feature roles characterize application-specific properties. Currently, only classifier roles have feature roles. A feature role consists of a name, a realization multiplicity, and a property specification expressed as a constraint template. The realization multiplicity specifies the number of realizations a feature role can have in a SRM realization. In this paper, we do not show feature role realization multiplicities if they are “1..*”. The constraint template of a feature role determines a family of application-specific properties expressed in terms of class attributes and operations. There are two types of feature roles: (1) Structural roles specify state-related properties that are realized by attributes or value-returning operations in a SRM role realization. An example of a structural role that can be realized by class attributes is given below:
We describe the RBML in Section 2 and illustrate its use by developing the CICO component specification in Section 3. We provide an overview of related work in Section 4, and conclude in Section 5.
2. RBML: The Role-Based Modeling Language A Role Model is a structure of roles, where a role defines properties that determine a family of UML model elements (e.g., class and generalization constructs). The type of model elements characterized by a role is determined by its base, where a role base is a UML metamodel class (e.g., Class, Generalization). For example, a role with the Class base determines a subset of UML class constructs. A UML model element conforms to, or plays (realizes) a role if it is an instance of the role’s base and has the properties specified in the role. Such an element is also called a realization of the role. A Role Model is thus a characterization of UML diagrams, and a Role Model realization is a model (e.g., a static structural diagram, sequence diagram) that consists of realizations of the roles in the Role Model. We have developed three types of Role Models: Static Role Models (SRMs) : A SRM is a characterization of a family of UML static structural models, that is, models that depict classifiers (e.g., UML classes and interfaces) and their relationships with each other (e.g., UML associations and generalizations). Interaction Role Models (IRMs) : An IRM is a characterization of a family of interaction diagrams (e.g., collaboration and sequence diagrams). Package Role Models (PRMs) : A PRM is a characterization of a family of models in a well-defined domain that are characterized by structural roles (e.g., classifier roles) and relationship roles (e.g., association roles) and package roles. PRMs can be packaged into a package role when the PRMs is used as a sub-system of a system. 2
Base Role Stereotype /RoleName
p
OCL metamodel constraints Structural role properties Behavioral role properties
(a) SRM Role Structure
Role realization multiplicity (not shown if it is "*")
/AbstractFactory
{self.oclTypeOf(Interface) or Constraints on form of base elements (self.oclTypeOf(Class) and self.isAbstract = true)} Feature roles
Role realization multiplicity
1..*
/ConcreteFactory
OCL metamodel constraint
{self.isAbstract = false}
Feature roles
/CreateProdBeh():[[Product]] {pre: true post: result = p and p.oclIsNew() = true}
/CreateProdBeh():[[Product]] {pre: true post: result = p and p.oclIsNew() = true} (b) Example of AbstractFactory SRM Role
1..*
(c) Example of ConcreteFactory SRM Role
Figure 1. Structure of a SRM Role /CurrentValue 1..1 {[[CurrentValue]] forAll(o | self.oclIsKindOf(Classifier). stereotype.name = "Subject" −> exist (s | s.attribute.type = o.attribute.type) and s.attribute.stereotype.name = o.attribute.stereotype.name)
/ObserverSRM
PRMs /ObserverIRM
(a) Package Role Structure
(b) Pacakge Role of Observer Design Pattern
Figure 6. Structure of a Package role A package role consists of five compartments. 1. The first compartment has the role base declaration as Package from the UML metamodel. 2. The second compartment contains the metamodel constraints that crosscut SRMs and IRMs that are de6
/CICOIn b1 /checkIn (iid : [[ID]]) b2 /checkOut (uid: [[ID]], iid : [[ID]])
/CompIn
/CICOComp
{self.stereotype.name = "realization"}
None /CICOSRM
/CICOOut b1 /findUser (uid : [[ID]]) b2 /findItem (iid : [[ID]]) b3 /findLending (l : [[Lending]]) b4 /addLending (l : [[Lending]]) b5 /updateStatus (s : [[Status]])
/CompOut {self.stereotype.name = "use"}
/CheckInIRM /CheckOutIRM
Figure 7. An abbreviated PRM of CICO Component erties that must hold across the Role Models are described in PRMs.
An architecture of component-based CICO system is shown in Fig. 9. The shaded circle is where the CICO component is plugged in. Note that the CICO component requires four interfaces, but the CICO component in Fig. 8 only provides two interfaces. As long as the component provides sufficient services that are required by the CICO system, interfaces can be shared. For example, if the CICOOut interface in Fig. 7 provides all the required services by CICOItemOut, CICOUserOut and CICODBout, then CICOOut can be shared for all these interfaces. It is natural to expect such an architectural mismatch unless the component is built for the particular system [8, 9].
An example of a detailed PRM for the CICO component is shown in Fig. 7 as a unit of composition. The PRM consists of two interface roles, one package role and two dependency roles. One interface is for incoming requests that the system context (rest of the system) makes to the component. This interface is connected to the component implementation by a realization dependency. The other interface is for outgoing requests that the component makes to the system context to fulfill incoming requests. For example, to perform the CheckIn request, the component makes the findItem, addLending and updateStatus requests to the context. This interface is connected to the component implementation by a use dependency. The component implementation includes one SRM and two IRMs for CheckIn and CheckOut scenarios. Details of CICOSRM, CheckInIRM and CheckOutIRM can be found in [12].
4. Related Work There are several methods for specifying components using the UML, including those of Cheesman and Daniels [2], Houston and Norris [11], and Liu and Cunningham [16]. Cheesman and Daniels use UML type models to describe components. Component interfaces are specified with associated classes and operations that include pre- and postconditions. Houston and Norris use subsystems in the UML to denote components. Their work presents a mapping from deployed components to subsystem to visualize the connection between them. Liu and Cunnigham propose a design by contract [17, 18] approach in which contracts are expressed using the Object Constraint Language (OCL). Their work just focuses on the specification technique with little concern for the reuse of specifications. Our work can complement the above effort by providing the property-oriented mechanism that enables reuse of design experiences. Formal methods have been developed to specify components. Lau and Ornaghi’s approach [14] introduces priori correctness on top of modular specification and verification
In order to use PRMs to describe component-based architectures, a folded form of Fig. 7 is shown in Fig. 8 as a composition unit. This form is purely for a structural view of the component-based architecture. In the folded form, interfaces are expressed as circles. All detailed properties in the dependencies and component implementation are hidden.
/CICOIn /CICOOut
/CompIn /CompOut
/CICOComp
Figure 8. A folded form of Fig. 7 7
/UIAuthOut
Presentation
/UISecurityOut
/UIAuth
/UISecurity Application Logic
/UserInterface
/UIItemOut
/UIItem
/UICICO
/AuthUIIn
/AuthUserOut
/ItemUIIn
/Authentication
/Item /UICICO
/ItemDBOut
/ItemCICOIn /ItemCICO
/AuthCC
/Security /SecurityUIIn /CICOItemOut
/CICOUIIn /UserAuthIn
/User
/UserDBOut
Storage
/DBUserIn
/UserCICO /CICOUserOut /UserCICOIn
/CICODBOut
/UserDB /DBUserOut
/CICO
/CICODB
ItemDB
/Database
/DBItemIn
Figure 9. Architecture of CheckIn/CheckOut System
5. Conclusions
[15] to provide an assembly guide for system prediction. Their work focuses more on system predictability in component specification. A major weakness in their work is that the approach is purely theoretical. Moreover, little attention has been paid to incorporating the approach into system development environments (e.g., through the use of supporting tools). Cox and Song [3] propose a component model with syntax and semantics defined. Although the syntax is well-defined, the semantics is insufficient to specify components properly. Their semantics only includes execution states of components. Semantics such as relationships between components is undefined.
We provided an overview of the RBML and outlined the approach to define Role Models as a specialization of the UML. We demonstrated how Role Models can be used to capture static properties of components and illustrated the approach using the CICO example. Currently we are developing techniques to describe behavioral properties using IRMs and meta-model level constraints. We plan to develop tools that incorporate the RBML and support automatic conformance checks to identify most suitable components from component libraries based on the component 8
specification.
[17] B. Meyer. Applying design by contract. In IEEE Computer, pages 40-51, October, 1992. [18] R. Mitchell and J. McKim. Design by Contract, by Example. Addison-Wesley, 2001. [19] C. Szyperski. Component Software: Beyond ObjectOriented Programming. Addison-Wesley, 1998. [20] The Object Management Group (OMG). Unified Modeling Language. Version 1.4, OMG, http://www.omg.org, September 2001.
References [1] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language User Guide. Addison-Wesley, 1999. [2] J. Cheesman and J. Daniels. UML Components: A Simple Process for Specifying Component-Based Software. Addison-Wesley, 2001. [3] P. Cox and B.Song. A formal model for component-based software. In IEEE Symposium on Visual/Multimedia Approaches to Programming and Software Engineering, pages 304-311, Stresa, Italy, September, 2001. [4] R. France, D. Kim, E. Song, and S. Ghosh. Patterns as precise characterizations of designs. Technical Report 02-101, Computer Science Department, Colorado State University, Fort Collins, CO, January, 2001. [5] R. France, D. Kim, E. Song, and S. Ghosh. metaRole-Based Modeling Language (RBML) Specification V1.0. Technical Report 02-106, Computer Science Department, Colorado State University, Fort Collins, CO, June, 2002. [6] R. France, D. Kim, E. Song, and S. Ghosh. Using roles to characterize model families. In Tenth OOPSLA Workshop on Behavioral Semantics: Back to the Basics, Tampa, FL, October, 2001. [7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1995. [8] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch or why it’s hard to build systems out of existing parts. In 17th International Conference on Software Engineering, Seattle, Washington, April, 1995. [9] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: Why reuse is so hard. In IEEE Software, 12(6), pages 17-26, December, 1995. [10] J. Han. An approach to software component specification. In International Workshop on Component-Based Software Engineering, Los Angeles, CA, May, 1999. [11] G. T. Heineman and W. T. Councill. Component-Based Software Engineering. Addison-Wesley, 2001. [12] D. Kim, R. France, S. Ghosh, , and E. Song. Using rolebased modeling language (rbml) as precise characterizations of model families. In The 8th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS 2002), Greenbelt, MD, December, 2002. [13] K. Lau. Is there a role for formality? In 4th ICSE Workshop on Component-Based Software Engineering, Component Certification and System Prediction, Toronto, Canada, May, 2001. [14] K. Lau and M. Ornaghi. A formal approach to software component specification. In OOPSLA Workshop, Specification and Verification of Component-Based Systems, October, 2001. [15] G. Leavens. Modular specification and verification of object-oriented programs. In IEEE Software, pages 72-80, July, 1991. [16] Y. Liu and H. C. Cunningham. Software component specification using design by contract. In The SouthEast Software Engineering Conference, Huntsville, Alabama, April, 2002.
9
