1. UML Unified MODELING Language
Hoang Huu Hanh, PhD
UML Unified MODELING Language
based on online courses and presentations

2. DEFINITION
Unified Modeling Language is the successor to the wave of Object- Oriented Analysis and Design methods that appear in the late `80s and early `90s.
Most directly unifies the methods of Booch, Rumbaugh (OMT), and Jacobson, but its reach is wider than that.
UML went through a standardization process with the OMG (Object Management Group) and is now an OMG standard.
Introduction to UML

3. CS 578 Software Architecture -- From Architecture to Design: Role Of UML
11 April 2017
UML History
Introduction to UML
Walk the audience through the timeline. Point out that the UML is the natural successor to the notations.
1. Late ‘80s and early ‘90 - there are many (50+) OO methodologies
2. Among the first generation methodologies, Booch and OMT stood out
3. Around 1993, second generation methodologies came out - Booch ‘93 and OMT-II. Methodologist borrowed good concepts from each others so many concepts were the same across the methodologies, but different notations.
4. Oct Dr. James Rumbaugh joined Rational to unify Booch & OMT.
5. At OOPSLA ‘95, Grady and Jim announced Unified Method 0.8.
6. Use Case technique developed by Dr. Ivar Jacobson was adapted by all
methodologies by then.
7. Rational acquires Objectory in fall of ‘95 - Dr. Ivar Jaconson joins Rational.
8. Jun of ‘96 - Rational submits UML 0.9 to OMG.
9. UML gains industry support from HP, Microsoft, Oracle + 16 others
10. UML is the de facto standard for OO and component technologies
11. The final submission goes in Sep. ‘97 - expect the announcement in Dec.
...
© Neno Medvidovic & Edward Colbert

4. WHAT IT IS UML is a modeling language, not a method
Most methods consist, at least in principle, of both a modeling language and a process.
Modelling Language is the (mainly graphical) notation that methods use to express designs.
Process is their advice on what steps to take in doing a design.
Modeling Language is the most important part of the method, which is the key part of communication.
Introduction to UML

5. WHY USE UML Helps Analysis and Design Used for communication
Use the advantages of OO
Documentation
As stated in The Unified Modeling Language User Guide;
UML is a language for:
Visualizing
Specifying
Constructing
Documenting
Introduction to UML

6. Visualizing It makes it easier to understand and work through problem
Since it is a formal language, it enables other developers familiar with the language to more easily interpret our drawings.
Introduction to UML

7. Specifying
We must communicate our software system using some common, precise, and unambiguous communication mechanism.
Again the formal nature of the UML facilitates this specification quite nicely.
Introduction to UML

8. Constructing
We know that the UML is a formal language with its own set of syntactical rules.
Because of this formality, we can create tools that interpret our models.
They can map the elements to a programming language, such as Java, C++.
Many tools such as Rational Rose, supports this forward engineering. In fact this is one of the advantages of using a formal modeling tool.
Introduction to UML

9. Documenting
The models we create are just one of the articats produced throughout the development lifecycle.
Using the UML in a consistent fashion produces a set of documentation that can serve as a blueprint of our system.
Introduction to UML

10. USAGES Define the boundaries of a system & its major functions
use cases and actors
Illustrate use cases
interaction diagrams
Define the static structure of a system
class diagrams
Model the behavior of objects
state transition diagrams
Document the physical implementation architecture
component & deployment diagrams
Provide for growth
stereotypes
Introduction to UML

11. FUNDAMENTAL UML Models and Views Core Diagrams Fundamental Elements
Introduction to UML

12. Introduction to UML

13. Models and Views UML is more than disjointed diagrams
Turn attention to an illustration of the UML from three different perspectives
Further insight into these divisions enables us to realize one of the greatest benefits of modeling, which is creating different views of our software system.
Introduction to UML

14. Core Elements
Introduction to UML

15. Core Elements (cont’d)
¹ An extension mechanism useful for specifying structural elements.
Introduction to UML

16. Fundamental Elements
These are the elements of which diagrams are composed
Understanding the intent of each element enables us to create precise diagrams, because each of them has unambiguous meaning.
Introduction to UML

17. DIAGRAMS
Individual diagrams contribute more to the specification of a software system.
They are composition of many of the fundamental elements.
Are mechanism that developers use to communicate and solve problems in the complex aspects of the system.
The most common diagram is the Class Diagram, which describe the structural relationships that exist among the classes, can guide developers in understanding our software system’s class structure.
Introduction to UML

