Introduction to UML

by K. Yue

1. Introduction to UML

• UML: A set of graphical notations for object oriented modeling.
• Wikipedia: "The Unified Modeling Language (UML) offers a way to visualize a system's architectural blueprints in a diagram."
• A standard maintained by OMG: OMG's UML page.
• Two major versions:
  • Version 1.4.2: international standard released in 2005.
  • Version 2.5.1: released in 2017, added nested classifiers and improved behavior models.
• Two main types of diagrams:
  • Structure diagrams: static structures.
  • Behavior diagrams: dynamic behaviors.
• Version 2.5 has 15 diagrams: 7 structure diagrams and 8 behavior diagrams.
• Some Resources:
  • OMG UML Resource
• SPARX UML Tutorial.
• We will focus on the class diagram only.

Class Diagram of UML 2.2 diagram (from wikipedia):

2. Class Diagrams (Emphasis on DB applications)

Introduction:

• A static structure diagram in UML.
• "Describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among the classes." from Wikipedia.
• Read "class diagram" from Wikipedia: http://en.wikipedia.org/wiki/Class_diagram.
• For a significantly better introduction by IBM: http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/.
• Two kinds of tools for drawing UML diagrams:
  • Graphical tools: main purposes are drawing (e.g. MS Visio, draw io, etc.)
  • Computer-Aided Software Engineering (CASE) tools: for software development with some understanding of the semantics of diagram elements (e.g. MagicDraw, IBM Rational Rhapsody, Visual Paradigm, Astah, etc.)
• We will use Astah UML Editor
  • We will use community version in classroom demonstration, which is now deprecated.
  • Students can use the more powerful student version for free: search "astah student license".
• One may also use UML object diagrams to show objects and their associations of a snapshot of the system.

A Simple Conceptual Modeling Process

1. Examine application requirements to gain a good understanding of the problem.
2. Conduct an analysis to extract concepts that may have data requirements.
3. For each concept, design how do model the concept. Options are:
   1. by attributes
   2. by a class
   3. by associations between classes
   4. no need to model

These steps are repeated until the model reaches the necessary fidelity, accuracy and precision.

Example:

Problem. An used car dealership application's subsystem: information about cars and their manufacturers.

Specification description: A car manufacturer has an unique id and name. A car maker may make many cars. For example, Honda, which may have an manufacturer id of 10001, makes Civic and Accord.

Analysis and Design

1. Manufacturer: a class (template) that can be used to initiate many manufacturer objects (instances).
2. Honda: an object of the class Manufacturer.
3. Resolve ambiguous terms: manufacturer, may refer to the manufacturer class or a particular manufacturer (e.g. Honda).
4. Define synonym: manufacturer, car manufacturer, car maker. Different terms can refer to the same concept.
5. Unique id: attribute (name), a property of the manufacturer class.
6. Make additional assumptions: Every manufacturer object must have an unique id.
7. 10001: attribute (value) of a manufacturer object.
8. Name: a property of manufacturer.
9. Additional assumption: Every manufacturer object must have a name.
10. Car: a class as there may be many brands of cars.
11. Prepare questions: Do we need to introduce the concept Model (e.g. Coupe, Sedan, Si Coupe)?
12. Civic and Accord: object instance of Car.
13. Additional assumption: Every car must have a name as its attribute.
14. Make, or manufacture: a relationship between a manufacturer (object) and a car (object).

Class Diagram:

Object Diagram:

Classes:

1. Drawn as a rectangular box.
2. The class names, attributes, and operations may be specified, with selected details in the name, attribute and operation compartments respectively.
3. Attribute and operation compartments are optional.
4. For DB modeling, the attribute compartment will eventually need to be clearly modeled. The operation compartments can be missed.
5. The levels of details depend on the phase of modeling. It is a common mistake to specify too much detail in the early modeling phases.
6. As modeling proceeds, more details are added, updated, and refined.

Note that software application modeling and database modeling has different focus.

1. Application modeling: focus on operations (methods).
2. Database modeling: focus on attributes (data).

Example: The following diagram show the Window class in three phases of modeling. Note that this is for software modeling, not data modeling.

• For example, one may focus on the main classes and their associations in the first model, without worrying about the attribute or operation compartments.
• Most UML editors allow controlling visibility of different elements. For example, in Astah:

• A stereotype (specifying the kind of entities) and a property list with tagged values can be added to any compartment.
• Their flexibility allows for customization and extensibility to fit specific applications.
• Additional properties on data members may be specified, such as:
  1. Visibility: + (public: +, protected: #, private: -, etc.)
  2. data types.
  3. abstract (in italic) or concrete (as constraints)
  4. class members (underscored) or instance members
  5. default values

Example: for software modeling:

Example: for database modeling.

The class Patron may be identified in the first draft of the UML class diagram.

1. In a subsequent iteration, attributes may be added using settings of the UML tool showing visibility of the attribute members.
2. Data types may be included using predefined data types provided by the tool.
3. In a further iteration, stereotype may be added, such as to identify the primary key <<PK>> and simple candidate key <<unique>>.
4. More specific user-defined types (or implementation types) may be used.
5. Operation members may be added. They are in general much less important than data members in database modeling.
6. Multiplicity should eventually be added, as shown in the diagram below.

• Note that multiplicity can be used to depict nullability and multi-valued attributes. In this example, Phone is nullable and Hobbies can have multiple values.

Examples:

Class diagrams from agile modeling and wikipedia.

• Some possible relational database options/extensions on attributes may include:
  1. Multi-valued: * or by using multiplicity.
  2. Multiplicity can also be used to indicate whether an attribute is nullable.
  3. Derived: <<derived>>, \, or using other specific notation
  4. Primary key: <<PK>> as stereotype.
  5. Candidate keys: <<CK>> as stereotyp
  6. Unique field: <<unique>> as stereotype.
  7. Nullability: <<nullable>> or by using multiplicity.
  8. User or system defined SQL data types.
  9. Indexing: <<index>> as stereotype.
• Check with your organizations for UML guidelines on a specific project.
• An example of a database profile for UML: http://www.agiledata.org/essays/umlDataModelingProfile.html
  • may be adapted for uses in later phase of modeling.
• A class is a 'first class citizen'.
  • It has attributes
  • It can form an associations with other classes.
  • Objects of a class can exist by themselves.
• As a comparison, an attribute is not a first class citizen.
  • It does not have sub-attributes
  • It cannot form associations.
  • The existence of an attribute depend on the object.
• A class in a class diagram have some properties of a data type.
• Objects can be instantiated from classes.

Example:

We may have four objects of the student class: S1, S2, S3 and S4. Each student object represents an individual student in a database application.

We may have three objects of the course class: C1, C2, and C3. Each course object represents an individual course in the database application.

Associations

• Binary associations are represented by solid lines.
• Important options include:
  1. Association names with reading direction arrows.
  2. Association roles.
  3. Multiplicities.
  4. Association attributes, usually stored as association classes.
  5. Qualifiers: association attributes to partition the targeted classes.
  6. Navigational requirement: specified by arrows.
  7. Dependency constraints: by dotted lines.
• Some modeling questions/decisions:
  1. Should we model something as a class or as an association?
  2. Should we model something as a class or an attribute?
  3. What kind of association should I use? Binary association, association class, n-ary association?

Example: Note that no attributes are shown in this initial phase.

Note:

1. Job is an association class.
2. The arrow in the association "works-for" shows the direction of the association.
3. The association "manages" is between two job objects.
4. The {or} designation specifies the partition of the account class into two classes: person (account) and corporate (account).

Example:For:

The association Enroll describes the association 'type'. The association is actually between two objects (a student object and a course object). Examples:

S1 -- C1: meaning student S1 is enrolled in course C1.
S1 -- C3
S2 -- C1
S2 -- C2
S2 -- C4
S3 -- C3
S4 -- C1
S4 -- C4

• Multiplicity can be specified by a number, the symbol * (many), a range, or a set.
• Multiplicity is a very common source of errors. Please refer to the explanation of the following diagram until you are very clear about it.

• Meaning:
  • Every X object is associated with n Y objects.
  • Every Y object is associated with m X objects.

Example

What do you think about these class diagrams?

(a)

(b)

(c)

• Aggregation indicator (hollow diamond) and composition indicator (solid diamond):
  1. Aggregation models the ‘a-part-of’ relationship. E.g. car-wheel.
  2. Composition is a strong form of aggregation: the part's life cycle is dependent on the wholes life-cycle; e.g. university-department, building-room.
  3. They can also be represented by using multiplicity.

Example: Aggregation and Composition

What do you think about this composition and aggregation examples in: http://en.wikipedia.org/wiki/File:Congregationalism?

• N-ary associations are represented using a diamond connecting to participating classes.
  • Not so common.
  • May be modeled as a class instead.

A not so good example from a tutorial:

Tips:

• In modeling, a tertiary association can be replaced by a number of binary associations.
• Don't use n-ary associations where n>=3 unless you are sure.
• Generalization is represented a hollow triangle at the superclass.
  • Generalization models the 'a-kind-of’ association.
  • Avoid multiple copies of member definition.

• Some options of generalization includes:
  • discriminator (the name of the partition),
  • powertype (a class in which an instance of it is a subclass of the superclass),
  • constraints (overlapping, disjoint, complete, incomplete and user defined constraints).

Example:

• There are many possible options and extensions.

Constructing class diagrams: some tips

1. There are many methodologies and best practice tips to construct effective class diagrams.
2. There are many possible modeling options: e.g. classes versus attributes, classes versus associations, multiplicity, etc.
3. Need to fully understand the assumptions and implications when making modeling decisions.
4. Do not model implementation details in earlier modeling phases.

Classwork We will work on a problem from a previous semester.