SOUTHERN LEYTE STATE UNIVERSITY

COLLEGE OF COMPUTER STUDIES

AND INFORMATION TECHNOLOGY

Module Three: Unified Modeling Language (UML)

COURSE OVERVIEW

Course No.

Course Code IT 303

Descriptive Title System Integration and Architecture 1

Credit Units 3 Units

School Year/Term 1st Semester, AY: 2021-2022

Mode of Delivery Online and Modular Learning

Name of Instructor/ Professor Randy M. Siervo

Course Description This course will introduce to the student on how to design and
build systems and integrate them into an organization. This
knowledge area develops the skills to gather requirements, then
source, evaluate and integrate components into a single system,
and finally validate the system. It also covers the fundamentals
of project management and the interplay between IT
applications and organizational processes.

Course Outcomes Knowledge (Think)

1. Analyze the fundamental requirements and techniques in
building and integrating system and architecture into an
organization.
Skills (Do)
2. Perform the techniques in building and integrating
system and architecture to a specified requirements.
Values (Feel)
3. Adapt system integration and architecture in
implementing an enterprise platform.

SLSU Vision A high quality corporate science and technology university

SLSU Mission Produces S and T leaders and competitive professionals;

generate breakthrough research in S and T based disciplines;
transform and improve the quality of life in the communities in
the service area; and be self –sufficient and financially viable.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

MODULE GUIDE

In this module, we will

continue our exploration in
the world of Object-
Oriented Programming
(OOP). OOP-based
architecture proves to be
beneficial especially when
dealing with special types of
data which need to
be packaged into one entity.
What would you do if you
have so much
capability at your hand? Of
course, you will use it. This
ideology will be
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

covered in this module

together with the principles
that surround OOP. Hard
might it be at first, however
their important role in OOP’s
implementation
will be eviden
In this module, you will learn the concept in building your system, and will help you the basic
modeling requirements in system integration and architecture.

This module is divided into four (4) separate topics namely; 1.)Use case diagrams, 2.) Class
diagrams, 3.) Sequential diagram, and 4.)State. I would like to you finish the topics one by one, it
would be easy for you to understand because the topics are arranged accordingly to its procedures.

The previous module was all about the fundamental requirements & techniques in building
system integration and architecture. Your learned the architecture concepts, tradition approach to
system architecting, its properties of components, styles and system design.

PRE-TEST

Test I. Fill in the blanks

1. ___________ is a type of diagram used in computer science and related fields to describe the
behaviour if system.
2. ___________ commonly used by developers, model the interactions between objects in a single use
case.
3. ___________ are typically related to ‘actors’.
4. ___________ is a human or machine entity that interacts with the system to perform meaningful
work.
5. ___________ sequential description of the step taken to carry out the case.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

LEARNING PLAN

Intended Learning Outcome: Explain the modeling tools and methodologies in

system integration and architecture.

Enabling Learning Outcomes:

In this lesson, you will learn about the types of modeling in system integration and
architecture.
1. The Use Case Model
2. The Class diagrams
3. Sequential diagrams
4. State diagrams

Introduction
The Use Case Model describes the proposed functionality of the new system. A Use Case represents
a discrete unit of interaction between a user (human or machine) and the system. Use Case are
typically related to ‘actors’. An actor is a human or machine entity that interacts with the system to
perform meaningful work.
Class diagrams are the main building block in object-oriented modeling. They are used to show the
different objects in a system, their attributes, their operations and the relationships among them.
Sequence/Sequential diagram commonly used by developers, model the interactions between
objects in a single use case. They illustrate how the different parts of a system interact with each
other to carry out a function, and the order in which the interactions occur when a particular use
case is executed.
A state diagram is a type of diagram used in computer science and related fields to describe the
behaviour if system. State diagram require that the system described is composed of a finite
number of states; sometime, this is indeed the case, while at other times this is a reasonable
abstraction.

Key to Remember:

 Requirements – things that the use case must allow the user to do, such as ability to
update otder, to modify order & etc.
 Constraints – rules about what can be done and can’t be done.
 Scenarios – sequential description of the step taken to carry out the case.
 Scneario diagram – sequence diagram to depict the workflow – as above but graphically
