1

Chapter Two: Introduction of UML

 Topics covered
2

 Overview of UML
 Building blocks of the UML
 Relationships in the UML
 UML Diagrams
 Overview of UML
3

 What is UML?
 It is an industry-standard graphical language or modeling
language for specifying, visualizing, constructing, and
documenting the artifacts of software systems.
 Goal: provide a standard notation that can be used by
all object-oriented methods
 The UML uses mostly graphical notations to express the OO
analysis and design of software projects.
 Simplifies the complex process of software design
 Help acquire an overall view of a system.
 Ont..
4

 Any real-world system is used by different users. The users can be

developers, testers, business people, analysts, and many more. Hence,
before designing a system, the architecture is made with different
perspectives in mind.
 The most important part is to visualize the system from the
perspective of different viewers.
 The better we understand the better we can build the system.
 UML plays an important role in defining different perspectives of a
system. These perspectives are −
 Design
 Implementation
 Process
 Deployment
 Cont..
5

 Model a system:-
1. Describing the system at abstract level to comprehend
its complexity
2. Necessary to manage complexity
3. Good for quick understanding of the systems
4. Less chances of conflicting views b/w end-user and
system designers common understanding
 In projects involving many participants, with different
technical and cultural backgrounds,
 Accuracy and clarity are critical standard notation
 Cont’d
6

 System development focuses on three different models of

the system:
 The functional model,  use case diagrams, describes
the functionality of the system from the user’s point of view.
 The object model,  represented in UML with class
diagrams, describes the structure of the system in terms of
objects, attributes, associations, and operations.
 The dynamic model  represented in UML with
interaction diagrams, state machine diagrams, and activity
diagrams, describes the internal behavior of the system.
 History of UML
7

 UML is a notation that resulted

from the unification of OMT
(Object Modeling Technique
[Rumbaugh et al., 1991]), Booch
[Booch, 1994], and OOSE
(Object-Oriented Software
Engineering [Jacobson et al.,
1992]).

-UML moves us from fragmentation to

standardization.
 Building blocks of the UML
8

 The building blocks of UML can be defined as:

1. Things

2. Diagrams

3. Relationships

1) Things
 It can be structural, behavioral, grouping or annotational
 Cont’d
9

Structural things:
 The Structural things define the static part of the model. They
represent physical and conceptual elements.
 Following are the brief descriptions of the structural things.
 Class: represents set of objects having similar responsibilities.
 Interface: defines a set of operations which specify the responsibility
of a class.
 Collaboration: defines interaction between elements.
 Use case: represents a set of actions performed by a system for a
specific goal.
 Component: a software unit.
 Node: can be defined as a physical element that exists at run time
 Cont’d
10

Behavioral things:
 A behavioral thing consists of the dynamic parts of UML models.
Following are the behavioral things:
 Interaction: defined as a behavior that consists of a group of
messages exchanged among elements to accomplish a specific task.

 State chart: is useful when the state of an object in its life cycle is
important.

 It defines the sequence of states an object goes through in

response to events.

 Events are external factors responsible for state change.

 Cont’d
11

Grouping things:
 Grouping things can be defined as a mechanism to group
elements of a UML model together.
 Package: is the only one grouping thing available for gathering
structural and behavioral things.
Annotational things:
 Annotational things can be defined as a mechanism to
capture remarks, descriptions, and comments of UML model
elements. Note is the only one Annotational thing available.
 Note: is used to render comments, constraints etc of an UML

element.
 Cont’d
12

(2) Relationship
 Relationship is another most important building block of UML. It
shows how elements are associated with each other and this
association describes the functionality of an application.

 There are four kinds of relationships available.

 Dependency: is a relationship between two things in which change
in one element also affects the other one.
 Association: is basically a set of links that connects elements of an
UML model. It also describes how many objects are taking part in
that relationship.
 Cont’d
13

 Generalization: can be defined as a relationship which

connects a specialized element with a generalized element. It
basically describes inheritance relationship in the world of
objects.

(3) UML Diagrams:

 UML diagrams are the ultimate output of the entire discussion. All
the elements, relationships are used to make a complete UML
diagram and the diagram represents a system.
 UML Diagrams
14

 UML has two types of diagrams:

 Structural Diagrams:
 Behavioral Diagrams:
 Structural Diagrams:
 Visualize, specify, construct and document the static aspects of a
system. the static aspects of a software system encompass the existence
and placement of things such as classes, interfaces, collaborations,
components and nodes etc.
 There are following four structural UML diagrams.
 Class Diagram
 Object Diagram
 Component Diagram
 Deployment Diagram
 Cont..
