UML OCUP2 Intro

Unified Modeling Language ⌘

History of UML ⌘

UML was developed by Grady Booch, Ivar Jacobson and James Rumbaugh (The Three Amigos)

UML versions⌘

• 0.8 Booch & Rumbaugh 1995
• 0.9 The Three Amigos 1996
• 1.1 OMG 1997
• 1.2-1.5 OMG refinements 1998-2003
• 2.0 OMG major review and redesign 2003-2005
• 2.1.1, 2.1.2 OMG 2007
• 2.2 OMG 2009
• 2.3 OMG 2010
• 2.4.1 OMG 2011
• 2.5 OMG 2015 current version

www.omg.org/spec/UML/Current/

Overview ⌘

• OMG Standard
• The Unified Modeling Language (UML)
• Data modeling, business modeling (work flows), object modeling, and component modeling
• UML aims to be a standard modeling language which can model concurrent and distributed systems
• UML is a de-facto industry standard
• UML models may be automatically transformed to other representations (e.g. Java, PHP)
• UML is extensible, through profiles, stereotypes and tagged values
• A lot of other languages are based on UML (SysML, SoaML)
• Usually default language for a lot of architecture frameworks (MoDAF, DoDAF, NAF)

UML 2.5 Scope⌘

• The objective of UML is to provide system architects, software engineers, and software developers with tools for analysis, design, and implementation of software-based systems as well as for modeling business and similar processes.
• UML contains:
  • A formal definition of a common MOF-based metamodel specifies the abstract syntax of the UML. The abstract syntax defines the set of UML modeling concepts, their attributes and their relationships, as well as the rules for combining these concepts to construct UML models.
  • A detailed explanation of the semantics of each UML modeling concept.
  • A specification of the notation elements for representing the individual UML modeling concepts as well as rules for combining them into a variety of different diagram type.
  • A detailed definition of ways in which UML tools can be made conformant with this specification.

Models and What They Model⌘

• A model is always a model of something.
• The thing being modeled can generically be considered a system within some domain.
• The model then makes some statements of interest about that system, abstracting from all the details of the system, from a certain point of view and for a certain purpose.
• For an existing system, the model may represent an analysis of the properties and behavior of the system.
• For a planned system, the model may represent a specification of how the system is to be constructed and behave.

UML 2.5 Specification ⌘

• New specification supersedes UML 2.4.1 Infrastructure (metamodel) and UML 2.4.1 Superstructure (notation and semantics for diagrams and their model elements)
• UML Infrastructure no longer forms part of the UML specification.
• Supporting specifications
  • Object Constraint Language (OCL)
  • UML Diagram Interchange

UML Features⌘

• Does not define method (see Unified Process)
• UML defines both:
  • UML model (contains documentation and all relations)
  • UML diagrams (partial graphic representation of a system's model)
• UML can model both views of the system:
  • Static (structural)
  • Dynamic (behavioural)
• Contains 14 different diagarams

UML Diagrams ⌘

Structure diagrams⌘

Structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems.

Class diagram⌘

Describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.

Other structure diagrams⌘

• Component diagram: describes how a software system is split up into components and shows the dependencies among these components.
• Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.
• Deployment diagram: describes the hardware used in system implementations and the execution environments and artifacts deployed on the hardware.
• Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time.
• Package diagram: describes how a system is split up into logical groupings by showing the dependencies among these groupings.
• Profile diagram: operates at the metamodel level to show stereotypes as classes with the <<stereotype>> stereotype, and profiles as packages with the <<profile>> stereotype.

Behavior diagrams⌘

Behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems.

Activity diagram⌘

Describes the business and operational step-by-step workflows of components in a system.

Use Case diagram⌘

Describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.

State machine diagram⌘

Describes the states and state transitions of the system.

Interaction diagrams⌘

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

Sequence diagram⌘

Shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.

Other Interaction diagrams⌘

• Communication diagram: shows the interactions between objects or parts in terms of sequenced messages.
• Interaction overview diagram: provides an overview in which the nodes represent communication diagrams.
• Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints.

UML 2.5 Metamodel (Abstrax Syntax)⌘

• UML is a language
• UML metamodel is a class model which describes UML
• UML is defined in UML!
• Just as English is described in English in dictionaries

UML 2.5 Metamodel Exercise ⌘

UML 2.5 Specification - how to read?⌘

Demonstration: How to read UML 2.5 Specification?