CIS224 Software Projects: Software Engineering and Research Methods

1
CIS224Software Projects Software Engineering
and Research Methods

• Lecture 11
• Brief introduction to the UML Specification
• (Based on UML Superstructure Specification,
  v2.0http//www.omg.org/cgi-bin/doc?formal/05-07-0
  4
• and UML Infrastructure Specification, v2.0
• http//www.omg.org/cgi-bin/doc?formal/05-07-05)

David Meredith d.meredith_at_gold.ac.uk www.titanmus
ic.com/teaching/cis224-2006-7.html
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_s
  pec_catalog.htmUML

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 P1A is merged into P2A
• P3 imports P2 so can define a subclass of A
  called B
• P3A represents result of merging P1A into
  P2A (not just P2A)
• P4 imports P1 so P4A refers to P1A (not
  result of merge)
• P1A is the merged increment
• P2A is the receiving increment
• BUT P2A also represents the result of the merge
  of P1A into P2A
• 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 after the merge transformation has taken
  place (also P2 in diagram)
• Merged element is model element in merged package
  (P1A)
• Receiving element is model element in receiving
  package before merge has taken place (the
  increment P2A)
• Resulting element is model element in resulting
  package (i.e., after merge has taken place)
  (result of merging P1A into P2A)

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