ModelElement. AssociationEnd. Relationship 2. Association. Class. GeneralizableElement. ModelElement

Transcription

1 A UML Prole for Rigorous Requirements Modeling Robert B. France, Department of Computer Science Colorado State University Fort Collins, Colorado. Jean-Michel Bruel Laboratoire TASC, Department of Computer Science Universite de Pau et des Pays de l'adour Pau, France. Abstract A prole is a mechanism that allows one to specialize the syntax and semantics of the Unied Modeling Language (UML) to a particular usage. In this paper we outline a prole that denes a specialization of the UML that supports precise modeling and rigorous analysis of software requirements. 1 Introduction The Unied Modeling Language (UML) [10] is a set of notations for modeling systems from a variety of views using object-oriented (OO) concepts. A deterrent to the use of UML for modeling the requirements of complex systems is the lack of support for rigorous semantic analysis. Rigorous semantic analysis of models requires precise semantics of the modeling notations. A number of groups have attempted to dene precise semantics for subsets of the UML (e.g., see [6, 8, 11]). The precise UML (puml) group 1 consists of researchers and practitioners that are actively developing precise semantics for the UML. Discussions at puml organized OOPSLA and ECOOP workshops provide evidence that a single semantics for the UML may not be suitable for all conceivable usages of the UML. This has given rise to a new view of the UML as a family of languages [3], in which each member is a specialization of the UML to a particular usage. This view of the UML can be supported by the notion of a prole. A prole is a mechanism currently under development in the Object Management Group (OMG) to better manage the evolution of the UML [1]. Given a core set of UML concepts, the intent is that a prole would provide the extensions and specializations needed to eectively use the UML in particular ways. In our work, a prole is minimally dened as follows: prole = specialization/extension of UML metamodel classes + semantics This work was partially funded by NSF grant CCR

2 The result of specializing or extending UML metamodel classes is a set of constructs that are tailored to the particular usage of the UML. Such specializations/extensions determine the grammar of the UML variant dened by the prole. A prole also needs to dene the semantics of the structures created using the constructs of the UML variant. If the UML variant is to be used to precisely specify and rigorously analyze systems then the semantics must be formal. A prole should also dene techniques for analyzing the models created using the UML variant. If the semantics are formal then such analysis techniques can be used to determine properties that can be inferred from the models in a rigorous manner. In this paper we outline a UML prole for precisely modeling software requirements. The UML variant dened by the prole is referred to as the Rigorous Requirements Modeling Language (RRML). The material presented in this paper should be viewed as illustrations of some of the more prominent aspects and not as a full description of the prole; space does not allow ustogive a full description of the prole. The semantics part of the prole is expressed in the formal notation Z [12], but any other suitable formal notation can be used. We use Z because it conveniently expresses the semantics in a formal manner and it allows us to rigorously explore the consequences of the semantics. Knowledge of Z is not a prerequisite to the use of RRML; the semantics can also be expressed in natural language. In section 2 we give an overview of the metamodel dening the RRML grammar. In section 3 we describe the RRML semantics, and in section 4 we outline how the semantics can be used to support rigorous analysis of RRML models. We conclude in section 5 with an outline of our plans to further develop RRML. 2 The RRML Metamodel A RRML specication consists of the following specializations of UML models: A requirements-level Class Diagram (R-CD), and a set of formalized Use Cases (UCs). In the RRML there is a strict separation of concerns: R-CDs model only the static relationships among requirements elements while UCs model only the required behavior of the system. We describe the structure of these models in the following subsections. 2.1 Requirements Class Diagrams A R-CD is a problem-oriented conceptual model of a system. An example of a CD for a clinical laboratory system [9] is given in Fig. 1. The following modeling elements are used to construct R-CDs: Class: In a R-CD, a class is represented by a UML class symbol that consists of a partition containing the name of the class, and another containing a list of attributes for the class. Type information for attributes may ormay not be shown in a R-CD. In a R-CD, class properties are expressed using only object-scope attributes; operations are not associated with classes in a R-CD. We agree with the developers of the Fusion method [2] that assignment of operations to classes can lead to design-level decisions. All attributes are public in a R-CD in the sense that they can be referenced in other parts of the requirements specication. Only two types of relationships can be represented in a R-CD: association and generalization relationships. Associations consist of two association ends: only binary Relationship: 2

