UML Design

1. 1
UML - Module Objectives
• At the end of this module, participants will be
able to:
– Explain the background behind UML and its use
in software design and development
– Describe when and how to apply the following
diagrams:
• Use Case Diagrams
• Class Diagrams
• Sequence Diagrams
• State Diagrams

2. 2
UML
• UML stands for Unified Modeling Language
• It is a standard language for specifying, visualizing, constructing,
and documenting the components of systems
• UML is independent of particular programming languages and
development processes

3. 3
Introduction to Case Study Activity
• Introduction to Client: Extreme Exploration
– Medium-sized retailer of outdoor apparel, accessories, and camping
gear.
– Existing website created by a graphic design firm and currently
provides information, such as store locations and phone numbers.
• Problem Domain
– Competitors have advantage online.
– First attempt at creating ecommerce presence failed due to lack of
expertise and methodology-driven approach.

4. 4
Introduction to Case Study Activity
• Business Goals
– Create online shopping catalog
– Expand product offerings by leveraging products of business partner
“Adventure-1”
– Allow for an enhanced purchasing experience
• Identified functional areas
– Catalog browsing
– Shopping cart
– User account
– Checkout

5. 5
Use Case Diagrams
• Useful in determining initial system requirements and
functionalities
• Displays relationships and interactions between actors and the
systems they act upon
• Identifies the ‘actors’ in a system and the various cases that the
actors might interact with the system

6. 6
Use Case Diagrams (cont.)
• Actors represent an entity that initiates the interaction with the
system
• An actor can represent a user, organization, or another external
system
Student Batch System
Faculty

7. 7
Use Case Diagrams (cont.)
• A ‘use case’ represents a possible interaction between the actor
and the system
• Each use case is a high level description of a functionality that
must be supported by the system
Enroll Subject
Get Subject
Prerequisites
Check Current
Schedule

8. 8
Use Case Diagrams (cont.)
• An interaction between an actor and a system is denoted by a line marked by a
<<uses>> tag
• This can be interpreted as “The (actor) can use the system to <<use case>>”
• Rectangle box called as system boundary box can be drawn to represent
scope of the use case
Student
Enroll Subject
Get Subject
Prerequisites
Check Current
Schedule
«uses»
«uses»
«uses»
Faculty
Get Enrolled
Students by Subject «uses»
«uses»

9. 9
Use Case Diagrams
• It is also possible to establish a relationship as a dependency
between two use cases using the <<extends>> line
• An <<extends>> line indicates that the use case is dependent
on another use case in order to perform the functionality
Extension
use case
Base use
case
Perform Security Check Student Enrolment
<<extends>>

10. 10
Use Case Diagrams
• Use Cases describe a sequence of actions the application
performs for an actor.
• Use Cases are identified as a team exercise.
– Identify actors and Use Cases
– Define interactions between actors and Use Cases
– Describe Use Case steps and combine similar Use Cases

11. 11
Activity – Use Case Diagram
Status of the Extreme Exploration project:
• The Plan phase is complete and the Business Analyst group is
Analyzing the Business Process.
Task to be performed in the Analysis phase:
– The use case diagram to be created

12. 12
Library Mgmt. System

13. 13
Library Mgmt. System Example 2

14. 14

15. 15

16. 16

17. 17
Class Diagrams
• Class diagrams are used to describe classes of objects in terms
of their names, attributes, and operations
• Class diagrams are used to describe the relationship between
the objects in a system

18. 18
Class Diagrams (cont.)
• A Class diagram is composed of a
class icon that defines the class itself
• The class icon describes the name of
the class, the attributes of a class, and
the behaviors/operations of a class
+enrollSubject()
+dropSubject()
+getCurrentSchedule()
-Name : String
-BirthDate : Date
-Grade : Integer
-Subjects[] : Subject
Student

19. 19
Class Diagrams (cont.)
• Associations are the representation of relationships between
classes that communicate with one another.
• There are several types of associations to consider:
– Multiplicity
– Generalization (Inheritance )
– Aggregation and Composition

20. 20
Class Diagrams (cont.)
• Multiplicity : An association relationship where (at least) one of
the two related classes references the other.

21. 21
Class Diagrams (cont.)
• Class diagrams can denote inheritance
relationships between two classes
• The direction of the arrow points to the
base or the parent class
+enrollSubject()
+dropSubject()
+getCurrentSchedule()
-Name : String
-BirthDate : Date
-Grade : Integer
-Subjects[] : Subject
Student
+getRequiredSubjects()
-Minimum GPA : Double
-Required Subjects[] : Subject
Honor Student

22. 22
Class Diagrams (cont.)
• Class diagrams can denote
implementation relationships
between a class and an interface
• The direction of the arrow points
to the interface being
implemented by the class
+teach()
+computeGrade()
+checkTestPaper()
+createTestPaper()
«interface»Faculty
+checkStudentSourceFile()
+readComputerManual()
-ComputerScienceFacultyID : int
ComputerScienceFaculty

23. 23
Class Diagrams (cont.)
• Aggregation and Composition :
– Aggregation is an “is-part-of-a” association
that specifies a “whole-part” relationship
between two classes.
– Composition is a stronger form of
aggregation that is a “has-a” relationship.
Composition
Aggregation

