The superstructure of the UML, which is our primary interest, offers standard modeling concepts that enable anyone who understands the superstructure, to create models that other people who understand the superstructure will stand a good chance of interpreting properly.

---

Infrastructure

• The infrastructure doesn't focus on the UML itself; instead it describes the way in which the UML is described, and the way that description is structured into packages and profiles. For example, the most basic elements of modeling are represented core UML and additional layers and profiles tailor existing metamodels toward specific platforms, such as C++, Java, CORBA, or EJB, or domains such as real-time, business objects, or SW process modeling. This layering helps organize the UML, and it helps incremental learning as well.
  
• A CASE tool can store the information gleaned from its diagrams in a nice sensible schema (logical database structure). What kinds of elements (what tables?) would the database need? That's what the infrastructure tries to tell you, the tool builder, as formally as possible.
• The infrastructure tries to ensure that the way the UML is described - the metamodel - is itself compatible with other modeling language descriptions.
  

  The Core packages

   

  The role of the common Core
   

• The OMG has other metamodel called the Meta-Object Facility (MOF) - the metamodel of the UML. The languages in which languages are expressed are often called metalanguages. The infrastructure of the UML has metamodels of metamodels. A common and helpful picture is the "M n " picture of the layering. Look at Modeling layers (metamodels and meta-metamodels).
  
   
• All of the UML metamodel is instantiated from meta-metaclasses that are defined in the InfrastructureLibrary.
• The UML metamodel imports and specializes all metaclasses in the InfrastructureLibrary.
• You do not need to learn the infrastructure - only UML models relevant to your projects, unless you want to be involved in the OMG UML standardization process.
   

---

Object Constraint Language

• The Object Constraint Language, or OCL, is a textual, formal, expression language for rigorously writing constraints using identifiers and values.

• Constraints can appear in diagrams, often involving brackets: square for guards and curly for general constraints. Constraints can also express preconditions , postconditions and invariants.

• Preconditions, postconditions and invariants are particular easy and powerful ways of improving specifications (design by contract). Preconditions are statements that must turn out to be true before particular things can take place. Postconditions are statements that must turn out to be true after particular things have taken place. Invariants are things that must always hold true when the system is at a stable point, i.e. the elements of the invariant are not actually undergoing change.

• The OCL is also used in the UML infrastructure to formally express constraints of the UML metamodel.

• The OCL has forAll and exists operators, but they can only be applied to identifiable existing collections. So it has a kind of higher-order logic.
   

---

Diagram Interchange

• The UML lacked a defined way of describing and transporting diagrams with all their layout information.

• UML 2.0 brings an XML-based diagram interchange standard.

 

---

Metamodel Layering

The architecture that is centered around the Core package is a complementary view of the four-layer metamodel hierarchy on which the UML metamodel has traditionally been based. When dealing with meta-layers to define languages there are generally three layers that always has to be taken into account:

• the language specification, or the metamodel (mangement),
• the user specification, or the model (domain), and
• objects of the model (carrier).

This structure can be applied recursively many times so that we get a possibly infinite number of meta-layers; what is a metamodel in one case can be a model in another case, and this is what happens with UML and MOF. UML is a language specification (metamodel) from which users can define their own models. Similarly, MOF is also a language specification (metamodel) from which users can define their own models.

An example of metamodeling; note that not all instance-of relationships are shown

Giving an illustration of a class using an instance specification

An example of the four-layer metamodel hierarchy

---

Superstructure of the UML: Diagrams

There are two kinds of diagrams: structure diagrams which represent the way things are, and behavior diagrams which represent the way things happen.

The top-level package structure of UML 2.0 Superstructure

A diagram requires a border or a title, Diagram frame shows how this is done. The border plus title is known as a frame . Some behavioral diagram elements appear on diagram borders - ports or entry/exit points, for example.

The heading gives the kind of diagram and the name: [<kind>]<name>[<parameters>]
The diagram may have the following kinds :

• class
• component
• interaction
• package
• state machine
• use case

In addition to the long form names for diagram heading types, the following abbreviated forms can also be used:

• act (for activity frames)
• cmp (for component frames)
• sd (for interaction frames)
• pkg (for package frames)
• stm (for state machine frames)
• uc (for use case frames)

---

Things

Things are the entities of a UML model.

UML things can be partitioned:

• structural things: class, interface, collaboration, use case, active class, component, node
• behavioral things (process representation): interactions, activities, state machines
• grouping things: package, component
• annotational things: a note

---

Relationships

• UML relationships connect things.
  • A dependency relationship indicates that one element depends in some way on another.
  • Associations are connections between classifiers.
  • Links are connections between instances.

---

Extensibility Mechanisms

• UML is extensible modeling language.
• Constraints
  These extend the semantics of sn element by allowing us to add new rules.
  Constrains are define in OCL.
• Stereotypes
  These allow us to define a new UML modeling element based on an existing one - we define the semantics if stereotype ourselves.
  (append a stereotype name in guillemets, e.g., «interface»)
• Tagged values
  These provide a way of extending an element's specification by allowing us to add new, ad hoc information to it.
  {tag1 = value1, tag2 = value2, ... , tagN = valueN}

 

---

UML Diagrams Used in this Course

• Structure Diagrams
  • Class diagrams (structure diagram)
  • Package diagrams (included in class diagrams)
  • Component diagrams
  • Composite structure diagrams
  • Deployment diagrams
• Behavior Diagrams
  • Use cases
  • Activity diagram
  • Sequence diagrams
  • Communication diagrams