Modeling Software Architectures in the Unified Modeling Language

More documents

Recommendations

Info

Modeling Software Architectures in UML • 9applied to model elements, effectively creating a new yet restricted formof meta class for constructing models. The semantic effect is as if the constraintsand tagged values were attached directly to those elements. Forinstance, interfaces are identified in class diagrams by attaching the stereotypename to class icons; among other things, the stereotypeconstrains an interface to declare only operations and no attributes.(4) Profiles are predefined sets of stereotypes, tagged values, constraints, andicons to support modeling in specific domains. The UML specification currentlydefines profiles for the Unified Process and for Business Modeling[Object management Group 2000].It is possible to express constraints on UML models using the Object ConstraintLanguage, which combines first-order predicate logic with a diagramnavigation language [Object Management Group 2000; Warmer and Kleppe1998]. Each OCL expression is specified and evaluated in the context of (the instancesof) some model element (referred to as self) and may use attributes andrelationships of that element as terms. The self instance may be a UML classifier(such as a class or an interface), or an element used by a classifier (such asan attribute, an operation, or an end element of associations), or another typeof model element. OCL also defines operations on sets, bags, and sequences tosupport construction and manipulation of collections of model elements in OCLexpressions. For instance, the operations defined within a class form a set thatcan be traversed in order to apply a constraint to each operation.The top of Figure 3 illustrates a simple OCL constraint on the instances ofclass Company (the self model element) expressed in terms of the cardinalitiesof its associations with Robot and Worker classes. Each association is identifiedby the name of the role filled by the class at the other end of the association. Bydefault, the role name is the name of the class itself with the first letter changedto lower case, and the role name evaluates to the set of all instances filling therole. Referring to associations and roles in this manner provides a means ofnavigating through the enclosing diagram and is therefore a key technique forconstructing constraints in OCL. The predefined property size is used to obtaincardinalities of collections of elements (in this case, the number of elementsfilling the robot role and the number of elements filling the worker role). Thus,the constraint says that the number of instances of Robots aggregated to aninstance of Company divided by the number of instances of Workers aggregatedto the instance of Company must be less than one-tenth.We further describe and illustrate OCL with constraints on the UML metamodel in the next section and in Section 5.2.3 The UML Meta ModelAs mentioned above, UML is a graphical language with semiformal syntaxand semantics, which are specified via a meta model, informal descriptive text,and constraints [Object Management Group 2000]. The meta model is itself aUML model that specifies the abstract syntax of UML models. For example, theUML meta model states that a Class is one kind of model element with certainattributes, and that a Feature is another kind of model element with its ownACM Transactions on Software Engineering and Methodology, Vol. 11, No. 1, January 2002.
10 • N. Medvidovic et al.Fig. 4. Simplified UML meta model (adapted from Object Management Group [2000]). Italicizedclasses are abstract (i.e., noninstantiable) classes. All classes are subclasses of ModelElement (exceptModelElement itself); this relationship is not shown.attributes, and that there is a one-to-many composition relationship betweenthem. Thus, in terms of Figure 2, the meta class Class is defined at the metamodel level, and instances of Class are the classes defined in software systemmodels at the model level. Figure 4 depicts the parts of the UML meta modelused in this paper.A powerful application of the extension mechanisms described in Section 2.2is to constrain the way the meta model is used in constructing system models.In particular, a stereotype can be defined for use with a particular meta modelelement and then applied to instances of that element in the model level(thereby constraining all instances of the stereotyped element at the user objectslevel of Figure 2). A stereotype thus essentially creates a new modelingconstruct, but one whose use still results in legal UML models. For example,suppose we wish to enhance the class diagram of Figure 3 to impose a designconstraint that a person may not be a composite element of another class—inother words, “a person must be the whole in any whole-part relationships.” Thisdoes not prevent a person from participating in containment relationships, onlycomposite relationships. In this example, composition would mean that employeescould not participate in any other aggregates and never work for anothercompany. The constraint may be stated formally in OCL as:Stereotype Person for instances of meta class Class--1-- If a person is in any composite relationship, it must be the composite, notthe composed.self.associationEnd.forAll(myEnd |myEnd.association.associationEnd->forAll(anyEnd |anyEnd.aggregation = composite impliesmyEnd.aggregation = composite))Note that the stereotype is defined for use with classes (i.e., instances of themeta model element Class) in system models, and thus we could apply thisACM Transactions on Software Engineering and Methodology, Vol. 11, No. 1, January 2002.
Page 1 and 2: Modeling Software Architectures in
Page 3 and 4: 4 • N. Medvidovic et al.Table I.
Page 5 and 6: 6 • N. Medvidovic et al.architect
Page 7: 8 • N. Medvidovic et al.Fig. 3.An
Page 11: 12 • N. Medvidovic et al.Fig. 5.T
Page 24: Modeling Software Architectures in
Page 27 and 28: 28 • N. Medvidovic et al.with the
Page 29 and 30: 30 • N. Medvidovic et al.Fig. 13.
Page 31 and 32: 32 • N. Medvidovic et al.Table II
Page 33 and 34: 34 • N. Medvidovic et al.self.par
Page 35 and 36: 36 • N. Medvidovic et al.placehol
Page 39 and 40: 40 • N. Medvidovic et al.(?A : Na
Page 43 and 44: 44 • N. Medvidovic et al.Rule2. U
Page 45 and 46: 46 • N. Medvidovic et al.componen
Page 47 and 48: 48 • N. Medvidovic et al.6.2 Arch
Page 49 and 50: 50 • N. Medvidovic et al.the “a
Page 51 and 52: 52 • N. Medvidovic et al.7.1.4 Ar
Page 53 and 54: 54 • N. Medvidovic et al.completi
Page 55 and 56: 56 • N. Medvidovic et al.MEDVIDOV

Modeling Software Architectures in the Unified Modeling Language

Create successful ePaper yourself

Delete template?

Save as template?