18. VIEWS
As we become more proficient in modeling, we begin to realize that using a combination of diagrams to communicate is most effective.
We may need to combine class diagram with a diagram whose intent is to give systems dynamics.
By combining these called views.
View is a depiction of our system from a particular perspective.
By making different views, we can represent our system from different perspectives.
Introduction to UML

19. VIEWS (cont’d) There are five main views,
Use case
Design
Development
Process
Physical
They must be consistent with each other, because all of them are representing the same system.
Can be used to validate each other.
Introduction to UML

20. USE CASE VIEW
This view documents the system from the customer’s perspective.
Terminology used in this view should be domain specific.
Depending on the technical nature of our audience, we should avoid obscure technical terms.
Diagrams most common in this view are the use case diagrams and, less common, activity diagrams.
Organizations transitioning to the UML may wish to work only with use case diagrams early and experiment with activity diagrams over time.
Introduction to UML

21. Design VIEW
This view documents the system from designer’s and architect’s perspective.
Diagrams most common in this view are class and interaction diagrams (either sequence or collaboration), as well as package diagrams illustrating the package structure of our Java application.
Introduction to UML

22. Development VIEW
This view documents the components that the system is composed of.
This view typically contains component diagrams.
Except for the most complex Java applications, this view is optional.
Introduction to UML

23. Process VIEW
This view documents the processes and threads that compose our application.
These processes and threads typically are captured on class diagrams using an active class.
Because of the advanced nature of active classes, coupled with the volume of use, active classes are beyond the scope of this discussion.
Introduction to UML

24. Physical VIEW This view documents the system topology.
Deployment diagrams that compose this view illustrate the physical nodes and devices that make up the application, as well as the connections that exist between them.
Introduction to UML

25. VIEWS (cont.) We are not limited with the listed views.
If there is something that architecturally important, for example security, then we may create a new view (ex: security view) into the system from that perspective.
Introduction to UML

26. Modeling Elements Structural elements Behavioral elements
class, interface, collaboration, use case, active class, component, node
Behavioral elements
interaction, state machine
Grouping elements
package, subsystem
Other elements
note
Introduction to UML

27. Diagrams - The foundation of UML
Use Case Diagrams
Requirements
Activity Diagrams
Generally what, not who - good to detect parallelism
Interaction Diagrams
Collaboration/Communication Diagrams (object centered)
Sequence Diagrams (timeline)
Static Structure Diagrams
Objects/Classes/Packages
Statechart Diagrams
States of objects with interesting lifecycles
Implementation Diagrams
Component Diagrams
Deployment Diagrams
Introduction to UML

28. DIAGRAMS
As we’ve seen, we can combine diagrams that form models and that can serve as views into our system.
If an advantage in modeling is to combine diagrams to form views into our system, then it only makes sense that each diagram has a different focus on what it communicates.
Each falls into one of two categories: behavioral, and structural.
Most commonly used are use case, sequence, and class diagrams.
Introduction to UML

29. Behavioral diagrams
Behavioral diagrams depict the dynamic aspects of our system.They are most useful for specifying the collaborations among elements that satisfy the behavior of our system’s requirements.
Five diagrams that fall into this category are;
Use case
Activity
State
Sequence
Collaboration (Communication)
Mostly used are use case, sequence, and collaboration.
Activity and state diagrams are used on an as-needed basis.
Activity diagrams visually represent behaviors captured by use cases.
State diagrams, on the other hand, are used to illustrate complex transitions in behavior for a single class.
Introduction to UML

30. Core Relationships
Introduction to UML

31. Core Relationships (cont’d)
Introduction to UML

32. Relationships
An association is a bi-directional connection between classes
An association is shown as a line connecting the related classes
An aggregation is a stronger form of relationship where the relationship is between a whole and its parts
An aggregation is shown as a line connecting the related classes with a diamond next to the class representing the whole
A dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the supplier
A dependency is shown as a dashed line pointing from the client to the supplier
Introduction to UML 30

33. Relationship Notation
1 - one and only one
4 - four and only 4
zero or 1
five to and including 10
0..* - zero or more
4..* - four or more
Introduction to UML

34. Finding Relationships
Relationships are discovered by examining interaction diagrams
If two objects must “talk” there must be a pathway for communication
RegistrationManager
Course
Registration
Manager
Math 101:
Course
3: add student(joe)
Introduction to UML 31

35. Relationships ScheduleAlgorithm RegistrationForm RegistrationManager
Course
Student
CourseOffering
Professor
addStudent(Course, StudentInfo)
name
numberCredits
open()
addStudent(StudentInfo)
major
location
tenureStatus
ScheduleAlgorithm
Introduction to UML 32

36. Associations
Introduction to UML