portrayed.
 Actor – is a user of the system.
 Activity diagram – can also be used to model system – level functions.
 Synch state – allows the forking and joining of execution threads
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

 State machine – describe the dynamic behaviour of objects over time by modeling the
lifecycles of objects of each class.

Discussion:

LESSON 1: USE CASE MODEL

A use-case model is a model of how different types of users interact with the system to solve a
problem.  As such, it describes the goals of the users, the interactions between the users and the
system, and the required behavior of the system in satisfying these goals.

A use-case model consists of a number of model elements.  The most important model elements
are: use cases, actors and the relationships between them.

A use-case diagram is used to graphically depict a subset of the model to simplify communications. 
There will typically be several use-case diagrams associated with a given model, each showing a
subset of the model elements relevant for a particular purpose.  The same model element may be
shown on several use-case diagrams, but each instance must be consistent.   If tools are used to
maintain the use-case model, this consistency constraint is automated so that any changes to the
model element (changing the name for example) will be automatically reflected on every use-case
diagram that shows that element.

The use-case model may contain packages that are used to structure the model to simplify analysis,
communications, navigation, development, maintenance and planning.

Much of the use-case model is in fact textual, with the text captured in the Use-Case Specifications
that are associated with each use-case model element. These specifications describe the flow of
events of the use case.

The use-case model serves as a unifying thread throughout system development. It is used as the
primary specification of the functional requirements for the system, as the basis for analysis and
design, as an input to iteration planning, as the basis of defining test cases and as the basis for user
documentation  

Basic model elements

The use-case model contains, as a minimum, the following basic model elements.

Actor

A model element representing each actor. Properties include the actors name and brief
description..

Use Case

A model element representing each use case. Properties include the use case name and use case
specification.

Associations

Associations are used to describe the relationships between actors and the use cases they
participate in. This relationship is commonly known as a “communicates-association”.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Advanced model elements

The use-case model may also contain the following advanced model elements.

Subject

A model element that represents the boundary of the system of interest.  

Use-Case Package

A model element used to structure the use case model to simplify analysis, communications,
navigation, and planning.  If there are many use cases or actors, you can use use-case packages to
further structure the use-case model in much the same manner you use folders or directories to
structure the information on your hard-disk.

You can partition a use-case model into use-case packages for several reasons, including:

 To reflect the order, configuration, or delivery units in the finished system thus supporting
iteration planning.
 To support parallel development by dividing the problem into bite-sized pieces.
 To simplify communication with different stakeholders by creating packages for containing
use cases and actors relevant to a particular stakeholder.

Generalizations

A relationship between actors to support re-use of common properties.

Dependencies

A number of dependency types between use cases are defined in UML. In particular, <<extend>>
and <<include>>.

<<extend>> is used to include optional behavior from an extending use case in an extended use
case.

<<include>> is used to include common behavior from an included use case into a base use case in
order to support re-use of common behavior.

The latter is the most widely used dependency and is useful for:

 Factoring out behavior from the base use case that is not necessary for the understanding of
the primary purpose of the use case to simplify communications.
 Factoring out behavior that is in common for two or more use cases to maximize re-use,
simplify maintenance and ensure consistency.

Example Use-Case Diagram

Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Figure 1: ATM Use-Case Diagram

This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and
Maintenance Person), five use cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill
Machine and Validate User), three <<includes>> dependencies, and the associations between the
performing actors and the use cases.

The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the
customer is identified to the system. This behavior can be extracted to a new inclusion use case
called Validate User, which the three base use cases <<include>>. The base use cases are
independent of the method used for identification, and it is therefore encapsulated in the inclusion
use case. From the perspective of the base use cases, it does not matter whether the method for
identification is to read a magnetic bank card, or perform a retinal scan. They only depend on the
result of Validate Customer.

Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also
includes descriptions of each actor, descriptions of each use case, and use-case specifications for
each use case. 

LESSON 2. CLASS DIAGRAMS

Discussion:

Class diagrams are one of the most useful types of diagrams in UML as they clearly map out the
structure of a particular system by modeling its classes, attributes, operations, and relationships
between objects.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Benefits of class diagrams

Class diagrams offer a number of benefits for any organization. Use UML class diagrams to:

 Illustrate data models for information systems, no matter how simple or complex.
 Better understand the general overview of the schematics of an application.
 Visually express any specific needs of a system and disseminate that information
throughout the business.
 Create detailed charts that highlight any specific code needed to be programmed and
implemented to the described structure.
 Provide an implementation-independent description of types used in a system that are
later passed between its components.

Diagramming is quick and easy with Lucidchart. Start a free trial today to start creating and
collaborating.

Basic components of a class diagram

The standard class diagram is composed of three sections:

 Upper section: Contains the name of the class. This section is always required, whether
you are talking about the classifier or an object.
 Middle section: Contains the attributes of the class. Use this section to describe the
qualities of the class. This is only required when describing a specific instance of a class.
 Bottom section: Includes class operations (methods). Displayed in list format, each
operation takes up its own line. The operations describe how a class interacts with data.

Member access modifiers

All classes have different access levels depending on the access modifier (visibility). Here are the
access levels with their corresponding symbols:

 Public (+)
 Private (-)
 Protected (#)
 Package (~)
 Derived (/)
 Static (underlined)

Member scopes

There are two scopes for members: classifiers and instances.

Classifiers are static members while instances are the specific instances of the class. If you are
familiar with basic OO theory, this isn't anything groundbreaking.

Additional class diagram components

Depending on the context, classes in a class diagram can represent the main objects, interactions in
the application, or classes to be programmed. To answer the question "What is a class diagram in
UML?" you should first understand its basic makeup.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

 Classes: A template for creating objects and implementing behavior in a system. In UML, a
class represents an object or a set of objects that share a common structure and behavior.
They're represented by a rectangle that includes rows of the class name, its attributes, and
its operations. When you draw a class in a class diagram, you're only required to fill out the
top row—the others are optional if you'd like to provide more detail.
o Name: The first row in a class shape.
o Attributes: The second row in a class shape. Each attribute of the class is displayed
on a separate line.
o Methods: The third row in a class shape. Also known as operations, methods are
displayed in list format with each operation on its own line.
 Signals: Symbols that represent one-way, asynchronous communications between active
objects.
 Data types: Classifiers that define data values. Data types can model both primitive types
and enumerations.
 Packages: Shapes designed to organize related classifiers in a diagram. They are
symbolized with a large tabbed rectangle shape.
 Interfaces: A collection of operation signatures and/or attribute definitions that define a
cohesive set of behaviors. Interfaces are similar to classes, except that a class can have an
instance of its type, and an interface must have at least one class to implement it.
 Enumerations: Representations of user-defined data types. An enumeration includes
groups of identifiers that represent values of the enumeration.
 Objects: Instances of a class or classes. Objects can be added to a class diagram to
represent either concrete or prototypical instances.
 Artifacts: Model elements that represent the concrete entities in a software system, such as
documents, databases, executable files, software components, etc.
Interactions

The term "interactions" refers to the various relationships and links that can exist in class and
object diagrams. Some of the most common interactions include:

 Inheritance: The process of a child or sub-class taking on the functionality of a parent or

superclass, also known as generalization. It's symbolized with a straight connected line
with a closed arrowhead pointing towards the superclass.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

In this example, the object "Car" would inherit all of the attributes (speed, numbers of passengers,
fuel) and methods (go(), stop(), changeDirection()) of the parent class ("Vehicle") in addition to the
specific attributes (model type, number of doors, auto maker) and methods of its own class
(Radio(), windshieldWiper(), ac/heat()). Inheritance is shown in a class diagram by using a solid
line with a closed, hollow arrow.

 Bidirectional association: The default relationship between two classes. Both classes are
aware of each other and their relationship with the other. This association is represented
by a straight line between two classes.

In the example above, the Car class and RoadTrip class are interrelated. At one end of the line,
the Car takes on the association of "assignedCar" with the multiplicity value of 0..1, so when the
instance of RoadTrip exists, it can either have one instance of Car associated with it or no Cars
associated with it. In this case, a separate Caravan class with a multiplicity value of 0..* is needed to
demonstrate that a RoadTrip could have multiple instances of Cars associated with it. Since one Car
instance could have multiple "getRoadTrip" associations—in other words, one car could go on
multiple road trips—the multiplicity value is set to 0..*
 Unidirectional association: A slightly less common relationship between two classes. One
class is aware of the other and interacts with it. Unidirectional association is modeled with
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

a straight connecting line that points an open arrowhead from the knowing class to the
known class.

As an example, on your road trip through Arizona, you might run across a speed trap where a
speed cam records your driving activity, but you won't know about it until you get a notification in
the mail. It isn't drawn in the image, but in this case, the multiplicity value would be 0..* depending
on how many times you drive by the speed cam.

Class diagram examples

Creating a class diagram to map out process flows is easy. Consider the two examples below as you
build your own class diagrams in UML.

Class diagram for a hotel management system

A class diagram can show the relationships between each object in a hotel management system,
including guest information, staff responsibilities, and room occupancy. The example
below provides a useful overview of the hotel management system. Get started on a class diagram
by clicking the template below.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

LESSON 3. SEQUENTIAL DIAGRAM

Discussion:
Sequence Diagrams are interaction diagrams that detail how operations are carried out. They
capture the interaction between objects in the context of a collaboration. Sequence Diagrams are
time focus and they show the order of the interaction visually by using the vertical axis of the
diagram to represent time what messages are sent and when.
Sequence Diagrams captures:
 the interaction that takes place in a collaboration that either realizes a use case or an
operation (instance diagrams or generic diagrams)
 high-level interactions between user of the system and the system, between the system
and other systems, or between subsystems (sometimes known as system sequence
diagrams)

Purpose of Sequence Diagram

 Model high-level interaction between active objects in a system
 Model the interaction between object instances within a collaboration that realizes a use
case
 Model the interaction between objects within a collaboration that realizes an operation
 Either model generic interactions (showing all possible paths through the interaction) or
specific instances of a interaction (showing just one path through the interaction)

Sequence Diagrams at a Glance

Sequence Diagrams show elements as they interact over time and they are organized according to

object (horizontally) and time (vertically):

Object Dimension
 The horizontal axis shows the elements that are involved in the interaction
 Conventionally, the objects involved in the operation are listed from left to right according
to when they take part in the message sequence. However, the elements on the horizontal
axis may appear in any order
Time Dimension
 The vertical axis represents time proceedings (or progressing) down the page.

Note that:

Time in a sequence diagram is all a about ordering, not duration. The vertical space in an

interaction diagram is not relevant for the duration of the interaction.

SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Sequence Diagram Example: Hotel System

Sequence Diagram is an interaction diagram that details how operations are carried out -- what

messages are sent and when. Sequence diagrams are organized according to time. The time

progresses as you go down the page. The objects involved in the operation are listed from left to

right according to when they take part in the message sequence.

Below is a sequence diagram for making a hotel reservation. The object initiating the sequence of

messages is a Reservation window.

Actor
 a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data)
 external to the subject (i.e., in the sense that an instance of an actor is not a part of the instance of its corre
 represent roles played by human users, external hardware, or other subjects.

Note that:
 An actor does not necessarily represent a specific physical entity but merely a particular role of some entit
 A person may play the role of several different actors and, conversely, a given actor may be played by mult
person.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Lifeline
 A lifeline represents an individual participant in the Interaction.

Activations
 A thin rectangle on a lifeline) represents the period during which an element is performing an operation.
 The top and the bottom of the of the rectangle are aligned with the initiation and the completion time resp