15

 Behavioral Diagrams: visualize, specify, construct, and document the

dynamic aspects of a system. Dynamic aspects of a system as representing
its changing parts. the dynamic aspects of a software system encompass
things such as the flow of messages over time and physical movements of
components across network

 Following five are the UML behavioral diagrams.

 Use Case Diagram
 Sequence Diagram
 Collaboration Diagram
 State chart Diagram
 Activity Diagram
 Use Case Diagram
16

 Describe the functional behavior of the system as seen by

the user.
 Model the functionality of a system using actors and use
cases. Use cases are a set of actions, services, and
functions that the system needs to perform.
 Mainly used for Visualizing/capturing the functional
requirements of a system that will translate into design
 Used during requirements elicitation Specify how the system
interacts with actors.
 Work like a contract between end user and software
developers.
 Use Case Diagram Symbols and Notations:
17

Use case represent the system's functions

Actors are the users of a system
Boundary: Represent systems boundary
 Actors
18
 An actor models an external entity which
communicates with the system:
 User
 External system
 Physical environment
Passenger  An actor has a unique name and an optional
description.
 Examples:
 Passenger: A person in the train
 GPS satellite: Provides the system with GPS
coordinates
Student  Student: a person in school and registered for class
 Relationships in Use Case Diagrams
19

 There are five types of relationships in a use case

diagram. They are
 Association between an actor and a use case
 Generalization of an actor
 Extend relationship between two use cases
 Include relationship between two use cases
 Generalization of a use case
 Association:
20

Communication between an actor and a use case(Illustrate relationships

between an actor and a use case ); Represented by a solid line.
 Generalization
21

Generalization: relationship between one general use case and a special

use case (used for defining special alternatives)
Represented by a line with a triangular arrow head toward the parent use
case.

 Is it Possible to Generalize Actors and Use Cases

 There maybe instances where actors are associated with similar use
cases while triggering few use cases unique only to them.
 In such instances you can generalize the actor to show the inheritance
of functions. You can do a similar thing for use case as well.
 Cont.…
22

 Generalization is simply the inheritance relationship between two use

cases by which one use case inherits all the properties and relationships
of another use case.
 You can use the generalization relationship when you find two or more
use cases which have common behavior/logic. In this instance, you can
describe the common parts in a separate use case (the parent) which
then is specialized into two or more specialized child use cases.
 Eg1. One of the best examples of this is “Make Payment” use case in a
payment system. You can further generalize it to “Pay by Credit Card”,
“Pay by Cash”, “Pay by Check” etc. All of them have the attributes and
the functionality of a payment with special scenarios unique to them.
 Eg2. If you are creating a payment system which allows students of
a training provider to pay for courses both on-line and by phone,
there will many things in common between the two scenarios
 Include relationship between two use cases

23

 For include relationships among use cases, use arrows

labeled “include"
 An <<include>> relationship indicates that one use case is
needed by another in order to perform a task.
 Avoid redundancy.
<<include>>
 Look for common functionality that can be reused across
the system.
 Then you can connect it via the include relationship to show
that its always called when the original use case is
executed.
 Extend relationship between two use cases

24

 For extends relationships among use cases, use arrows labeled

"extends"
 An <<extends>> relationship indicates alternative options under a
certain use case.
<<extend>>
 There are some functions that are triggered optionally. In such cases
you can use the extend relationship and attach and extension rule to
it.
 Banking system example “Calculate Bonus” is optional and only
triggers when a certain condition is matched.
 Extend doesn’t always mean its optional. Sometimes the use case
connected by extend can supplement the base use case. Thing to
remember is that the base use case should be able to perform a
function on its own even if the extending use case is not called.
 The <<extend>> Relationship cont.…
25
 <<extend>> relationships represent
exceptional or seldom invoked cases.
Passenger  The exceptional event flows are
factored out of the main event flow for
clarity.
 Use cases representing exceptional
PurchaseTicket
flows can extend more than one use
case.
<<extend>>
 The direction of a <<extend>>
relationship is to the extended use case
<<extend>>
<<extend>>

OutOfOrder <<extend>> Timeout

Cancel NoChange
 Example

26
 Use Case Diagrams(cont.)
27

•Pay Bill is a parent use case and Bill Insurance is the child use case.
(generalization)
•Both Make Appointment and Request Medication include Check
Patient Record as a subtask.(include)
•The extension point is written inside the base case
Pay bill; the extending class Defer payment adds the behavior of this
extension point. (extend)
 Eg.3
