University of 8 May 1945, Guelma
MISM Faculty
Computer Science Department
Information Systems
Chapter 3 : Unified Modeling Language (UML)
Dr. ABDELMOUMENE Hiba
[email protected] [email protected]Concerned students :
1st year professional bachelor’s degree –NTW 2024/2025
Introduction
❏ The complexity of software has risen proportionally to the demand for software products. Projects were
beginning to require more code, resources, and engineers to complete. Furthermore, due to the growing
complexity, clear and active communication needed to be used to ensure the success of the project.
❏ In response, standard modeling systems were developed, the most common of which is UML (Unified
Modeling Language). UML continues to be at the forefront of popular modeling systems today being the
standard “software blueprint language”.
❏ UML provides a way for anyone involved in the software project, including programmers, business analysts,
and clients to share a common understanding and vocabulary when discussing the details of the software
project. UML has foundations in the object-oriented paradigm, allowing for the central concepts of software
engineering to be a fundamental part of the system.
What is UML ?
❏ Unified Modeling Language (UML) – a family of graphical notations, which is based on a unified metamodel. It
helps in the specification and design of software systems, especially systems built using object-oriented (OO)
technology.
❏ The UML is called a modeling language, not a method. Most methods consist, at least in principle, of both a
modeling language and a process. The modeling language is the (mainly graphical) notation that methods use
to express designs. The process is their advice on what steps to take in doing a design.
❏ UML is a relatively open standard, which is under the control of the group OMG (Object Management Group),
an open consortium of various companies. OMG group has been formed to create standards that support cross-
system interaction, such as the interaction of object-oriented systems.
❏ UML appeared in 1997 as a result of the unification of a plurality of object-oriented graphical modeling
languages that developed in the late 80's and early 90's.
History
❏ Unified Modeling Language (UML) was conceived in the 1990s as a standardized way to visually represent the
design of software systems.
1) Origins (Early to Mid-1990s): UML's origins can be traced back to the work of Grady Booch, Ivar Jacobson, and
James Rumbaugh, who were each working on their own methodologies for software design and development.
Booch had developed the Booch method, Jacobson had developed Object-Oriented Software Engineering
(OOSE), and Rumbaugh had developed the Object Modeling Technique (OMT).
2) Unification Efforts (1994-1996): In 1994, these three leading figures in software engineering joined forces to
create a unified modeling language. This collaboration resulted in the creation of the Unified Modeling
Language (UML), which aimed to combine the best practices and concepts from their individual methodologies.
History
3) UML 1.0 (1997): The first version of UML, known as UML 1.0, was released in 1997. It included a set of
standardized diagrams and notations for representing various aspects of software systems, such as classes,
objects, relationships, use cases, and more. UML 1.0 established the foundation for subsequent versions.
4) UML 2.0 (2005): The next major milestone was the release of UML 2.0 in 2005. This version introduced several
improvements and enhancements, including a more comprehensive set of diagrams, better support for modeling
complex systems, and increased flexibility in modeling concepts.
5) OMG Standardization (1997-Present): The Object Management Group (OMG), an international consortium, took
over the standardization and further development of UML after its initial release. OMG has continued to evolve
UML over the years, with contributions from various industry experts and practitioners.
UML diagrams
❏ Language UML in its current state defines a notation and metamodel. The notation is a set of graphic elements that are
used in the models; It is the syntax of the modeling language. Metamodel – a diagram defining the concept of language.
❏ A diagram is a graphic representation of a set of elements that make up a system. In most cases, it takes the form of a
connected graph, where vertices correspond to elements and arcs to relationships. A diagram provides the user with a
means of visualizing and manipulating modeling elements.
❏ The UML metamodel provides a range of tools for representing all the elements of the object world (class, object ... ...)
and the links between them.
UML diagrams
❏ UML was designed to create a standardized modeling language that follows the following principles:
1. Programming language independent
2. Development process independent
3. Could support higher-level development concepts
4. Extensible and able to be specialized to specific projects
5. Integrated various best practices from the field of software engineering
6. Was expressive and ready-to-use and able to provide for the creation of useful, meaningful models.
UML diagrams
❏ UML provides a set of standardized diagrams that represent different aspects of a software system, such as
requirements, structure, behavior, and interactions between components. Over time, UML has evolved into its
current version, UML 2.5, which includes more than 13 different types of diagrams.
❏ UML diagrams follow two complementary classifications :
❏ Based on system perspective: Structural (static) vs. Behavioral (dynamic).
❏ Based on modeling purpose: Functional (system actions), Structural (system configuration), and Dynamic
(system functionality construction).
UML diagrams
❏ From system perspective
1. Structure Diagrams (static view): These diagrams describe the configuration and organization of a system, focusing on
its components and relationships rather than its behavior. They align with the structural and static axis of UML modeling:
Class, Object, Package, Composite Structure, Component, Deployment, and Profile Diagrams.
2. Behavior Diagrams (dynamic view): These diagrams capture the behavior and interactions within a system, representing
how different components function over time. They align with the functional and dynamic axes of UML modeling: Use
Case, Activity, State Machine, and Interaction Diagrams (Sequence Diagram, Communication Diagram, Timing Diagram).
UML diagrams
UML diagrams
❏ From modeling perspective
1. Functional axis: represents the actions performed by the system to be built: Use case, Sequence, Activity
diagrams.
2. Static axis: describes the system's configuration: Class, Object, Package, Composite Structure, Component,
Deployment diagrams.
3. Dynamic axis: focuses on the construction of the system's functionalities: State Machine, Activity, Sequence
diagrams.
UML diagrams
Basic concepts
❏ Objects : an object is anything that we can describe in the real world and subsequently model. Anything you
point at, you can describe the general properties of it, including any operations (actions) that it can perform. For
example,
❏ The top box details the name of the class and the type (instantiating class). The object Fire Truck is an instance of
the Truck class. The second box details the attributes of the object. In this example, there is one attribute color
with a value of red.
Basic concepts
❏ Class: A class defines how an object is to be built, which is why many refer to it as a blueprint. No architect would dare build a building or
other object without first having a design in place. Using the class blueprint, we can build as many objects as needed within memory
limitations. The things built (created) from the blueprint are objects.
❏ Based on the example of ‘Fire_Truck’ UML provides another way to view this abstraction as a class diagram. The Fire Truck class was
instantiated from the base class Truck. The class diagram representing Truck lists important information about the class.
❏ The top box holds the class name, the middle box holds the class attributes, and the bottom box holds the class methods. There are
several symbols used to represent critical information about the attributes and methods. The following symbols precede attributes and
methods.
1. ‘+’ symbol denotes a public attribute/method.
2. ‘#’ symbol denotes a protected attribute/method.
3. ‘-‘ symbol denotes a private attribute/method.
Basic concepts
❏ Each attribute/method is separated into two parts by a ‘:’ symbol. The first part denotes the attribute’s name and
the second part denotes the type of the attribute. The schema for a method follows the same format but maybe a
bit more complicated due to the additional parenthesis. The information enclosed in the parenthesis denotes the
formal attributes of the method. If there are no attributes listed in the parenthesis, the method takes no
parameters.
❏ The second part of the method after the ‘:’ denotes the return type
Of the method. For example, the public honk method in
the example takes no parameters and returns a sound object.
Basic concepts
❏ Actors: An actor is an external entity, such as an organization or person that interacts with a software system. An
actor is a role played by these entities interacting with the system. For example, when designing an ATM for a
bank, an actor could be the individual who interacts with the system to perform an action. Actors have unique
names to properly identify them within the system, similar to objects.
❏ Example 1. shows the relationship that an actor has with a system. The oval ‘Make Appointment’ represents a use
case that happens in response to an externally initialized event. The event in question is the line connecting the
actor, such as a patient, to the use case.
Basic concepts
❏ Example 2. depicts a point of-sale system at a convenience store. The clerk starts by initially interacting with the system.
Next, the customer must interact with the system, for example, when paying with a debit card. They must interact with
the system to enter their identification number. The actor-use case standard provides a convenient way for both clients
and the software engineering team to visualize and discuss the external interactions that the system must be able to
handle.
Basic concepts
❏ Associations: Associations express the relationships between classes and define the actions that define their
interactions. Associations have instances called links in UML, similar to how objects are instances of classes.
There are several types of associations.
Basic concepts
1) Generalization : Generalization describes inheritance, which is when a class is derived from a more generalized
version of itself. Consider the diagram below which denotes the superclass Vehicle that has two child classes,
Passenger and Utility. This relationship is denoted by a solid line with an arrow pointing to the superclass.
Basic concepts
2) Dependency : A dependency describes a relationship where one entity depends on or requires the resources of
another. For example, a car needs an engine to move. A flashlight needs a battery to function. A dependency is doted
by a dashed line in UML with an arrow at one or both ends.
3) Aggregation: Aggregation occurs when one class completely contains another class. For example, a hotel room
cannot exist without a hotel.
Basic concepts
4) Includes and Extends: Includes and Extends are two types of relationships used in use case diagrams. Uses
specifics that the “semantics of the source element are dependent upon the semantics of the public portion of the
target element”. Extends specifies that “the target use case adopts the behavior of the source”. Both involve selecting
a common behavior from several use cases and using them in a single-use case.
5) Multiplicity: Relationships can take on many different forms, defined by the number of possible associations that a
class can have. Multiplicity defines the “number of instances of an individual class that may be associated with a
single instance of another class”. In a UML diagram, multiplicity is denoted by a single digit, signifying the exact
number of relationships that an entity will have, or it will use the form “x:y”. x and y, in this case, represent the
number of relationships that fall between the range of “x” to “y”.
Basic concepts
Use case diagram
❑ As we have seen in chapter 1, DFDs are powerful modeling tools that you can use to show a system’s functionality and the flow of data
necessary for the system to perform its functions.
❑ DFDs are not the only way to show functionality. Another way is use case modeling.
❑ Any system can be described by a certain number of use cases, corresponding to the needs expressed by all users. Each user, considered as
an actor, will have a certain number of use cases within the system. All these use cases are represented in the form of a Use Case Diagram.
❑ Use case modeling helps analysts analyze and understand the functional requirements of a system without worrying about how those
requirements will be implemented.
❑ The process is inherently iterative—analysts and users work together throughout the model development process to further refine their use
case models.
Use cases serve as a means to gather and describe the needs of the system’s actors.
Use case diagram
1) Use case
❑ Represents a major piece of system functionality.
❑ A use case shows the behavior or functionality of a system. It consists of a set of possible sequences of interactions
between a system and a user in a particular environment, possible sequences that are related to a particular goal.
❑ A use case describes the behavior of a system under various conditions as the system responds to requests from principal
actors. A principal actor initiates a request of the system, related to a goal, and the system responds.
❑ A use case can be stated as a present-tense verb phrase, containing the verb (what the system is supposed to do) and the
object of the verb (what the system is to act on).
❑ Use cases do not reflect all of the system requirements; they must be augmented by documents that detail requirements,
such as business rules, data fields and formats, and complex formulas.
Use case diagram
1) Use case
❑ For identifying use cases, you can ask the following questions:
❑ What are the main tasks performed by each actor?
❑ Will the actor read or update any information in the system?
❑ Will the actor have to inform the system about changes outside the system?
❑ Does the actor have to be informed of unexpected changes?
❑ Can extend another use case.
❑ Can include another use case.
❑ The use case is represented by an ellipse containing its name. Use case’s
name
Use case diagram
1) Use case
❑ Example – Library Management Use cases :
❑ Member Management
❑ Membership Management (library subscriptions).
❑ Loan Management.
❑ Book Management (independent of loans).
❑ Generation of Loan Tracking Statistics (number of loans, etc.).
❑ Generation of Library Tracking Statistics (number of members, loans, etc.).
❑ Management of Internal Book Consultations.
Use case diagram
2) Actor
❑ An actor is a kind of role played by the user to the system. It is a typical system user that represents a responsibility or
role within the system rather than a physical person. An actor can be represented by a person, a system, or a machine.
❑ An actor is an external entity that interacts with the system. It is someone or something that exchanges information with
the system.
❑ Note that there is a difference between an actor and a user. A user is anyone who uses the system. An actor, on the other
hand, represents a role that a user can play. The actor’s name should indicate that role.
❑ Because actors are outside the system, you do not need to describe them in detail. The advantage of identifying actors is
that it helps you to identify the use cases they carry out.
Use case diagram
2) Actor
❑ There are two types of actors: Primary and Secondary
❑ A primary actor is mandatory for a use case (at least one is required). It represents the actor directly concerned
with the functional objective of the use case. Secondary actors are not directly involved in the use case but may be
required to assist in its execution.
❑ A use case corresponds to a functional objective of the primary actor. The goal of a use case is not necessarily an
outcome required by a secondary actor. A secondary actor interacts with the use case to facilitate its execution but
does not have a direct interest in it.
❑ The actor is represented by a stickman
Actor
Use case diagram
2) Actor
❑ Errors to Avoid
❑ Defining the system boundary can sometimes be challenging, and the two main errors to avoid are:
1) Including indirect actors who do not have a direct interaction with the system.
2) Identifying system components as actors instead of considering only external entities interacting with the
system.
Use case diagram
2) Actor Use Case Actors
Member Management Loan Agent
❑ Example – Library Membership Management Loan Agent
Management Use cases Loan Management Loan Agent
Loan Management Member
Loan Management Consultant
Book Management Librarian
Loan Tracking Statistics Preparation Librarian
Library Tracking Statistics Preparation Director
Consultation Management Loan Agent
Use case diagram
3) Relationships between use cases
❑ Include Relationship: Formalized by the stereotype <include>: the base use case explicitly incorporates another
use case in a mandatory way.
❑ The include relationship occurs when you have a chunk of behavior that is similar across more than one use case
and you don't want to keep copying the description of that behavior. It Has an arrow drawn from the base use case
to the used use case.
Use case 1
<<include>> <<include>>
Use case 2 Use case 3
Use case diagram
3) Relationships between use cases
❑ Extend Relationship: Formalized by the stereotype <extend>: the base use case implicitly incorporates another
use case in an optional way.
Use case 1
<<extend>> <<extend>>
Use case 2 Use case 3
Use case diagram
3) Relationships between use cases
❑ Generalization Relationship between Use Cases: The generalization/specialization relationship is a relationship
that links two use cases. If a first use case specializes a second one, it inherits its description and may enhance or
extend it. It is called a sub-use case (just as a subclass specializes another class).
❑ Use use case generalization when you have one use case that is similar to another use case but does a bit more. In
effect, this gives us another way of capturing alternative scenarios. Use case 1
❑ Has an arrow drawn from the specialized use case to the base use case.
Use case 2
Use case diagram
4) Relationships between Actors
❑ Generalization Relationship between Actors: The only possible relationship between two actors is
generalization:
❑ Actor A is a generalization of actor B if actor A can be substituted by actor B.
Actor A
In this case, all use cases accessible to A are also accessible to B, but the reverse is not true.
Actor B
Use case diagram
5) Use case description
❑ Use case diagrams can represent the functionality of a system by showing use case names and the actors who are
involved with them. The names of the use cases alone do not provide much of the information that is necessary to
continue with analysis and to move on to the design phase. We also need to know what goes on inside each use case.
❑ Each use case must be described in textual form in order to clearly identify the processes to be carried out by the system
to meet the need expressed by the actor.
❑ The use case description is done according to a template. The point is not the format of the template so much as it is how
the template encourages analysts to write complete use cases.
❑ Each heading reminds the analyst of the information that needs to be provided.
Use case diagram
5) Use case description Use case title
Goal in context : Briefly describe the context and the expected
outcomes of the use case.
Primary actor(s): The actor or actors involved in the use case must be
identified, along with a general description of their role.
Preconditions: Things that must be true before a use case can start.
Postconditions: If specific conditions must be met after the execution
of the use case, they should be stated at this stage.
Nominal scenario: This refers to the main scenario that should unfold
without any issues and lead to the desired outcome.
Secondary scenario: The other scenarios, whether secondary or
related to anomaly resolution, should be described at this point.
Secondary actors: Actors who are not directly involved in the case
but may be called upon for the execution of the case.
Exceptions
Use case diagram
6) Use case diagram
❑ A use case model consists of actors and use cases.
❑ A use case represents an interaction between an external entity and a software system. A use case diagram models
the system from the view of an external observer.
❑ Example – Library Management Use cases
Use case diagram