Call Message
 A message defines a particular communication between Lifelines of an Interaction.
 Call message is a kind of message that represents an invocation of operation of target lifeline.

Return Message
 A message defines a particular communication between Lifelines of an Interaction.
 Return message is a kind of message that represents the pass of information back to the caller of a corresp
message.

Self Message
 A message defines a particular communication between Lifelines of an Interaction.
 Self message is a kind of message that represents the invocation of message of the same lifeline.

Recursive Message
 A message defines a particular communication between Lifelines of an Interaction.
 Recursive message is a kind of message that represents the invocation of message of the same lifeline. It's
activation on top of the activation where the message was invoked from.

Create Message
 A message defines a particular communication between Lifelines of an Interaction.
 Create message is a kind of message that represents the instantiation of (target) lifeline.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Destroy Message
 A message defines a particular communication between Lifelines of an Interaction.
 Destroy message is a kind of message that represents the request of destroying the lifecycle of target lifelin

Duration Message
 A message defines a particular communication between Lifelines of an Interaction.
 Duration message shows the distance between two time instants for a message invocation.

Note

A note (comment) gives the ability to attach various remarks to elements. A comment carries no semantic force, b

information that is useful to a modeler.

Message and Focus of Control

 An Event is any point in an interaction where something occurs.
 Focus of control: also called execution occurrence, an execution occurrence
 It shows as tall, thin rectangle on a lifeline)
 It represents the period during which an element is performing an operation. The top and