37. Association Ends
Introduction to UML

38. Relationship Notation
1 - one and only one
4 - four and only 4
zero or 1
five to and including 10
0..* - zero or more
4..* - four or more
Introduction to UML

39. Ternary Associations
Introduction to UML

40. Composition
Introduction to UML

41. Composition (cont’d)
Introduction to UML

42. Generalization
Introduction to UML

43. Generalization
Introduction to UML

44. Dependencies
Introduction to UML

45. Dependencies
Introduction to UML

46. Derived Attributes and Associations
Introduction to UML

47. Links
Introduction to UML

48. Constraints and Comments
Introduction to UML

49. Traffic Control System
Actors
An actor is someone or some thing that interacts with the system
External Forces
Human interaction
Automated System
Traffic Control System
Driver
Keyboard
Operator
User
<<Backup System>>
<<toll booth>>
Introduction to UML 14

50. Use Cases A use case is a pattern of behavior the system exhibits
Each use case is a sequence of related transactions performed by an actor and the system in a dialogue
Details what the system must provide to the actor when the use cases is executed
A flow of events document is created for each use case
Written from an actor point of view
Actors are examined to determine their how they interact with the system
Break down into the most atomic actions possible
Typical contents
How the use case starts and ends
Normal flow of events
Alternate flow of events
Exceptional flow of events
Introduction to UML 15

51. Use case diagrams
Use case diagrams are centered around the business processes that our application must support.
Most simply, use case diagrams enable us to structure our entire application around the core processes that it must support.
Doing so enables us to use these use cases to drive the remainder of the modeling and development effort.
Shows a set of actors and use cases, and the relationships between them.
Use case diagrams contribute to effective model organization, as well as modeling the core behaviors of a system.
Introduction to UML

52. Use Case Diagram Captures system functionality as seen by users
Built in early stages of development
Purpose
Specify the context of a system
Capture the requirements of a system
Validate a system’s architecture
Drive implementation and generate test cases
Developed by analysts and domain experts
Introduction to UML

53. Customer Service Agent
Use Case Diagram
Use case diagrams are created to visualize the relationships between actors and use cases
Pay toll
Driver
Passager
Lost Luggage
Customer Service Agent
Ramp Maintenance
Mechanic
Introduction to UML 18

54. Use Case Diagram Captures system functionality as seen by users
Introduction to UML

55. Collaboration Diagrams
A type of interaction diagram that describes the organizational layout of the objects that send and receive messages.
Semantically equivalent to a sequence diagram.
It uses class diagrams layout, and can be used to make more cohesive and less coupled classes.
Introduction to UML

56. Collaboration Diagram
A collaboration diagram displays object interactions organized around objects and their links to one another
course form :
1: set course info
CourseForm
2: process
3: add course
: Registrar
theManager :
aCourse :
CurriculumManager
Course
Introduction to UML
4: new course 22

57. Sequence Diagrams Semantically equivalent to a collaboration diagram.
sequence diagram is a type of interaction diagram that describes time ordering of messages sent between objects.
Almost in all software development activity, this diagram is used.
Introduction to UML

58. Sequence Diagram
A sequence diagram displays object interactions arranged in a time sequence
Counter
Agent
Ticket
Passenger
Gate
Agent
Plane
1: Give Info
2: Questions
3: Answer
4: Print
5: Safeguard
6:Present
7: Board
8: Overbook
9: Return
Introduction to UML 21

59. The State of an Object A state transition diagram shows
The life history of a given class
The events that cause a transition from one state to another
The actions that result from a state change
State transition diagrams are created for objects with significant dynamic behavior
Introduction to UML 37

60. State Transition Diagrams
Illustrates internal state-related behavior of an object.
Transitions between states help identify, and validate, complex behavior.
A class can have at most a single state diagram.
Introduction to UML

61. State Transition Diagram
Add Student /
Set count = 0
Add student[ count < 10 ]
[ count = 10 ]
Cancel
Initialization
Open
do: Initialize course
do: Finalize course
do: Notify registered students
entry: Register student
exit: Increment count
Canceled
Closed
Introduction to UML 38

62. Activity Diagrams Models the flow of activity between processes.
These diagrams are most useful in detailing use case behavior.
An activity diagram doesn’t show collaboration among objects.
Introduction to UML