3 Figure 1: The Clinical Class Diagram associations are allowed in a R-CD. We have been able to reduce cases involving higher-order associations (those with 3 or more association ends) to binary associations using aggregation. The restriction to binary associations simplies the semantics and has insignicant impact on the expressiveness of RRML. Constraint: Constraints on model elements are expressed in the Object Constraint Language (OCL) [13]. An outline of the metamodel for R-CDs is shown in Fig. 2 (attributes and constraints are missing from the diagram - these are essentially the same as those found in the Core package of the UML metamodel [10]). 2.2 Formalized Use Cases RRML Use Cases are used to specify required system operations. A system operation can be (1) one that is invoked by users (external agents) of the system, or (2) one that is not invoked by an external agent, but is required of the system (e.g., logging of banking transactions). The Use Case format used in RRML is based on Fusion Operation Models [2]. An example is given below: Operation : enter test request Description : Enter information about a sample and the test to be performed on it. Reads : supplied sample inf o, ::: Change : new sample, ::: Sends : labeler : send label inf o Pre-Condition : There is a patient report that has been selected as current, current patient report Post-Condition : A new test request has been created to hold information about the requested test type and sample; ::: 3

4 RCDmetamodel 1(1) ModelElement 1..* constrainedelement{ordered} * constraint Relationship 2 AssociationEnd Constraint type * 1 {ordered} connection 1 Generalization Association Class owner 1 GeneralizableElement feature * Attribute multiplicity changeability ModelElement Figure 2: The R-CD MetaModel The use of natural language is for presentation purposes only; there is an underlying formal semantics for UCs as outlined later in this paper. One can use the OCL to express the Pre- and Post-condition parts of a UC. 3 RRML Semantics In this section we give anoverview of the precise semantics for Class Diagrams and Use Cases and outline how they can be used to support rigorous analyses. 3.1 R-CD Semantics We interpret a R-CD as a characterization of valid, externally observable application states. An (externally observable) application state is an object structure that consists of all the objects and links that can be observed by external agents at some point in time. A R-CD precisely states the properties that valid (application) states must have. In this paper we refer to the valid states that possess the properties expressed in a R-CD as congurations. The objects and links in a conguration are those that have been created and not yet destroyed at some point in time. Our semantics is similar to the interpretation of Class Diagrams used in the Catalysis method, where a conguration is called a snapshot [4]. Our interpretation of attributes, associations and generalization/specialization varies from those used in the Catalysis approach; our interpretation is tailored to the use of Class Diagrams for requirements modeling. The semantics of R-CD constructs are expressed using Z schemata. A Z schema consists of two parts: a declaration part and a predicate part. Variables and their types are declared in the declaration, and constraints on the variables are expressed in the predicate part. The predicate part is expressed using predicate logic and set notations. Natural language descriptions of the more complex schemata presented in this paper will be given to aid readability. Semantically, a 4

