CIS224 Software Projects: Software Engineering and Research Methods

1. CIS224Software Projects: Software Engineering and Research Methods David Meredith d.meredith@gold.ac.uk www.titanmusic.com/teaching/cis224-2006-7.html Lecture 11 Brief introduction to the UML Specification (Based on UML Superstructure Specification, v2.0http://www.omg.org/cgi-bin/doc?formal/05-07-04 and UML Infrastructure Specification, v2.0 http://www.omg.org/cgi-bin/doc?formal/05-07-05)

2. UML 2.0, The Current Official Version • Official UML specification published by the Object Management Group (www.omg.org) • Currently upgrading all of UML to Version 2.0 • Specification is in four parts • UML 2.0 Superstructure (completed in 2004) • Defines six structure diagrams, three behaviour diagrams, four interaction diagrams and elements used in them • UML 2.0 Infrastructure • Defines base classes that form the foundation for UML 2.0 • UML 2.0 Object Constraint Language (OCL) • Allows for setting of pre- and post-conditions, invariants, and other conditions • UML 2.0 Diagram Interchange • Provides package for graph-oriented information, allowing models to be exchanged, stored and retrieved and then displayed in their original forms • Complete UML 2.0 language specification consists of Superstructure and Infrastructure • Most up-to-date specification available here: http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML

3. Conformance • UML can be applied in many different domains • Not all modelling capabilities required in all domains • Therefore UML has modular structure which allows selection of those parts that are of interest in a particular domain • If too much flexibility permitted, then likelihood of different tools supporting different subsets of the language • Can lead to interchange problems • Therefore definition of compliance is a compromise between modularity and ease of interchange • Small number of compliance levels defined • That is, tool may choose to comply with UML on one of only a small number of levels of detail and completeness • Increases likelihood of models supporting same or compatible subsets of the language • To provide modularity, UML divided up into language units

4. Language Units • Modelling concepts in UML grouped into language units • Each language unit provides means to represent a system from a particular perspective, e.g., • State Machines language unit: provides means to represent event-driven behaviour of a system • Activities language unit provides means to represent behaviour as a sequence of actions • Division of UML into language units means that user does not need to understand whole language before being able to parts of it effectively • Each language unit partitioned into increments, each one adding more modelling capabilities to the previous one • Makes language easier to learn and use

5. Compliance Levels • Set of modelling concepts in UML is partitioned into layers of increasing capability called compliance levels • Infrastructure defines two compliance levels: • Level 0 (L0) • Contains single language unit for modelling class-based structures • Metamodel constructs (LM) • Adds language unit to L0 for more advanced, class-based structures useful for designing metamodels like UML itself • Four compliance levels defined for UML Superstructure: • Level 0 (L0) • Contains single language unit for modelling class-based structures • Level 1 (L1) • Adds to L0 language units for use cases, interactions, structures, actions and activities • Level 2 (L2) • Adds to L1 language units for deployment, state machines and profiles • Level 3 (L3) • Complete UML. Adds to L2 language units for information flows, templates and model packaging

6. Package merge (UML Sup. Spec., p.107) • Package merge indicates that contents of two packages are to be combined • Similar to generalization in that element in source package adds the characteristics of an element with same name in target package to its own characteristics, resulting in an element that combines characteristics of both • Commonly used when elements in source package have same name as elements in target package and represent the same concept • Can be used to provide different definitions of a concept for different purposes • Start with common base definition, extend this definition in increments, with each increment defined in a separate merged package • Can obtain many different definitions of a given concept by selecting different sets of increments to merge • Package merge is an operation that takes the contents of two packages and produces a new package that combines the contents of the packages involved in the merge

7. Package merge • In a package merge, contents of package to be merged combined with contents of receiving package • Receiving package deemed to represent result of merge (cf. subclass represents aggregation of features of all its superclasses and not just increment added by subclass itself) • Reference to element in receiving package refers to result of merge rather than increment physically defined in receiving package • In diagram, • P1 and P2 define different increments of the same class, A • P2 merges contents of P1 (P2 is receiving package), so P1::A is merged into P2::A • P3 imports P2 so can define a subclass of A called B • P3::A represents result of merging P1::A into P2::A (not just P2::A) • P4 imports P1 so P4::A refers to P1::A (not result of merge) • P1::A is the merged increment • P2::A is the receiving increment • BUT P2::A also represents the result of the merge of P1::A into P2::A • Merged package is the package to be merged into receiving package (P1 in diagram) • Receiving package is package that conceptually contains result of merge before merge transformation has taken place (P2 in diagram) • Resulting package is package that contains result of merge afterthe merge transformation has taken place (also P2 in diagram) • Merged element is model element in merged package (P1::A) • Receiving element is model element in receiving package before merge has taken place(the increment P2::A) • Resulting element is model element in resulting package (i.e., after merge has taken place) (result of merging P1::A into P2::A)

8. Using packages to define UML compliance levels • Contents of each language unit defined by a corresponding top-tier package in the UML metamodel • Each language unit package contains a second-tier package for each increment within the language unit • Contents of a compliance level defined by set of metamodel packages that belong to that level • Compliance level builds on supporting compliance levels by means of package merge mechanism • Package merge allows concepts at one level to be extended with new features within the same namespace • Empty, core “UML” package defines namespace shared by all compliance levels • L0 defined by top-level metamodel shown at left • Basic package contains elementary concepts e.g., • Class, Package, DataType, Operation, etc.

9. Level 1 top-level package merges • Package UML assumed to include packages merged in at Level 0 and their contents • Each merged package may itself have other packages merged into it

10. Format of Superstructure Specification • Part I: Structure • Static, structural constructs (e.g., classes, components, nodes, artifacts) used in structural diagrams (e.g., class diagrams, component diagrams, deployment diagrams) • Part II: Behaviour • Dynamic, behavioral constructs (e.g., activities, interactions, state machines) used in behavioral diagrams (e.g., activity diagrams, sequence diagrams, state machine diagrams) • Part III: Supplement • Auxiliary constructs (e.g., information flows, models, templates, primitive types) and profiles (used for customizing UML for various domains, platforms and methods) • Each part organised into chapters according to capability • e.g., Part I (Structure) contains chapters on Classes, Components, Composite structures and Deployments

11. Summary • Four parts of UML 2.0 specification • Superstructure • Infrastructure • Object constraint language • Diagram Interchange • Conformance • Compliance levels • Language Units • Package Merge • Defining compliance levels with package merge • Format of specification