28

 <<include>>
 Add and drop. Check CGPA >2.5 and ECTS <35
 With draw. Login, view class…..
29
 A use case template for an ATM system
30
31
 Cont..
32
 Sequence diagram
33

 Model the interactions between objects in a single use

case.
 Illustrate how the different parts of a system interact with
each other to carry out a function.
 Sequence diagrams describe interactions among classes in
terms of an exchange of messages over time.
 Displays the time sequence of the objects participating in
the interaction.
 This consists of the vertical dimension (time) and horizontal
dimension (different objects).
 Cont..
34

 Activation Bars
35
 Activity Diagram
36

 Activity diagrams show flow of control and data flow. Typically used to
model:
 Business process workflow
 Flow within a use case
 Business rules logic
 Functional processes
 They are the perfect tool for mapping processes and workflows
 Visually presents a series of actions or flow of control in a system similar to
a flowchart.

 Activities modeled can be sequential and concurrent.

 Cont..
37
 Basic Activity Diagram Notations and Symbols
38

 Initial State or Start Point:

 represents the initial action state or the start point for any activity diagram.

 Activity or Action State:

 An action state represents the non-interruptible action of objects.

 Action Flow:

 Illustrate the transitions from one action state to another.

 Decisions and Branching:

 A diamond represents a decision with alternate paths. When an activity

requires a decision prior to moving on to the next activity, add a diamond
between the two activities
Cont..
39

 Synchronization:
 It is represented as a straight, slightly
thicker line in an activity diagram.
 A fork node is used to split a single
incoming flow into multiple concurrent
flows.
 A join node joins multiple concurrent
flows back into a single outgoing flow.
 A fork and join node used together are
often referred to as synchronization.
 Cont..
40

 Time Event:

 This refers to an event that stops the flow for a time.

 Merge Event:

A merge event brings together multiple flows that are not

concurrent.
 Final State or End Point:
 An arrow pointing to a filled circle nested inside another circle
represents the final action state.
 Login activity diagram
41
This chart shows the flow of checking out a book from your local library. From
inquiring about a book’s availability to taking it home, there are several steps
along the way.
42
 State Machine Diagram
43

 A state machine 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 machine diagram shows how state of some object or

system could change.
 State diagram describes the behavior of a single object in
response to a series of events in a system.
 Models the dynamic flow of control from state to state of a
particular object within a system.
 These are state transition diagrams and describe the lifetime of
some object (a person, a student,…)
 Cont..
44

 Used to model the dynamic nature of a system.

 They define different states of an object during its lifetime and
these states are changed by events.
 Useful to model the reactive systems. Reactive systems can be
defined as a system that responds to external or internal events.
 Describes the flow of control from one state to another state.
 The most important purpose of statechart diagram is to model
lifetime of an object from creation to termination.
 To model the life time of a reactive system.
 To describe different states of an object during its life time.
 Define a state machine to model the states of an object.
 As Statechart diagram defines the states, it is used to model the
lifetime of an object.
 The following state chart diagram represents the states while
navigating through different pages in the project’s site indicating the
overall features –insert, update, view messages/notices etc.
45
The next statechart diagram represents the states of a process while
posting messages to the message board by a residential student or
while posting notices by the hostel administrator.
46
 Class Diagram
47

 Class diagrams is a static diagram

 Describe/ represents the static structure/ view of an application(system):
Objects, Attributes, and Associations.
 Class diagram is not only used for visualizing, describing, and documenting
different aspects of a system but also for constructing executable code of the
software application.
 Class diagrams are the only diagrams which can be directly mapped with
object-oriented languages and thus widely used at the time of construction.
 Class diagram shows a collection of classes, interfaces, associations,
collaborations, and constraints.
 The purpose of lass diagram is to Model the static view of a system/Analysis
and design of the static view of an application and Describe responsibilities
of a system
 Class Diagram basics/ Symbols and Notations
48

 class: Define the classes in an OO system. their fields and

methods. Classes are composed of three things: a name,
attributes, and operations.
Visibility Class name

Attributes

Methods
 Cont..
49

visibility:  Relationships between classes

+ public • Generalization: an inheritance relationship
# protected • Inheritance between classes
- private (dashed line, white arrow)
~ package (default) • Interface implementation
/ derived (dashed line, white arrow)
• Association: a usage relationship
o Aggregation (clear white diamond)
o Composition ( black diamond)
 multiplicity (how many are used)
* ==== 0, 1, or more
1 === 1 exactly
2..4 === between 2 and 4, inclusive
3..* === 3 or more (also written as “3..”)
 Cont..