5 Z schema denes the values that can be associated with the declared variables. We illustrate the formal semantics by applying it to parts of the R-CD shown in Fig. 1 in the following subsections Class Semantics The set of all objects that have the properties specied in a class is called the object space of the class. In a conguration, the set of all objects that belong to a class is called the conguration set of the class, and the objects in the set are referred to as conguration objects of the class. A conguration set is always a subset of the object space of the class; it contains the set of objects that have been created and not yet destroyed at some point in time. A basic class is one that is not a specialization (subclass) in a generalization hierarchy. A basic class is formally interpreted as a characterization of its conguration sets. Our interpretation of a R-CD class implies that constraints associated with classes in a R-CD are constraints on their conguration sets. For example, class multiplicity restricts the number of objects that can be in a conguration set of the class. An attribute is interpreted as a placeholder for non-object values. The semantics of attributes in a class is expressed in Z by an attribute schema. The attribute schema for SampleSlot is given below (the qlength attribute in the R-CD is restricted to a value less than or equal to 20): SampleSlot Attrs qlength : N qlength 20 The semantics of a basic class is expressed by a Z schema called an instance schema. An instance schema denes the properties that each object of the class must possess when it is present in a conguration. The declaration part of the instance schema consists of (1) a variable representing conguration sets of the class (referred to as the conguration set variable), and (2) a partial function, called the attribute function, that relates conguration objects to their attribute values. The predicate part consists of a conjunct that restricts the domain of the attribute function to conguration objects and any other application-specic constraints on conguration objects (expressed as OCL constraints in the R-CD). The instance schema for SampleSlots is given below: SampleSlot sampleslot : PSAMPLESLOT sampleslot attribute : SAMPLESLOT dom sampleslot attribute = sampleslot 7! SampleSlot Attrs In the above SAMPLESLOT is the object space of the class, sampleslot is the conguration set variable and sampleslot attribute is the attribute function Generalization Semantics In a generalization structure superclasses are specialized by subclasses. In a R-CD, a subclass inherits the attributes of its superclass and may dene additional attributes. Semantically, we interpret subclasses as subsets of the conguration set of the root superclass (each generalization structure has exactly one root superclass). How the root superclass object space is carved up can be constrained as follows: 5

