Artificial Intelligence

Borana University
College of Natural and Computational Science

Department of Computer Science

Course: Software Engineering l In

Chapter: Two
Unified Modeling Language(UML))
 Introduction
 Unified Modeling Language (UML) is a general-purpose graphical
modeling language. The main aim of UML is to define a standard way to
visualize the way a system has been designed .
 It is quite similar to blueprints used in other fields of engineering.
 UML is not a programming language, it is rather a visual language.
 A modeling language is a language whose vocabulary and rules focus on the
conceptual and physical representation of a system
 We use UML diagrams to portray the behavior and structure of a system.
 UML helps software engineers, businessmen, and system architects with
modeling, design, and analysis.
 The Object Management Group (OMG) adopted Unified Modelling
Language as a standard in 1997. It’s been managed by OMG ever since.
 The International Organization for Standardization (ISO) published UML as
an approved standard in 2005. UML has been revised over the years and is
reviewed periodically.
 Introduction(Cont..)
 The goal of UML is to provide a standard notation that can be used by all
object-oriented methods and to select and integrate the best elements of
precursor notations.
Usages of UML:
 UML is used in the course to
i. Document designs, design patterns / frameworks
ii. Represent different views/aspects of design - visualize and construct
designs, static / dynamic / deployment / modular aspects
iii. Provide a next-to-precise, common, language –specify visually for the
benefit of analysis, discussion, comprehension...
 The UML has been accepted as a standard by the Object Management
Group
 (OMG). The OMG is a non-profit organization with about 700 members
that sets standards for distributed object-oriented computing.
 Building Blocks of the UML
 To understand the UML, you need to form a conceptual model of the
language, and this requires learning three major elements
 These elements: the UML's basic building blocks, the rules that dictate how
those building blocks may be put together, and some common mechanisms
that apply throughout the UML.
 The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams
 Things are the abstractions that are first-class citizens in a model, where
relationships tie these things together and diagrams group interesting
collections of things.
 Things in the UML
 There are four kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
 These things are the basic object-oriented building blocks of the UML and
we use them to write well-formed models.
Structural things
 Structural things is nouns that depicts the static behavior of a model.
 They display the physical and conceptual components. They include class,
object, interface, node, collaboration, component, and a use case.
A class:- is a description of a set of objects that share the same attributes,
operations, relationships, and semantics. A class implements one or more
interfaces.
 Structural things(Cont..)
 Graphically, a class is rendered as a rectangle, usually including its name,
attributes, and operations, as in Figure below

Object:- An individual that describes the behavior and the functions of a

system. The notation of the object is similar to that of the class; the only
difference is that the object name is always underlined and its notation is given
below.
 Structural things(Cont..)
Interface:- is a collection of operations that specify a service of a class or
component. An interface therefore describes the externally visible
behavior of that element.
 An interface might represent the complete behavior of a class or component
or only a part of that behavior. An interface defines a set of operation
specifications (that is, their signatures) but never a set of operation
implementations.
 The declaration of an interface looks like a class with the keyword
«interface» above the name; attributes are not relevant, except sometimes to
show constants.
 Structural things(Cont..)
Collaboration: It represents the interaction between things that is done to
meet the goal. Also known as a communication diagram.

Use case: Use case is the core concept of object-oriented modeling. It

portrays a set of actions executed by a system to achieve the goal(functionality
of the system). It represented by oval shep as shown below
 Structural things(Cont..)
Actor: It comes under the use case diagrams. It is an object that interacts
with the system(external entity that have interaction with the system), for
example, a user.

Component : Component describes the physical part of a system.

A node: represents a computational resource in the runtime(physical element

that exists at run time).
 Behavioral things
 Behavioral things are the dynamic parts of UML models. These are the verbs of a
model, representing behavior over time and space.
 In all, there are three primary kinds of behavioral things.
Interaction − Interaction is defined as a behavior that consists of a group of
messages exchanged among elements to accomplish a specific task.
 An interaction involves a number of other elements, including messages, actions,
and connectors (the connection between objects).

A state machine: is designed to track an object's life cycle, particularly when the
object's state is significant. It outlines the series of states that an object undergoes in
reaction to external factors, known as events, which are responsible for state
changes.
 Behavioral things(Cont…)
Grouping Things: The organizational part of the UML model; provides a
higher level of abstraction (granularity).
 Package - a general-purpose element that comprises UML elements - structural,
behavioral or even grouping things.
 Packages are conceptual groupings of the system and need not necessarily be