the bottom of the rectangle are aligned with the initiation and the completion time
respectively.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Sequence Fragments
 UML 2.0 introduces sequence (or interaction) fragments. Sequence fragments make it
easier to create and maintain accurate sequence diagrams
 A sequence fragment is represented as a box, called a combined fragment, which encloses a
portion of the interactions within a sequence diagram
 The fragment operator (in the top left cornet) indicates the type of fragment
 Fragment types: ref, assert, loop, break, alt, opt, neg

Operator Fragment Type

alt Alternative multiple fragments: only the one whose condition is true will execute.

Optional: the fragment executes only if the supplied condition is true. Equivalent to an alt only
opt
with one trace.

par Parallel: each fragment is run in parallel.

loop Loop: the fragment may execute multiple times, and the guard indicates the basis of iteration.

region Critical region: the fragment can have only one thread executing it at once.

neg Negative: the fragment shows an invalid interaction.

Reference: refers to an interaction defined on another diagram. The frame is drawn to cover the
ref
lifelines involved in the interaction. You can define parameters and a return value.

Sequence diagram: used to surround an entire sequence diagram.

Note That:
 It is possible to combine frames in order to capture, e.g., loops or branches.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

 Combined fragment keywords: alt, opt, break, par, seq, strict, neg, critical, ignore,
consider, assert and loop.
 Constraints are usually used to show timing constraints on messages. They can apply to the
timing of one message or intervals between messages.
Combined Fragment Example

Sequence Diagram for Modeling Use Case Scenarios

User requirements are captured as use cases that are refined into scenarios. A use case is a

collection of interactions between external actors and a system. In UML, a use case is:

"the specification of a sequence of actions, including variants, that a system (or entity) can perform,

interacting with actors of the system."

A scenario is one path or flow through a use case that describes a sequence of events that occurs

during one particular execution of a system which is often represented by a sequence diagram.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Sequence Diagram - Model before Code

Sequence diagrams can be somewhat close to the code level, so why not just code up that algorithm

rather than drawing it as a sequence diagram?

 A good sequence diagram is still a bit above the level of the real code
 Sequence diagrams are language neutral
 Non-coders can do sequence diagrams
 Easier to do sequence diagrams as a team
 Can be used for testing and/or UX Wireframing

LESSON 4. STATE DIAGRAM

Discussion:
A state diagram is used to represent the condition of the system or part of the system at finite
instances of time. It’s a behavioral diagram and it represents the behavior using finite state
transitions. State diagrams are also referred to as State machines and State-chart Diagrams.
These terms are often used interchangeably. So simply, a state diagram is used to model the
dynamic behavior of a class in response to time and changing external stimuli. We can say that each
and every class has a state but we don’t model every class using State diagrams. We prefer to
model the states with three or more states.

Uses of statechart diagram –

 We use it to state the events responsible for change in state (we do not show what
processes cause those events).
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

 We use it to model the dynamic behavior of the system .

 To understand the reaction of objects/classes to internal or external stimuli.
