UML The Unified Modeling Language A Practical Introduction

1
UMLThe Unified Modeling LanguageA Practical
Introduction
Al-Ayham Saleh

• Al-Ayham Saleh

Aleppo University
17-11-2003
2
UML Modeling

• A model is an abstraction of a situation
• Models consist of objects
• Objects are alive
• They know their attributes
• They can do things using their methods
• They exist in different states
• Each object is unique, it is not any other
  object.
• Objects live in communities
• they exchange messages
• They have relationships with each other
• Objects live in a world, and there are other
  worlds
• Classes are blueprints of objects
• Object are instances of classes

3
UML Diagrams

• Use Case diagrams
• Class diagrams
• Object diagrams
• Sequence diagrams
• Collaboration diagrams
• State chart diagrams
• Activity diagrams
• Component diagrams
• Deployment diagrams

4
Class Diagrams

• Classes are representations of objects.
• Class diagrams represent Objects and their
  relations with each other.
• Class diagrams are static, they display WHO
  operates, not WHAT happens

5
Class Diagram Notations
6
Information/Property Notations
7
Operation/Method Notations
ltltsterotypegtgtopt visibilityopt name(parameter-list
) multiplicityopt return-typeopt
property-stringopt

• Without polymorphism, a method is the same as an
  operation
• With polymorphism, an operation is represented by
  two or more methods

8
Class relationships

• Generalization

• Association

• Dependency

9
Generalization

• Also called generalization/specialization
• Generalization is converted into inheritance when
  generating application code.

10
Association

• Represents links between classes.
• Customer makes a payment.
• Customer makes an order.
• UML allows non-directional associations at the
  analysis phase

11
Association

• Associations have a navigational direction
• A Customers Payment
• Payment of a customer
• Navigational direction is a design issue, not an
  analysis issue.
• If no navigation is given, this may indicate a
  bidirectional navigation or that it is not
  specified.

12
Association

• We have
• ordinary association
• simple aggregation
• very similar to ordinary association,
• only means one class is more Important than the
  other.
• Aggregation is modeled by an empty diamond at the
  important part
• For the programmers, Aggregation is Call by
  reference
• composition (strong aggregation)

13
Association

• We have
• ordinary association
• simple aggregation
• composition (strong aggregation)
• Composition is a Whole-Part relationship
• Composition is modeled by a black diamond at the
  Whole.
• Order can not exist outside the Customer
• For the programmers, Composition is Call by
  value

14
Association

• Associations have Multiplicity
• 0
• 0 .. 1
• 0 .. n
• 1
• 1 .. n
• n

15
Association

• Associations have Roles
• Roles explain the meaning of the association
• Roles are names for the participation of each
  class in the association.
• The programmer converts the roles to the
  appropriate property names.
• Roles have visibility

16
Association

• Associations can be qualified
• The association may have some internal
  parameters.
• The designer should fully explain how the
  qualified association should be implemented.

17
Association Classes

• Associations can have properties and methods.
• An Association Class is a class that represents
  the association.

18
Reflexive Association
19
Designing with Associations

• UML designer should explain with maximum detail
  all the elements of an association

20
Dependency

• Dependency means One class uses the other
• Could be used to show that one method of a class
  uses some objects of the other class.
• Programmers use Dependency to include the
  definition of a class in the other.

Dependent Class
Basic Class
Depends on
21
Abstract Classes
Italic Means abstract
Generalization means inheritance
22
Interfaces

• Interfaces are pure virtual classes
• Interfaces contain only declarations
• Interfaces can be realized by classes
• Interface inheritance is a good programming
  methodology.

Realization
23
Parameterized classes

• Some classes may not be very clear by their own,
  but rather depend on an external parameter.
• Parameterized classes must be instantiated before
  you can create objects of them.
• You can understand parameterized classes as
  class templates

24
Designing effective class diagrams

• Organize similar classes into packages
• Beware of cyclical generalization
• Generalization and realization is unique between
  2 classes
• Use associations where there are structural
  relationships
• Associations are NOT communication pipes.
• Start with Analysis, then refine details to the
  maximum level.
• Explain everything to the programmer using UML
  notations.

25
Common Class diagram pitfalls

• Cyclic generalization
• Redundant generalization
• Redundant realization
• UML/OOP features not supported in the
  implementation language
• Multiple inheritance not supported by Java.
• Duplicate navigable roles for a class in many
  associations

26
Class diagrams in Rational Rose

• The class diagram toolbar

Class
Interface
Association
Association Class
Package
Dependency
Generalization
Realization
27
Class diagrams in Rational Rose

• Classes in Rational Rose

28
Class diagrams in Rational Rose

• Classes in Rational Rose

29
Class diagrams in Rational Rose

• Classes in Rational Rose

30
Class diagrams in Rational Rose

• Associations in Rational Rose

31
Quiz I

• Every student will be advised by one teacher.
  Some teachers advise many students, and some
  advise none. Which of the following class
  diagrams most clearly represents that
  student-teacher relationship?

32
Quiz 2

• An application has many windows, each window has
  an icon, icons are stored in the application, and
  are shared between windows.
• An application has many windows, each window has
  a unique icon, icons are stored in the
  application, not in the windows.
• An application has many windows, each window has
  an icon, icons are stored in the windows, and
  referenced by the application.
• An application has many windows, each window is
  identified by its own unique icon. The
  application includes the windows and their icons.

33
Workshop

• Analyze the following business case using UML and
  Rational Rose, and design a class diagram for an
  OOP computer system that serves it.
• A Customer makes an Order, and a Payment for it.
• A Payment is one of three kinds Cash, Check, or
  Credit.
• The order contains Items, each item is bought in
  a specific quantity and at a specific price.
• The Order can be in a STATE like
• pending for new orders
• approved for received and accepted orders
• rejected for received and rejected orders
• shipped for approved orders that are shipped to
  the customer
• closed for orders received by the customer