implemented as cohesive software modules.

Annotational Things
 Annotational features pertain to a tool that records observations, explanations,
and feedback regarding UML model components.
 The sole Annotational feature is known as a Note, which is utilized to display
comments, restrictions, and other details pertaining to a UML element.
 Relationships
 Relationship articulates the meaning of the links between things. 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 in UML.
1. Dependency
2. Association
3. Generalization
4. Realization
Dependency : a dependency is a semantic relationship between two model
elements in which a change to one element (the independent one) may affect
the semantics of the other element (the dependent one).
 Graphically, a dependency is rendered as a dashed line

 Arrow-head points to the independent thing or entity.

 2.Association
 An Association in a UML model is a collection of connections that link the
various elements together.
 It additionally specifies the number of entities that are involved in the
relationship. It is denoted by a dotted line with arrowheads on both sides to
describe the relationship with the element on both sides.

3.Generalization: It portrays the relationship between a general thing (a

parent class or superclass) and a specific kind of that thing (a child class or
subclass). It is used to describe the concept of inheritance. It is denoted by a
straight line followed by an empty arrowhead at one side.
4.Realizatio: Realization refers to the connection between two elements,
where one element describes certain responsibilities that have not been
implemented, and the other element implements them.
This relationship specifically applies to interfaces.
 UML Diagrams
 A UML diagram is the graphical presentation of a set of elements, most
often rendered as a connected graph of vertices (things) and paths
(relationships).
 There are different types of UML diagrams that are available in UML 2.0,
such that each diagram has its own set of a symbol.
 And each diagram manifests a different dimension, perspective, and view of
the system. There are nine commonly used UML diagrams
 Use Case Diagrams
 Class Diagrams
 Object Diagram
 Sequence Diagrams
 Collaboration Diagram
 State chart Diagrams
 Activity Diagrams
 Component Diagram
 Deployment Diagram
 Use case Diagram
 A use case diagram is used to represent the dynamic behavior of a system. It
encapsulates the system's functionality by incorporating use cases, actors, and their
relationships. In use case diagram, there should be some internal or external factors
for making the interaction which called actor.
 It models the tasks, services, and functions required by a system/subsystem of an
application.
 It depicts the high-level functionality of a system and also tells how the user handles
a system.
Purpose of Use Case Diagrams
 The main purpose of a use case diagram is to portray the dynamic aspect of a system.
It accumulates the system's requirement, which includes both internal as well as
external. Following are the purposes of a use case diagram given below:
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the system.
4.It represents the interaction between the actors
 Use Case Diagram(Cont..)
How to Draw a Use Case Diagram?
 Use case diagrams are considered for high level requirement analysis of a system. In
use case, actors can be a human user, some internal applications, or may be some
external applications.
 When we are planning to draw a use case diagram, we should have the following
items identified.
(i). Functionalities to be represented as use case
(ii). Actors
(iii).Relationships among the use cases and actors.
Example of a Use Case Diagram
 A use case diagram depicting the Online Shopping website is given on the next
slide.
 The top-level uses(functionality) are; View Items, Make Purchase, Checkout, Client
Register,
 Internal or external, entities that have interaction with the system(actors) are;
 Customer(New, registered),paypal, Serv Authentication, I provider, Cr pay Service
Use Case Diagram(Cont..)
 Class Diagram
 The class diagram depicts a static view of an application. It represents the types of
objects residing in the system and the relationships between them.
 A class consists of its objects, and also it may inherit from other classes. A class
diagram is used to visualize, describe, document various different aspects of the
system, and also construct executable software code.
 It shows the attributes, classes, functions, and relationships to give an overview of
the software system.
 It constitutes class names, attributes, and functions in a separate compartment that
helps in software development.
Purpose of Class Diagrams
 It analyses and designs a static view of an application.
 It describes the major responsibilities of a system.
 It is a base for component and deployment diagrams.
 It incorporates forward and reverse engineering.
 Class Diagram(Cont..)
Vital Components of a Class Diagram
 The class diagram is made up of three sections are;
 Upper Section Class name
 Middle Section  Attributes
 Lower Section Methods
How to draw a Class Diagram?
 Some key points that are needed to keep in mind while drawing a class diagram are
given below:
(1)To describe a complete aspect of the system, it is suggested to give a meaningful
name to the class diagram
(2) The objects and their relationships should be acknowledged in advance.
(3) The attributes and methods (responsibilities) of each class must be known.
(4) A minimum number of desired properties should be specified as more number
of the unwanted property will lead to a complex diagram.
 Class Diagram(Cont..)