Firstly let us understand what are Behavior diagrams? There are two types of diagrams
in UML :
1. Structure Diagrams – Used to model the static structure of a system, for example-
class diagram, package diagram, object diagram, deployment diagram etc.
2. Behavior diagram – Used to model the dynamic change in the system over time.
They are used to model and construct the functionality of a system. So, a behavior
diagram simply guides us through the functionality of the system using Use case
diagrams, Interaction diagrams, Activity diagrams and State diagrams.
Difference between state diagram and flowchart –
The basic purpose of a state diagram is to portray various changes in state of the class and
not the processes or commands causing the changes. However, a flowchart on the other
hand portrays the processes or commands that on execution change the state of class or an
object of the class.

The state diagram above shows the different states in which the verification sub-system or class
exist for a particular system.

Basic components of a statechart diagram –

1. Initial state – We use a black filled circle represent the initial state of a System or a class
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

2. Transition – We use a solid arrow to represent the transition or change of control from
one state to another. The arrow is labelled with the event which causes the change in state.

3. State – We use a rounded rectangle to represent a state. A state represents the conditions
or circumstances of an object of a class at an instant of time.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

4. Fork – We use a rounded solid rectangular bar to represent a Fork notation with incoming
arrow from the parent state and outgoing arrows towards the newly created states. We use
the fork notation to represent a state splitting into two or more concurrent states.

5. Join – We use a rounded solid rectangular bar to represent a Join notation with incoming
arrows from the joining states and outgoing arrow towards the common goal state. We use
the join notation when two or more states concurrently converge into one on the occurrence
of an event or events.

6. Self transition – We use a solid arrow pointing back to the state itself to represent a self
transition. There might be scenarios when the state of the object does not change upon the
occurrence of an event. We use self transitions to represent such cases.
 SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

7. Composite state – We use a rounded rectangle to represent a composite state also.We
represent a state with internal activities using a composite state.

8. Final state – We use a filled circle within a circle notation to represent the final state in a state
machine diagram.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

Steps to draw a state diagram –

1. Identify the initial state and the final terminating states.

2. Identify the possible states in which the object can exist (boundary values corresponding to
different attributes guide us in identifying different states).
3. Label the events which trigger these transitions.
Example – state diagram for an online order –

Figure – state diagram for an online order

The UMl diagrams we draw depend on the system we aim to represent. Here is just an example of
how an online ordering system might look like :
1. On the event of an order being received, we transit from our initial state to Unprocessed
order state.
2. The unprocessed order is then checked.
3. If the order is rejected, we transit to the Rejected Order state.
4. If the order is accepted and we have the items available we transit to the fulfilled order state.
5. However if the items are not available we transit to the Pending Order state.
6. After the order is fulfilled, we transit to the final state. In this example, we merge the two
states i.e. Fulfilled order and Rejected order into one final state.

Summary:
Summary

 A use-case model is a model of how different types of users interact with the system to
solve a problem.  As such, it describes the goals of the users, the interactions between the
users and the system, and the required behavior of the system in satisfying these goals.
SOUTHERN LEYTE STATE UNIVERSITY
COLLEGE OF COMPUTER STUDIES
AND INFORMATION TECHNOLOGY

 Class diagrams are one of the most useful types of diagrams in UML as they clearly map out
the structure of a particular system by modeling its classes, attributes, operations, and
relationships between objects.

 Sequence Diagrams are interaction diagrams that detail how operations are carried out.
They capture the interaction between objects in the context of a collaboration. Sequence
Diagrams are time focus and they show the order of the interaction visually by using the
vertical axis of the diagram to represent time what messages are sent and when.
 A state diagram is used to represent the condition of the system or part of the system at
finite instances of time.

Post Test

1. Create a UML diagrams (use case, class, sequence and state diagrams) of online shopping.

References

http://www.utm.mx/~caff/doc/OpenUPWeb/openup/guidances/concepts/
use_case_model_CD178AF9.html
https://www.lucidchart.com/pages/uml-class-diagram
https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-sequence-
diagram/
https://www.geeksforgeeks.org/unified-modeling-language-uml-state-diagrams/