63. STRUCTURAL DIAGRAMS
Diagrams in this category are focused on specifying the static aspects of our system.
Of these four diagrams, the class diagram is most often used.
when transitioning to the UML, most organizations tend to use class diagrams first because they are excellent mechanisms for communication among developers, as well as tools that can be used for problem solving.
There are two forms of class diagrams.
The first is the most commonly understood and consists of the classes that compose our system and of the structure among these classes.
Unfortunately, the second is not often used but is of equal importance and can be most effective in helping developers understand our system from a high level.
A type of class diagram, called a package diagram, often represents the Java packages and the dependencies between them that our application consists of.
Introduction to UML

64. Class Diagrams
Illustrates a set of classes, packages, and relationships detailing a particular aspect of a system.
This diagram is likely the most common one used in modeling.
Introduction to UML

65. Class Diagrams
A class diagram shows the existence of classes and their relationships in the logical view of a system
UML modeling elements in class diagrams
Classes and their structure and behavior
Association, aggregation, dependency, and inheritance relationships
Multiplicity and navigation indicators
Role names
Attributes
The structure of a class is represented by its attributes
Attributes may be found by examining class definitions, the problem requirements, and by applying domain knowledge
Operations
The behavior of a class is represented by its operations
Operations may be found by examining interaction diagrams
Introduction to UML 23

66. Class Diagram
Captures the vocabulary of a system
Introduction to UML

67. Object Diagrams
Provides a snapshot of the system illustrating the static relationships that exist between objects.
Object diagrams depict the structural relationship that exists among the objects within our running application at a given point in time.
When we think of the runtime version of our system, we typically think of behavior.
Many people have found that object diagrams are most useful in fleshing out the instance relationships among objects, which in turn can help verify our class diagrams.
Beyond this, object diagrams are not often used.
Introduction to UML

68. Relationships
Relationships provide a pathway for communication between objects
Sequence and/or collaboration diagrams are examined to determine what links between objects need to exist to accomplish the behavior -- if two objects need to “talk” there must be a link between them
Three types of relationships are:
Association
Aggregation
Dependency
Introduction to UML 29

69. Multiplicity and Navigation
Multiplicity defines how many objects participate in a relationships
Multiplicity is the number of instances of one class related to ONE instance of the other class
For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship
Although associations and aggregations are bi- directional by default, it is often desirable to restrict navigation to one direction
If navigation is restricted, an arrowhead is added to indicate the direction of the navigation
Introduction to UML 33

70. Multiplicity and Navigation
RegistrationForm
RegistrationManager
Course
Student
CourseOffering
Professor
addStudent(Course, StudentInfo)
name
numberCredits
open()
addStudent(StudentInfo)
major
location
tenureStatus
ScheduleAlgorithm 1
0..*
1..* 4
3..10
0..4
Introduction to UML 34

71. Inheritance
Inheritance is a relationships between a superclass and its subclasses
There are two ways to find inheritance:
Generalization
Specialization
Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy
Introduction to UML 35

72. Inheritance ScheduleAlgorithm RegistrationForm RegistrationManager
Course
Student
CourseOffering
Professor
addStudent(Course, StudentInfo)
name
numberCredits
open()
addStudent(StudentInfo)
major
location
tenureStatus
ScheduleAlgorithm
name
RegistrationUser
Introduction to UML 36

73. The Physical World
Component diagrams illustrate the organizations and dependencies among software components
A component may be
A source code component
A run time components or
An executable component
Introduction to UML 39

74. Component Diagrams
Addresses the static relationships existing between the deployable software components.
Examples of components may be .exe, .dll, .ocx, jar files, and/or Enterprise JavaBeans.
Component diagrams might be used to show the software components within our application.
Components aren’t equivalent to classes.
Introduction to UML

75. Component Diagram
Captures the physical structure of the implementation
Introduction to UML

76. Deploying the System
The deployment diagram shows the configuration of run-time processing elements and the software processes living on them
The deployment diagram visualizes the distribution of components across the enterprise.
Introduction to UML 41

77. Deployment Diagram Captures the topology of a system’s hardware
Introduction to UML

78. Extensibility Mechanisms
Stereotype
Tagged value
Constraint
Introduction to UML

79. Extending the UML
Stereotypes can be used to extend the UML notational elements
Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components
Examples:
Class stereotypes: boundary, control, entity, utility, exception
Inheritance stereotypes: uses and extends
Component stereotypes: subsystem
Introduction to UML 43

80. Deployment Diagrams Describes the physical topology of a system.
Typically includes various processing nodes, realized in the form of a device (for example, a printer or modem) or a processor (for example, a server).
Deployment diagrams are most useful when we have a complex configuration environment.
If our application is to be deployed to multiple servers, across locations, a deployment diagram might be useful.
Introduction to UML

81. Q & A
… time to ask questions
Introduction to UML

82. Thank you!
… take a break
Introduction to UML