Introduction to UML
by K. Yue
1. Resources
UML:
UML and DB Modeling:
2. Introduction to UML
- A set of graphical notations for object oriented modeling.
- A standard maintained by OMG.
- Two major versions:
- Version 1.4.2: international standard released in 2005.
- Version 2.3: released in 2010.
- Two main types of diagrams:
- Structure diagrams
- Behavior diagrams
- Version 2.2 has 14 diagrams.
- We will focus on the use case diagram and the class diagram.
Class Diagram of UML 2.2 diagram (from wikipedia):

3. Use Case Diagrams
- To show the main functions of a system for actors (users).
- It is a kind of behavior diagram.
- Good for providing overview of system requirements.
- Used during the early requirement phase to identify system behaviors (what, not how). For example, it is used in the inception and elaboration phases of the Rational Unified Process (RUP).
- Analysis phase: to capture the system requirements and understand what the system is supposed to do,
- Design phase: Specify the behavior of the system as implemented, and/or specify the semantics of a mechanism.
- Read "use case" page of wikipedia: http://en.wikipedia.org/wiki/Use_case
Building blocks:
- Use Case: an action that provides some functions.
- Actors: persons, organizations or external systems that interact with the system to be modeled.
- drawn as a person.
- actors' relationship not shown.
- actor generalization may be modeled. E.g. the actors "staff", "faculty" can be generalized to the actor "employee".
- System boundary box: for showing the system scope.
- drawn as a rectangle to include the use cases.
- Associations between actors and use cases:
- drawn as a solid line.
- An arrow can be added.
- Arrowhead is used to indicate the initial invocation.
- Arrowhead is used to indicate control flow, not data flow.
- Relationships between use cases:
- Frequently used relationships:
- "uses": dotted line with <<use>> stereotype.
- "include": dotted line with <<include>> stereotype.
- "extend": dotted line with <<extend>> stereotype.
- generalization: solid line ended with hollow arrowhead.
An example use case (from wikipedia): http://en.wikipedia.org/wiki/File:Use_case_restaurant_model.svg
Classwork:
Draw a use case diagram for the SCE TA application.
Classwork: Comments on the following use case diagrams.
Diagram #1: E-Commerce Website with Credit Card Processing Capability

Diagram #2: development of an intelligent Web Crawler to scan Human Recruitment specific content



Diagram #3: an application that will utilize a GPS device to monitor and track a fleet of equipment during a disaster recovery scenario.

How to draw UML diagrams:
- Pen and paper: hand.
- graphical editors: e.g. Powerpoint, Visio, etc.
- modeling tool or CASE tool: e.g. Rational Rose, ArgoUML, etc.
Discussion: Just Barely Good Enough (JBGE) modeling and documentation.
Classwork
Construct a reaonable use case diagram for the toy library application
4. Class Diagrams (Emphasis on DB applications)
Introduction:
Classes:
- Drawn as a rectangular box.
- The class names, attributes and operations may be specified, with selected details in the name, attribute and operation compartments respectively.
- Attribute and operation compartments are optional.
- For DB applications, the attribute compartments will eventually need to be filled.
- The levels of details depend on the phase of modeling. It is a common mistake to specify too much detail in the early modeling phase.
- As modeling proceeds, more details are added, updated and refined.
Example:

- A stereotype (specifying the kind of entities) and a property list with tagged values can be added to any compartment.
- Additional properties on members may be specified, such as:
- Visibility: + (public: +, protected: #, private: -, etc.)
- abstract (in italic) or concrete (as constraints)
- class members (underscored) or instance members
- default values
- data types.
Example:

- Database options on attributes may include:
- Multi-valued: *
- Derived: \
- Primary key: <<PK>>.
- Candidate keys: <<CK>>
- Nullable
- Check with your organizations for options to be used.
- An example of a database profile for UML: http://www.agiledata.org/essays/umlDataModelingProfile.html
- may be adapted for uses d in later phase of modeling.
Associations
- Binary associations are represented by solid lines.
- Important options include:
- Association names with reading direction arrow.
- Association roles.
- Cardinality (multiplicity).
- Association attributes, usually stored in association classes.
- Qualifiers: association attributes to partition target classes.
- Navigational requirement: specified by arrows.
- Dependency constraints: by dotted lines.
Example:

- Multiplicity can be specified by a number, the symbol * (many), a range or a set.
- Aggregation indicator (hollow diamond) and composition indicator (solid diamond):
- Aggregation models the ‘a-part-of’ relationship. E.g. car-wheel.
- Composition is a strong form of aggregation: the part's lifecycle is dependent on the whole's lifecycle; e.g. university-department, building-room.
Example:

What do you think about this composition and aggregation example: http://en.wikipedia.org/wiki/File:AggregationAndComposition.svg?
- N-ary associations are represented using a diamond connecting to participating classes.
- Not so common.
- May be modeled as a class instead.
Example:

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 ‘is-a’ association.
- 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.
Examples:
Some class diagrams found in the Web:
Constructing class diagrams
- Many methodologies and best practice tips to construct effective class diagrams.
- Many possible modeling options: e.g. classes versus attributes, classes versus association, multiplicity, etc.
- Need to fully know the implications when making modeling decision.
Classwork
Construct a reasonable class diagram for the toy library application.