6 Overlapping and Disjoint Subclasses: A set of subclasses is said to be disjoint if there are no objects that are instances of more than one subclass in the set. If there is at least one object that is an instance of more than one subclass in the set then the set is said to be overlapping. Abstract and Non-Abstract Superclasses: An abstract superclass is one in which each superclass conguration object is also a conguration object of at least one depicted subclass. A superclass that can have conguration objects that are not conguration objects of depicted subclasses is said to be non-abstract. Given a conguration, the set of conguration sets for all classes in a generalization structure is called the specialization conguration of the structure. A generalization structure in a R-CD is a characterization of its specialization congurations. A subclass instance schema has essentially the same form as a basic class instance schema. The attribute schema of a subclass consists of the superclass attribute schema, a schema dening the subclass-specic attributes, and constraints on attribute values. An example of a subclass instance schema is given below: Blood Sample blood : PSAMPLE blood attribute : SAMP LE blood sample 7! Blood Attrs 8b : blood (blood attribute(b)):sample quality =(sample attribute(b)):sample quality dom blood attribute = blood In the above Sample is the instance schema for the Sample class in the R-CD. The second conjunct in the predicate part ensures that the attribute function of Blood maps the sample part of blood object to the same sample that the attribute function of Sample maps the blood object to (i.e., the subclass object inherits attributes of the corresponding superclass object). Subclass instance scehmata are not enough to dene a generalization structure. One also has to dene relationships among root superclass and subclass conguration sets, for example, abstractness and disjointedness. A gen-schema characterizes the specialization congurations of a specialization structure. The declaration part of a gen-schema consists of the instance schemata of leaf subclasses (each leaf schema includes all the instance schema of its ancestors). The predicate part of a gen-schema contains conjuncts that express disjoint and abstractness properties (and other constraints expressed as constraints on the structure in the R-CD). The gen-schema for the Analyzer specialization structure is given below: AnalyzerConf ig RegularAnalyzer AdvanceAnalyzer regularanalyzer \ advanceanalyzer = ; regularanalyzer [ advanceanalyzer = analyzer In the above, regularanalyzer and advanceanalyzer are conguration sets dened in the included schemata, RegularAnalyzer and AdvanceAnalyzer, respectively. The conguration set variable 6

7 for the superclass Analyzer, analyzer, is also dened in this schema (the superclass instance schema is included in subclass schemata) Association Semantics A R-CD (binary) association is interpreted as a mathematical relation between the conguration sets of the related classes that satises the multiplicity and other stated constraints on the association. The mathematical relations characterized by an association is dened by a Z schema called an association schema in our Z formalization. Multiplicity and other constraints on an association are stated in the predicate part of its association schema. Space allows us to illustrate only the formalization of the semantics for general associations. The Z formalization of association semantics is expressed as an Association schema that consists of schemata for the associated classes and a function representing the association in the declaration part. The predicate part states the multiplicity and any other constraints on the association. The following is the association schema for the carried out on association (the Assoc-Gen generator is expanded and simplied in the predicate part): Carried Out On Sample T est carried out on : SAMPLE $ TEST carried out on 2 sample >! test The semantics of associations that appear at both superclass and subclass levels of a specialization structure requires special treatment because of the need to relate the associations. An example of such an association can be found in the Clinical System R-CD (see Fig. 1): the aggregation between Analyzer and SampleSlot also appears at the subclass level as an aggregation between RegularAnalyzer and SampleSlot. In a R-CD, these two aggregations are not independent: the aggregation at the subclass level must be a subset of the aggregation at the superclass level. The aggregation at the subclass level is said to be a specialization of the aggregation at the superclass level. The multiplicities on an association at the superclass level are constraints on the links that can be formed between objects of the superclass and objects of the associated class. Given that instances of subclasses are also instances of superclasses in our semantics, the multiplicities at the superclass level also constrain the links that can exist between subclass objects and objects of the associated class. A modeler can further restrict the links at the subclass level (as is done in Fig. 1). These restrictions must be consistent with the multiplicities given at the superclass level. The Z formalization of the semantics for the specialized aggregation shown in Fig. 1 is given below: In what follows an expression of the form Rel 2 (m::n)! (s::t)[cl1s : CL1;cl2s: CL2] is a shorthand representation for an association between class CL1 with conguration set cl1s and CL2 with conguration set cl2s (interested readers can refer to [7] for an expansion of this 7

8 expression). The class names CL1 and CL2 are omitted if they can be inferred from the context. SlotAnaly Analyzer SampleSlot slotanaly : AN ALY ZER $ SAMPLESLOT slotanaly 2 1! (1::)[analyzer; sampleslot] SlotReg SlotAnaly RegularAnalyzer slotreg : AN ALY ZER $ SAMPLESLOT slotreg 2 (0; 1)! 1[reganalyzer; sampleslot] slotreg slotanaly The Z formalization of the semantics of a R-CD is expressed in a conguration schema. The conguration schema is formed by including the association schemata and gen-schemata for the R- CD. Some renaming of variables may be needed if unique variable names were not used for dierent variables across the schemata. 3.2 Formalized Use Cases Formally, a Use Case is interpreted as a characterization of a set of tuples of the form (startconf ig; endconf ig; inputs; outputs), where startconf ig is a conguration in which the operation starts, endconf ig is a conguration in which the operation ends, inputs is a set of input values for the operation (possibly empty), and outputs is a set of output values produced by the operation (possibly empty). We use Z operation schemata to express the semantics of Use Cases. A Z operation schema denes an operation as a relationship between a before and after state, and as a relationship between inputs and outputs. Space does not allow us to give an example of a Z operation schema for a UC, but a detailed example can be found in [7]. 4 Rigorous Analysis The precise semantics of a R-CD can be used to infer structural properties of the modeled application. The need to establish these properties may arise out of the need to show that the model conforms to certain requirements, or out of challenges posed by reviewers of the models. Rigorous analysis may also be required to tackle questions for which answers are not explicitly given in the model. For example, in the Clinical system one may ask whether an aggregation between AdvanceAnalyzer and SampleSlot is implied by the aggregation between Analyzer and SampleSlot and if so what are the constraints on the aggregation. An understanding of R-CD semantics leads to the conjecture that the aggregation at the Analyzer level implies that an aggregation also holds between AdvanceAnalyzer and SampleSlot, where the multiplicity at the SampleSlot end is 1:: and the multiplicity atthe AdvanceAnalyzer end is 0; 1. This conjecture 8

9 can be formally stated as follows: AnalyzerConfig `8s:slots ((9a : advs super agg(s) =a)6 (8a : advs super agg(s) 6= a)) Using the semantics outlined in this paper one can show that this conjecture is valid. In the case of a textual notation such as Z, analysis is carried out by constructing proofs. Each proof involves applying a sequence of inference rules and axioms to the specication to derive the required conclusion. Just as with a textual notation, a proof technique for CDs can be thought ofas a transformation process [5]. Precisely dened graphical notations such R-CDs oer the possibility of diagrammatic transformations as a proof strategy. In this approach, graphical inference rules are used to systematically transform a class diagram to another class diagram which represents some conclusion to be proved. Provided that each inference rule results in a diagram whose properties are implied by the previous diagram, a complete proof sequence can be constructed. We have developed some inference rules for R-CDs that support this view of analysis. For example, Fig. 3 gives the rule for the demotion of a binary association in a R-CD. In the left hand side (LHS) model, elements of class A are linked to elements of class D. Given that objects of a subclass are also objects of its superclass, then elements of the subclass can be linked to objects of class D. The R-CD is complete in the sense that the association between subclass objects and objects of the class D are constrained only by the superclass constraints. Given that a superclass object is associated with p::q D objects, then each subclass object is also associated with p::q D objects. In turn, a D object is associated with m::n superclass objects. Some (including none) of the superclass objects can be B objects and some (including none) can be C objects. The number of B (C) objects associated with a D object can not exceed n. A(abs) D A(abs) D m..n p..q Transformation m..n p..q Rel Rel B disjoint C disjoint D p..q B C 0..n 0..n p..q D RelB RelD {RelB U RelD = Rel} Figure 3: Demotion rule 5 Conclusion The work presented here focuses on dening a semantics that is suitable for precisely modeling software requirements. We are currently developing automatable analysis techniques based on the semantics, in particular, we are developing inference rules for R-CDs to support diagrammatic reasoning, and implementing a prototype analysis subsystem in a CASE tool. References [1] Analysis and Design Platform Task Force. Requirements for UML proles. Technical Report ad/ , Object Management Group,

10 [2] Derek Coleman, Patrick Arnold, Stephanie Bodo, Chris Dollin, Helena Gilchrist, Fiona Hayes, and Paul Jeremaes. Object-Oriented Development: The Fusion Method. Prentice Hall, Englewood Clis, NJ, Object-Oriented Series edition, [3] S. Cook, A. Kleppe, R. Mitchell, B. Rumpe, J. Warmer, and A. Wills. Dening UML family members using prefaces. In TOOLS 32. IEEE Press, [4] D. F. D'Souza and A. C. Wills. Objects, Components, and Grameworks with UML: The Catalysis Approach. Addison-Wesley, [5] A. S. Evans. Reasoning with UML class diagrams. In Workshop on Industrial Strength Formal Techniques (WIFT'98). IEEE Press, [6] R. France, A. Evans, K. Lano, and B. Rumpe. The UML as a formal modeling notation. Computer Standards and Interfaces, 19, [7] R. France, E. Grant, and J-M. Bruel. FUZed: An UML-based rigorous object-oriented analysis technique. CSU technical report, Colorado State University, Fort Collins, Colorado, USA, February [8] Johan Lilius and Ivan Porres Paltor. Formalising UML State Machines for Model Checking. In Proceedings of UML'99, Springer-Verlag LNCS 1723, pages 430{445, [9] Ruth Malan, Reed Letsinger, and Derek Coleman. Object-Oriented Development At Work: Fusion in the Real World. Hewlett-Packard professional books. Prentice Hall, Upper Saddle River, NJ, November [10] The Object Management Group (OMG). Unied Modeling Language. Version 1.3, OMG, June [11] Gunnar Overgaard. A Formal Approach to Collaborations in the Unied Modeling Language. In Proceedings of UML'99, Springer-Verlag LNCS 1723, pages 99{115, [12] J. Michael Spivey. The Z Notation: A Reference Manual. Prentice Hall, Englewood Clis, NJ, Second edition, [13] J. Warmer and A. Kleppe. The Object Constraint Language: Precise Modeling with UML. Addison- Wesley,