Introduction to UML

by K. Yue

1. Resources

UML:

• OMG's UML page.
• SPARX UML Tutorial.

2. Introduction to 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.
• 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.
• We will focus on the class diagram.

Class Diagram of UML 2.2 diagram (from wikipedia):

3. Use Case Diagrams

• No longer covered in CSCI 5333.

4. 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, or a significantly better introduction by IBM: http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/.
• We will use Astah UML Editor community version: http://astah.net/editions/community.
• May use UML object diagrams to show objects and their associations of a snapshot of the system.

Example:

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

Specification: 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:

1. Manufacturer: class (a template that can be used to initiate many manufacturer (instance).
2. Honda: object of the class Manufacturer.
3. Ambiguous term: manufacturer, may refer to the manufacturer class or a particular manufacturer.
4. 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. Additional assumption: 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. Question: 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 filled.
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.

Example: Three phase of modeling a class in software modeling. Note that software application modeling and database modeling has different focus.

1. Application modeling: focus on operations.
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 less important than data members in database modeling.
6. Multiplicity should eventually be added.

• 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 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>>, <<unique>> as stereotype.
  6. Nullability: <<nullable>> or by using multiplicity.
  7. User or system defined SQL data types.
  8. Default values.
  9. Indexing.
• Stereotype is a major mechanism for extending UML diagrams.
• Check with your organizations for UML guidelines for 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'.
• 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.

Classwork (If time allows)

Construct a reasonable class diagram for the toy library 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 target 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.

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.

• 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.

Classwork:

Exercise 7.16, Elmarsi, only in UML class diagram, and not ER. (Elmarsi_7_16.docx)

• Generalization is represented a hollow triangle at the superclass.
  • Generalization models the 'a-kind-of’ association.
  • Avoid multiple copies of member definition.

Example:

Student_Staff_Faculty.asta

What are the associations between student, staff and faculty?

• 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 (If time allows)

The goal is to build a toy prototype database to partially support a portion of a drastically simplified student group system (SGS). Construct an UML class diagram to capture and model the partial requirements below. You should list class names, attributes with multiplicities, and associations with multiplicities. Roles of associations should also be provided when appropriate. Multiplicities should be as specific as possible. Show the stereotype <<PK>> (primary key) when applicable.

In SGS, students can form groups to do things and join these groups as members. The student id (a unique identifier that can serve as a key), name, email, and phone of a student should be recorded. All are mandatory fields with the exception of phone, which is optional. When a student joins a group as a member, the join time must be stored, together with an optional comment.

A group must have a unique id and a name. It may also have a description. It can be a top group or a lower level group. A group may have some subgroups, which are themselves groups, and thus may have their own subgroups. A top level group must have a faculty supervisor, so a faculty id must be stored. A member can make comments on a top level group (but not a lower level group). Such comments should be recorded with the time they were made.

Use Astah if you have a computer.