50

 Visibility: Define the access specification of class

members(methods/attributes)
 However, the UML provides abbreviations for visibility: +
(public), - (private), and # (protected).
A public member is visible anywhere in the program and may
be called by any object within the system.(+)
 A private member may be used only by the class that defines
it.(-)
 A protected member may be used only by (a) the class that
defines it or (b) a subclass of that class.(#)
 Attributes/Methods
51

 attributes (fields, instance variables)

Rectangle
 visibility name : type [count] = default_value
-width:int
 attribute example: -heght:int
- balance : double = 0.00 /area:double

 Class operations / methods +rectangle(width:int

,hegght:int):double
 visibility name (parameters) : return_type +distane(r.rectangle
):double
 parameter types listed as (name: type)

 example:

+ distance(p1: int, p2: int): double

 Classes Relationships
52

 A generalization: is used when two classes are similar,

but have some differences. Read as “A kind of”
• In this example, the object "Car" would
inherit all of the attributes in addition to
the specific and methods of its own class.
• child class have some similarities, but each
class has some of its own attributes and
operations
 Cont..
53

 The association relationship is the most common relationship in a

class diagram.
 The association shows the relationship between instances of classes.
 all objects have their own lifecycle and there is no owner.
 Let's take an example of Teacher and Student. Multiple students can
associate with single teacher and single student can associate with
multiple teachers, but there is no ownership between the objects and
both have their own lifecycle. Both can be created and deleted
independently.
 E.g. the class Order is associated with the class Customer.
 Uni-directional association, two classes are related, but only one
class knows that the relationship exists.
 Bi-directional association is a linkage between two classes.
Associations are always assumed to be bi-directional; this means
that both classes are aware of each other and their relationship,
unless you qualify the association as some other type
 Cont..
54

 Aggregation: refers to the formation of a particular

class as a result of one class being aggregated or built
as a collection. Read as “part of”
 E.g. the class “library” is made up of one or more books,
among other materials.
 In aggregation, the contained classes are not strongly
dependent on the lifecycle of the container. In the same
example, books will remain so even when the library is
dissolved.
 Cont..
55

 Composition: is very similar to the aggregation

relationship. with the only difference being its key purpose
of stressing the dependence of the contained class to the
life cycle of the container class.
 That is, the contained class will be destroyed when the
container class is destroyed.
 composition: “is entirely made of”
 Stronger version of aggregation
 The parts live and die with the whole

 –E.g. a shoulder bag’s side pocket will also cease to exist

once the shoulder bag is destroyed.
Multiplicity: of the association denotes the number of objects that can
participate in then relationship.1 For example, an Order object can be associated to only
one customer, but a customer can be associated to many orders.
Indicator
56 Meaning

0..1 Zero or one

1 One only

0..* Zero or more

* Zero or more

1..* One or more

3 Three only

0..5 Zero to Five

5..15 Five to Fifteen

 Cont..
57

 Class diagram is also considered as the foundation for component and

deployment diagrams.
 e,.g. The following diagram is an example of an Order System of an
application. It describes a particular aspect of the entire application.
 First of all, Order and Customer are identified as the two elements of the
system. They have a one-to-many relationship because a customer can
have multiple orders.
 Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In
addition, they have additional functions like dispatch () and receive ().
Part of Hierarchy
Computer

I/O Devices CPU Memory

Cache ALU Program

Counter
Some issues in object modeling
 Improving the readability of class diagrams
 Managing object modeling Avoid Ravioli
 Different users of class diagrams
Account
Models
Bank Customer

Name
* Amount * Has Name
AccountId
CustomerId
AccountId
Deposit()
Withdraw()
GetBalance() CustomerId

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

 Cont..
60
 Cont..
61
 Class-diagrams have different types of
„users“
 According to the development activity, the developer plays different roles.
 Analyst
 System-Designer,
 DetailedDesigner
 Implementor.
 In small systems some of the roles do not exist or are played by the same
person.
 Each of these roles has a different view about the models.
 I want to distinguish the types of classes that appear in class diagrams.
 Application domain classes
 Solution domain classes
 Class diagrams are always part of models
 Analysis model: Application domain model
 System Design and Object design models: Solution domain model
 Component diagram
63

 Component diagrams are used to model the physical aspects

of a system. Now the question is, what are these physical
aspects?
 Physical aspects are the elements such as executables, libraries,
files, documents, etc. which reside in a node.
 Component diagrams are used to visualize/describe the
organization and relationships of the components
 Shows the dependencies among software components, including
the classifiers that specify them (for example implementation
classes) and the artifacts that implement them; such as source
code files, binary code files, executable files, scripts and tables.
 It does not describe the functionality of the system but it
describes the components used to make those functionalities.
 Ont..
64

 Component diagrams are used during the implementation phase of

an application. However, it is prepared well in advance:
 To visualize the implementation details.
 To get an idea of the implementation.
 This diagram is very important to implement the application
efficiently and for other aspects such as application performance,
maintenance, etc.
 The implementation team of an application should have a proper
knowledge of the component details Component diagrams can be
used to −
 Model the components of a system.
 Model the database schema.
 Model the executables of an application.
 Model the system's source code.
65
 Cont..
66

 You model components and their relationship so that

 Clients can predict the structure and functionality in finished
system
 Developers have a structure to work toward

 Technical writers who have to provide documentation and help

files can understand what they are writing about
 Cont..
67

 Steps to Creating a Component Diagram:

 Take stock of everything needed to implement the
planned system. For example, for a simple e-commerce
system, you'll need components that describe products,
orders, and customer accounts.
 Create a visual for each of the components.

 Describe the organization and relationships between

components using interfaces, ports, and dependencies.
 Cont..
68

 An example of a component diagram for online shopping.

The diagram shows "white-box" view of the internal structure of
three related subsystems - WebStore, Warehouses, and Accounting.
• WebStore subsystem contains three components related to online
shopping: Search Engine, Shopping Cart, and Authentication.
• Accounting subsystem provides two interfaces :
• Manage Orders and Manage Customers.
• Warehouses subsystem provides two interfaces:
• Search Inventory and Manage Inventory used by other
subsystems.
 Deployment Diagram
69

 Deployment diagram Describes a static view of the run-time

configuration of hardware nodes and the software components
that run on those nodes.
 The deployment diagram captures the configuration of the
run time element of the application.
 Deployment diagrams show the hardware for your system, the
software that is installed on that hardware, and the middleware
used to connect the disparate machines to one another.
 Deployment diagrams are used for describing the
hardware components, where software components are
deployed.
 Cont..
70

 Component diagrams are used to describe the

components and deployment diagrams shows how they
are deployed in hardware. They are Closely related
 UML is mainly designed to focus on the software artifacts
of a system. However, these two diagrams are special
diagrams used to focus on software and hardware
components.
 Deployment diagrams can be visualized as the hardware
components/nodes on which the software components
reside.
 Cont..
71

 The purpose of deployment diagrams can be described as −

 Visualize the hardware topology of a system.
 Describe the hardware components used to deploy software components.
 Describe the runtime processing nodes.
 An efficient deployment diagram is very important as it controls the
following parameters −
 Performance, Scalability, Maintainability, Portability
 To meet these types of requirements, hardware components should be designed
efficiently and in a cost-effective way.
 Before drawing a deployment diagram, the following artifacts should be
identified
 Nodes
 Relationships among nodes
 Now-a-days software applications are very complex in nature. Software
applications can be standalone, web-based, distributed, mainframe-based
and many more
 Cont..
72

 An artifact represents a physical entity Examples: Model files, source files,

scripts, binary executable files.
 Node are Execution environments (virtual machine, app server, and other
“middleware”)
 Displays the configuration of run-time processing elements and the
software components, processes, and objects that reside within them.

Nodes are connected

by communication
paths to create
network systems
E.g. Consider a system that includes a Web server and two database
servers. Both database servers are identical: The first acts as a main server,
while the second acts as a redundant backup in case the first one fails. Users
use Web browsers to access data through the Web server. They also have
the option of using a proprietary client that accesses the databases directly.
Draw a UML deployment diagram representing the hardware/software
mapping of this system.
 Cont..
74
 e.g.
75

 The deployment diagram in Figure 8 shows that the users access the
 Reporting Tool by using a browser running on their local machine and
 connecting via HTTP over their company's intranet to the Reporting Tool.
 This tool physically runs on the Application Server named
 w3reporting.myco.com. The diagram shows the Reporting Tool component
 drawn inside of IBM WebSphere, which in turn is drawn inside of the node
 w3.reporting.myco.com. The Reporting Tool connects to its reporting
 database using the Java language to IBM DB2's JDBC interface, which then
 communicates to the actual DB2 database running on the server named
 db1.myco.com using native DB2 communication. In addition to talking to
 the reporting database, the Report Tool component communicates via
 SOAP over HTTPS to the Billboard Service.
76