(5)Notes can be used as and when required by the developer to describe the
aspects of a diagram.
(6) The diagrams should be redrawn and reworked as many times to make it
correct before producing its final version.
Purpose of Class Diagrams
 Following are the purpose of class diagrams
(1) It analyses and designs a static view of an application.
(2) It describes the major responsibilities of a system.
(3) It is a base for component and deployment diagrams.
(4) It incorporates forward and reverse engineering.
 Class Diagram(Cont..)
A class diagram describing the sales order system is given below.
 Object Diagram
 Object diagrams are dependent on the class diagram as they are derived from
the class diagram. It represents an instance of a class diagram.
 The objects help in portraying a static view of an object-oriented system at a
specific instant.
Purpose of Object Diagram
 The object diagram holds the same purpose as that of a class diagram.
 The class diagram provides an abstract view which comprises of classes and
their relationships, whereas the object diagram represents an instance at a
particular point of time. Generally, the purpose of Object diagram are;
 It is used to perform forward and reverse engineering.
 It is used to understand object behavior and their relationships practically.
 It is used to get a static view of a system.
 It is used to represent an instance of a system.
 Object Diagram (Cont..)
Applications of Object Diagrams
 To build a prototype of a system.
 To model complex data structures.
 To perceive the system from a practical perspective.
 Reverse engineering.
Example of Object Diagram
 Continue
Class vs. Object Diagram
 Sequence Diagram
 The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram.
 It helps in envisioning several dynamic scenarios. It portrays the communication
between any two lifelines as a time-ordered sequence of events, such that these
lifelines took part at the run time.
 In UML, the lifeline is represented by a vertical bar, whereas the message flow is
represented by a vertical dotted line that extends across the bottom of the page.
Purpose of a Sequence Diagram
(1) To model high-level interaction among active objects within a system.
(2) To model interaction among objects inside a collaboration realizing a use case.
(3) It either models generic interactions or some certain instances of interaction.
Benefits of a Sequence Diagram
 It explores the real-time application.
 It depicts the message flow between the different objects.
 It has easy maintenance and Implement both forward and reverse engineering.
 It is easy to generate and it can easily update as per the new change in the system
 Sequence Diagram(Cont..)
The drawback of a Sequence Diagram
 In the case of too many lifelines, the sequence diagram can get more complex.
 The incorrect result may be produced, if the order of the flow of messages changes.
 Since each sequence needs distinct notations for its representation, it may make the diagram
more complex.
 The type of sequence is decided by the type of message.
Sequence Fragments
 Sequence fragments have been introduced by UML 2.0, which makes it quite easy
for the creation and maintenance of an accurate sequence diagram.
 It is represented by a box called a combined fragment, encloses a part of interaction
inside a sequence diagram.
 The type of fragment is shown by a fragment operator.
Sequence Diagram (Types of Fragments)
 Example of a Sequence Diagram
 An example of a high-level sequence diagram for online bookshop is given below
Example of a Sequence Diagram2
 Collaboration Diagram
 The collaboration diagram is used to show the relationship between the objects in a
system.
 Both the sequence and the collaboration diagrams represent the same information
but differently.
 Instead of showing the flow of messages, it depicts the architecture of the object
residing in the system as it is based on object-oriented programming.
 An object consists of several features. Multiple objects present in the system are
connected to each other.
 The collaboration diagram, which is also known as a communication diagram, is
used to portray the object's architecture in the system.
Notations of a Collaboration Diagram
 Objects
 Actors
 Links
 Messages
Components of collaboration Diagram
 When to use a Collaboration Diagram
 To model collaboration among the objects or roles that carry the functionalities of use cases
and operations.
 To model the mechanism inside the architectural design of the system.
 To capture the interactions that represent the flow of messages between the objects and the
roles inside the collaboration.
 To model different scenarios within the use case or operation, involving a collaboration of
several objects and interactions.
 To support the identification of objects participating in the use case.
 In the collaboration diagram, each message constitutes a sequence number, such that the
top-level message is marked as one and so on.
Steps for creating a Collaboration Diagram
 Determine the behavior for which the realization and implementation are specified.
 Discover the structural elements that are class roles, objects, and subsystems for
performing the functionality of collaboration.
 Choose the context of an interaction: system, subsystem, use case, and operation.
 Think through alternative situations that may be involved. Implementation of a