24. 24
Class Diagrams (cont.)
• Class diagrams can be used to show a ‘strong’ aggregation
between two objects
• It is denoted as a ‘has-a’ relationship between the two objects
• The lifetime of the object that is contained is dependent on the
lifetime of the container object
+enrollSubject()
+dropSubject()
+getCurrentSchedule()
-Name : String
-BirthDate : Date
-Grade : Integer
-Subjects[] : Subject
-StudentHistory[] : Student History
Student
+retrieveNotes()
+retrievePreviousGPA()
+retrieveCompletedSubjects()
-Subject
-Grade
-School
-Note
-Year
Student History
1 0..*

25. 25
Class Diagrams (cont.)
• An ‘association’ relationship can be formed denoting a ‘weak’
aggregation between two objects
• In an association relationship, the objects can exist
independently of each other
+enrollSubject()
+dropSubject()
+getCurrentSchedule()
-Name : String
-BirthDate : Date
-Grade : Integer
-Subjects[] : Subject
-StudentHistory[] : Student History
Student
-Name : String
-Description : String
-Prequisites[] : Subject
Subject
1 0..*

26. 26

27. 27

28. 28
Sequence Diagrams
• Sequence diagrams show a group of objects interacting within a
system to perform a specific functionality
• Sequence diagrams show the ‘messages’ that are passed
between one object to another, and the order (or sequence) that
these messages are sent

29. 29
Sequence Diagrams (cont.)
• Messages are indicated as solid horizontal arrows attached to
the timeline of the source object to the target object
• Dashed horizontal arrows indicate the response of the message
receiver
Student Scheduler UI Scheduler DB
retrieve available subjects
retrieveSubjectList()
return Subject[]
display Subjects[]

30. 30

31. 31
State Diagrams
• State diagrams are used to model the changes in the state of an
object as events occur.
• The diagram represents what possible states an object can
change into depending on its current state, and what events
occur
• Each diagram represents an object of a single class

32. 32
State Diagrams (cont.)
• State diagrams begin with an initial state:
• Events or messages that cause the state to change is marked
by an arrow pointing to an icon representing the resulting state
Enrolled
/ Student Enrolls

33. 33
State Diagrams (cont.)
• The state can branch off to other states or itself depending on
the messages or events it can receive.
Enrolled
/ Student Enrolls
Graduates
/ Student Graduates
Suspended
/ Student Suspended
/ Student Removed
Discharged
/ Student Removed
Graduated

34. 34

35. 35
Activity
Diagram

36. 36
Component diagram

37. Deployment diagram

38. 38
Questions and Comments
• What questions or comments
do you have?

39. 39
1) What type of UML diagram is shown below?
2) Identify ‘actor’ and ‘system’ in the following diagram.
3) What is <<uses>> tag used for?
4) What is <<extends>> tag used for?
Checkpoint Question

40. 40
1) What type of UML diagram is shown below?
a) Use Case Diagram
2) Identify ‘actor’ and ‘system’ in the following diagram.
a) Customer is the actor. Login and Registration are the systems.
3) What is <<uses>> tag used for?
a) An interaction between an actor and a system is denoted by a line marked by a
<<uses>> tag
4) What is <<extends>> tag used for?
a) An <<extends>> line indicates that the use case is dependent on another use case
in order to perform the functionality. In the example on the slide, Login is dependent
on Registration. If customer is not registered, he/she cannot login to the system.
Checkpoint Answer

41. 41
1) Identify what each of the following represents (Interface, Aggregation,
Dependency, Composition, Generalization, Association)
Checkpoint Question

42. 42
1) Identify what each of the following represents (Interface, Aggregation,
Dependency, Composition, Generalization, Association)
Checkpoint Answer
Composition
Generalization
Dependency
Interface
Association
Aggregation

43. 43
1) Draw a class diagram for the following:
1. Abstract class Mammal consisting of:
• Private variable numOfLegs of type integer
• Getter and setter for numOfLegs
• public void eat() method
2. Interface Moveable
• Consists of void move() method
3. Class Lion subclass of class Mammal
• Consists of roar() method that returns String
Checkpoint Question

44. 44
1) Draw a class diagram for the following (Cont…)
4. Class Dog subclass of class Mammal
• Private variable age of type integer
• Getter and Setter for variable age;
• Consists of woof() method that returns String
5. Class Jungle
• Consists of public double area() method
• Associate it with class Lion()
• Establish multiplicity between Jungle() and Lion()
Checkpoint Question

45. 45
45
Checkpoint Answer

46. 46
Look at the UML diagram on the next slide and
A. Identify type of UML diagram shown
B. Add following messages/return message calls in the correct order:
1. ValidateWithDB(id, pwd)
2. Show Response to the User
3. DB Returns true or false
4. ExecuteLoginRequest(id, pwd)
5. User Enters Id and Password to Login
6. Return true or false
Checkpoint Question

47. 47
Checkpoint Question

48. 48
1) Solution
Checkpoint Answer

49. 49
True or False?
1. State diagrams are type of UML diagrams.
2. State diagrams begin with an intermediate state
3. Events or messages that cause the state to change is marked by
an arrow pointing to an icon representing the resulting state
4. The state can never branch off to other states
Checkpoint Question

50. 50
50
True or False?
1. State diagrams are type of UML diagrams. True
2. State diagrams begin with an intermediate state. False
3. Events or messages that cause the state to change is marked by
an arrow pointing to an icon representing the resulting state. True
4. The state can never branch off to other states. False
Checkpoint Answer