collaboration diagram at an instance level, if needed.
 A specification level diagram may be made in the instance level sequence diagram
for summarizing alternative situations.
Example of Collaboration Diagram
 State Machine (Chart) Diagram
 The state machine diagram is also called the State chart or State Transition
diagram, which shows the order of states underwent by an object within the
system.
 It captures the software system's behavior. It models the behavior of a class, a
subsystem, a package, and a complete system.
 It tends out to be an efficient way of modeling the interactions and collaborations
in the external entities and the system.
 It models event-based systems to handle the state of an object. It also defines
several distinct states of a component within the system. Each object/component
has a specific state. The following are the types of a state machine diagram.
(i) Behavioral state machine :-the behavioral state machine diagram records
the behavior of an object within the system. It depicts an implementation of a
particular entity. It models the behavior of the system.
(ii) Protocol state machine :-It captures the behavior of the protocol. The
protocol state machine depicts the change in the state of the protocol and
parallel changes within the system. But it does not portray the implementation
of a particular component.
 Notation of a State Machine Diagram
Types of State
The UML consist of three states:
(i).Simple state: It does not constitute any
substructure.
(ii).Composite state: It consists of nested states (sub
states), such that it does not contain more than one
initial state and one final state. It can be nested to any
level.
(iii).Submachine state: The submachine state is
semantically identical to the composite state, but it can
be reused.
Example of state Machine Diagram
 Activity Diagram
 Activity diagram is another important diagram in UML to describe the dynamic
aspects of the system.
 Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system.
 The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent. Activity diagrams deal with all type of flow
control by using different elements such as fork, join, etc.
The purpose of an activity diagram can be described as:-
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.
Before drawing an activity diagram, we should identify the following elements:-
 Activities
 Association
 Conditions
 Constraints
 Activity Diagram(Cont..)
Following diagram is drawn with the four main activities
 Send order by the customer
 Receipt of the order
 Confirm the order
 Dispatch the order
 When to use an Activity Diagram
 An activity diagram can be used to portray business processes and
workflows. Also, it used for modeling business as well as the software.
(1).To graphically model the workflow in an easier and understandable way.
(2).To model the execution flow among several activities.
(3).To model comprehensive information of a function or an algorithm
employed within the system.
(4).To model the business process and its workflow.
(5).To envision the dynamic aspect of a system.
(6).To generate the top-level flowcharts for representing the workflow of an
application.
(7).To represent a high-level view of a distributed or an object-oriented
system.
 Component Diagram
 Component diagrams are different in terms of nature and behavior.
Component diagrams are used to model the physical aspects of a system.
 Physical aspects are the elements such as executables, libraries, files,
documents, etc. which reside in a node.
 Component diagrams are used to visualize the organization and relationships
among components in a system. These diagrams are also used to make
executable systems.
 It does not describe the functionality of the system but it describes the
components used to make those functionalities.
 Component diagrams can also be described as a static implementation view
of a system. Static implementation represents the organization of the
components at a particular moment.
 A single component diagram cannot represent the entire system but a
collection of diagrams is used to represent the whole.
 Example of a Component Diagram1
 A component diagram for an online shopping system is given below:
Example of a Component Diagram2
 Deployment Diagram
 The deployment diagram visualizes the physical hardware on which the software
will be deployed. It portrays the static deployment view of a system. It involves
the nodes and their relationships.
 It maps the software architecture created in design to the physical system
architecture, where the software will be executed as a node. Since it involves
many nodes, the relationship is shown by utilizing communication path.
Purpose of Deployment Diagram
Following are the main purposes of deployment diagram enlisted below:
 To envision the hardware topology of the system.
 To represent the hardware components on which the software components are
installed.
 To describe the processing of nodes at the runtime.
The deployment diagram consist of the following notations:
 A component
 An artifact
 An interface and A node
Symbol and notation of Deployment Diagram
Example of Deployment Diagram1
Example of Deployment Diagram2
 When to use a Deployment Diagram
 The deployment diagram is mostly employed by network engineers, system
administrators, etc. with the purpose of representing the deployment of
software on the hardware system.
 It envisions the interaction of the software with the hardware to accomplish
the execution.
Deployment diagrams can be used for the followings
 To model the network and hardware topology of a system.
 To model the distributed networks and systems.
 Implement forwarding and reverse engineering processes.
 To model the hardware details for a client/server system.
 For modeling the embedded system.