CHAPTER THREE-PART II

Modeling a System using UML

1
 UNIFIED MODELLING LANGUAGE (UML)

 A language whose vocabulary and rules focus on the conceptual and physical
representation of a system.
 UML defines structural and behavioral things and diagrams.
 UML is the language of blueprints for software.
It is a graphical language for
 Visualizing
 Specifying – building models that are precise, unambiguous, and complete
 Constructing – possible to map from a model in the UML to a programming
language
 Documenting-Intended for software-intensive systems
2
 UNIFIED MODELLING LANGUAGE (UML)---

 Unified Modeling Language (UML) is a standardized visual modeling language used in

software engineering to design and specify software systems.
 UML provides a set of graphical notations and conventions for representing
various aspects of a system's structure and behavior,
making it easier for stakeholders to understand, communicate,
and document software requirements, designs, and architectures.
Key features of UML include:
1. Standardization
 UML is an industry-standard modeling language standardized by the
Object Management Group (OMG), ensuring
consistency and interoperability across different tools and organizations.
3
 UNIFIED MODELLING LANGUAGE (UML)---

2. Visual Representation
 UML uses graphical notations, such as diagrams and symbols, to
represent different aspects of a software system, including its
structure, behavior, interactions, and architecture.
3. Modeling Concepts
 UML provides a rich set of modeling concepts and constructs for
representing various elements of a software system, such as
classes, objects, relationships, attributes, methods,
use cases, activities, states, and events.
4. Diagram Types
UML supports several types of diagrams for modeling different aspects of a software system,
4
 UNIFIED MODELLING LANGUAGE (UML)---

 Structural Diagrams:
 Class diagrams, object diagrams, component diagrams, deployment diagrams.
 Behavioral Diagrams:
 Use case diagrams, sequence diagrams, activity diagrams,
state machine diagrams, communication diagrams, timing diagrams.
5. Tool Support
 UML is supported by a wide range of modeling tools that provide graphical editors,
code generation, reverse engineering, and other features to
facilitate the creation, manipulation, and analysis of UML models.
6. Communication and Collaboration
 UML diagrams serve as a common language for stakeholders, including clients,
developers, testers, architects, and project managers, to
communicate and collaborate effectively throughout the software development lifecycle.5
 UNIFIED MODELLING LANGUAGE (UML)---

7. Documentation
 UML diagrams can be used to document various aspects of a software system,
including its requirements, designs, architectures, and implementations.
They serve as valuable artifacts for understanding, analyzing, and maintaining software
systems.
 Overall, UML plays a crucial role in software development by providing a
standardized and visual modeling language for
representing and analyzing software systems, facilitating
communication, collaboration, and documentation among stakeholders, and
improving the quality and effectiveness of software development processes.

6
 WHAT UML IS NOT
1. Not a Programming Language:
 UML is not a programming language like Java, C++, or Python.
 It does not provide constructs for writing executable code.
Instead, UML is a visual modeling language used for designing, specifying, and
documenting software systems at a higher level of abstraction.
2. Not a Methodology or Process:
 UML is not a software development methodology or process.
 It does not prescribe specific development practices, techniques, or methodologies for
building software systems.
Instead, UML is a modeling language that can be used within various development
methodologies, such as Agile, Waterfall, or Spiral.
7
 WHAT UML IS NOT------
3. Not a Complete System Specification
 While UML provides a rich set of modeling constructs for representing different
aspects of a software system, it does
not offer a complete and detailed specification of a system.
 Additional documentation, requirements, and design artifacts may be
needed to fully specify and implement a software system.
4. Not a Substitute for Clear Communication:
 While UML diagrams can aid in communication and understanding, they are
not a substitute for clear and effective communication among stakeholders.
 Using UML does not guarantee successful communication if
stakeholders do not understand the diagrams or if
8
 WHAT UML IS NOT------
5. Not Only for Large-Scale Systems
 While UML is often associated with large-scale or complex systems, it can be
applied to projects of various sizes and complexities.
 UML can be scaled and adapted to suit the needs of different projects,
from small applications to enterprise-level systems.
6. Not Always Required for Every Project
 While UML can be beneficial for designing and documenting software systems,
it is not always necessary or appropriate for every project.
 The use of UML should be tailored to the specific needs, goals, and constraints
of each project, considering factors such as project size,
complexity, team expertise, and stakeholder preferences.
9
 UML STRUCTURE
UML

Common Architecture
Building Blocks Mechanisms

 Architecture
Building Blocks Common Mechanisms
 Specifications  Use-case view
 Things
 Adornments  Logical view
 Relationships
 Common Divisions  Process view
 Diagrams  Extensibility  Implementation view
Mechanisms 10
 Deployment view
 The Unified Modeling Language (UML)

 UML has three building blocks:

 Things, the objects.
 Relationships, the glue that holds things together.
 Diagrams, categorized as either structure or behavioral.
A. BUILDING BLOCKS OF UML
1. Things – the abstractions
i) Structural things – nouns, static, represent conceptual or physical elements: Class,
interface, collaboration, active class, component, and a node
ii) Behavioural things – verbs, dynamic, represent behaviour over time and space:
Interaction and state machine
iii) Grouping things – organizational parts of UML: Packages
11
iv) Annotational things – explanatory parts of UML
 A. BUILDING BLOCKS OF UML-----

2. Relationships – tie things together

A. Dependency (uses)
 a semantic (logical) relationship between two things in which a change to one thing (the
independent thing) may affect the semantics of the other thing (the dependent thing)
A car uses a fuel
B. Association
 a structural relationship that describes a set of links, a link being a connection among
objects.

12
 A. BUILDING BLOCKS OF UML-----

C. Generalization (is a)
 A specialization/generalization relationship in which objects of the
specialized element (the child) are substitutable for objects of the
generalized element (the parent)

3. Diagram
 The graphical representation of a set of elements
 Helps to visualize a system from different perspectives
 May contain any combination of things and relationships.
13
 UML DIAGRAMS
1. Diagrams used to describe structure
 Class diagram
 Object diagram
 Component diagram
 Deployment diagram
2. Diagrams used to describe behavior and Function
 Use Case diagram (functional)
 Sequence diagram
 Activity diagram
 Collaboration diagrams
14
Overview of UML Diagrams

15
 RULES OF UML

 UML (Unified Modeling Language) diagrams are standardized graphical notations used
for modeling software systems.
 While there aren't strict "rules" for UML diagrams, there are
guidelines and best practices to ensure clarity, consistency, and
effectiveness in communication.
Here are some general rules or principles to follow when creating UML diagrams:
1.Consistency
 Maintain consistency in notation, symbols, and naming conventions throughout the
diagrams to ensure clarity and ease of understanding.
1.Simplicity
 Keep the diagrams simple and focused on conveying essential information.
16
Avoid unnecessary complexity or detail that may confuse readers..
 RULES OF UML-----------

3. Clarity
 Ensure that the diagrams are clear and understandable to their intended audience.
 Use appropriate labeling, annotations, and comments to
clarify complex parts or relationships.
4. Abstraction
 Use appropriate levels of abstraction in your diagrams.
 Represent the system at a level of detail that is relevant to the intended purpose of the
diagram.
5. Correctness
 Ensure that the diagrams accurately represent the system being modeled.
 Validate the diagrams against the requirements and constraints of the
17
 RULES OF UML-----------

6. Completeness
 Include all necessary elements, relationships, and
behaviors in the diagrams to provide a comprehensive
view of the system.
 Avoid omitting important details that may be essential for
understanding the system's behavior or structure.
7. Modularity
 Organize the diagrams into logical modules or views that focus on
specific aspects of the system.
 Use packages or namespaces to group related elements and
provide a clear structure to the diagrams. 18
 RULES OF UML-----------

8. Use of Stereotypes
 Use stereotypes to extend or specialize the standard UML elements and
provide additional semantics or meaning to the diagrams.
 Use them judiciously to enhance the expressiveness of the diagrams
without introducing unnecessary complexity.
9. Alignment and Layout
 Arrange the elements and relationships in the diagrams in a
logical and visually appealing layout.
 Use alignment, spacing, and formatting to improve readability and comprehension.
10. Documentation
 Provide adequate documentation for the diagrams to explain their purpose, context, and any
19
relevant assumptions or decisions.
 B. COMMON MECHANISMS IN UML

Systems development using UML can be made simpler by the presence of common mechanisms:
1. Specifications – Behind every part of UML’s graphical notation there is a specification that
provides a textual statement of the syntax and semantics of that building block.
 Specification are used to state the system’s details.
 Provides a semantic backplane that contain all the parts of all the models of the
system.
 Example – a class diagram
2. Adornments – Most elements in the UML have a unique and direct graphical notation that
provides a visual representation of the most important aspects of the element.
 Every element in the UML’s notation starts with a basic symbol, to which can be
Transaction
added a variety of adornments to that symbol.
+execute()
+rollback()
#priority()
-timestamp() 20
 B. COMMON MECHANISMS IN UML------

3. Common Divisions

Class and Object

Costomer : Costomer Alemayehu : Costomer
-name name
name
-address
-phone
address address
phone phone

4. Extensibility Mechanisms
 UML can be extended using the following mechanisms
 Stereotypes: Extends the vocabulary of UML, allowing you to create new kinds of
building blocks that are derived from existing ones but that are specific to your problem.
 Constraints: Extends the semantics of a UML building block, allowing you to add new
rules or modify existing ones.
21
 C. ARCHITECTURE
Architecture is the set of significant decisions about
 The organization of a software system
 The selection of the structural elements and their interfaces by which the system is
composed
 Their behavior, as specified in the collaborations among those elements
 The composition of these structural and behavioral elements into progressively larger
subsystems
 The architectural style that guide this organization:
the static and dynamic elements and their interfaces, their collaborations, and their
composition.

22
 C. ARCHITECTURE--------------

 System/software architecture refers to the conceptual structure and design of a complex system.

 It encompasses the arrangement of components, their relationships, and the principles and guidelines

governing their organization and interaction.

 System/software architecture provides a high-level view of the system,

defining its key structural elements and their roles, responsibilities, and interfaces.
 Software architecture is not only concerned with architecture and behavior,

but also with usage, functionality, performance, resilience, reuse, comprehensibility,

economic and technology constraints and trade-offs, and aesthetic concerns.

Architecture of a system can be described by a view.

 A view is simply a subset of UML modeling constructs that represent one aspect of the system

 Each of the views involve structural and behavioural models 23

 Views of a system
 In software engineering, system architecture and design are often represented using multiple views, each
focusing on a specific aspect of the system.
 These views collectively provide a comprehensive understanding of the system's architecture and
facilitate communication among stakeholders
 Systems can be viewed from a number of perspectives:
 Different stakeholders:
 System Owners,
 End Users,
 System Analyst,
 System Developers,
 Project Managers and etc
 Each looks at the system in different angle at different times over the project’s life span
 System Architecture can be used to manage these different viewpoints, therefore controlling the
24
development of a system throughout its life cycle
 UML captures these different angles/viewpoints as a set of five
interlocking views: - System Assembly
Vocabulary Configuration
Functionality Management

Design view Implementation view

behavior Use case view

Process view Deployment view System

Topology
Performance Distribution
Scalability Delivery
throughput Installation

 Each view focused on a particular aspect of the system, are stand

alone and interact with each other
25
 Views of a system-------
1. Use case view
 The "Use Case view" refers to a perspective or representation of a system's architecture that
emphasizes the use cases and their relationships with actors.
 It provides a focused view of the system's functionality, highlighting how users (actors) interact
with the system to achieve specific goals or tasks.
 End-product: Use Case Diagrams
2. Design views
 Supports the functional requirements of the system
 Focuses on the things (classes, interfaces and collaborations) that form the vocabulary of the
problem that the system is trying to solve and the elements of the solution to that problem.
 The view encompasses the static and dynamic aspects of the system
 End-product: Class and Object Diagram (Static), Sequence/Collaboration, Activity and State
26
 Views of a system-------
3. Process view
 Focuses on the aspects(features or component) of the system that involves timing and the flow of
control.
 Addresses the performance, scalability and throughput of the system
 End product: Activity Diagrams
4. Implementation view
 Encompasses the components and files that are used to assemble and release the physical system
 End-product: Component Diagrams
5. Deployment view
 Focuses on the geographic distribution of the various software elements on hardware and other
physical elements that constitute a system
 Encompasses the nodes that form the system’s hardware topology on which the system executes
27
 End-product: Deployment Diagram
 Use Case Model
 A use case model is a representation of the functional requirements
of a system from the perspective of its users.
It describes the interactions between the users (actors) and the system to achieve
specific goals or tasks.
 Use case modeling is a technique used in software engineering to
capture, analyze, and document the functional requirements of a
system in a structured and organized manner.
Here are the key components of a use case model:
1.Actors
 Actors represent the roles played by users or external systems that interact with the
28
 Use Case Model------
 Each actor has specific goals or tasks that they want to
accomplish by using the system.
Actors are depicted as stick figures in use case diagrams.
3. Use Cases
 Use cases represent the specific functionalities or features of the
system from the perspective of users.
 Each use case describes a sequence of interactions between the user and
the system to achieve a particular goal.
 Use cases capture both the main flow of events and alternative or exceptional flows.
Use cases are depicted as ovals in use case diagrams.
29
 Use Case Model------
4. Relationships
 Relationships between actors and use cases indicate the interactions between them.
A. Association
 An association between an actor and a use case indicates that the actor participates
in or interacts with that use case.
B. Include/Extend
 Include and extend relationships represent common or optional behavior shared
among multiple use cases.
 "Include" indicates that one use case includes the functionality of
another use case, while "extend" indicates that one use case extends
Relationships the behavior of another use case under certain conditions.30
 Use Case Model------
4. System Boundary
 The system boundary represents the scope of the system and
delineates its boundary from external actors and systems.
 It helps clarify which actors are part of the system and which are external to it.
5. Use Case Diagram
 A use case diagram is a graphical representation of the use case model.
 It visually depicts the actors, use cases, and their relationships.
 Use case diagrams provide a high-level overview of the system's functionality and
help stakeholders understand the system's requirements and scope.
Use case modeling is an essential technique for requirements elicitation, analysis, and validation in
software development projects.
 It helps ensure that the system meets the needs and expectations of its users by
capturing their requirements in a structured and systematic manner. 31
 Use Case Model------
Use case Modeling could be
1. Essential Use Case Modeling
 Used at requirement elicitation stage
 Technology free
 Just to understand what users need to see on the system from functions point of view
2. System Use Case Modeling
 Is a continuation of essential use case with adding implementation related details
 It is influenced by the technology to be used for the systems development
 It is composed of the system use case diagram and its corresponding documentation
The use case diagram and the documentation will have same components as the essential
use case model with little technology influence.
32
 Use Case Model Objective

1.Requirements Elicitation
 Helps elicit and document functional requirements by identifying the

goals, tasks, and interactions of system.

2. Scope Definition
 Helps define the scope of the system by identifying the

boundaries and interactions with external actors.

 It clarifies which functionalities are within the system's scope and which are not,

helping stakeholders understand the

system's capabilities and limitations.

33
 Use Case Model Objective----------

3. Communication and Collaboration

 Serve as a visual communication tool that facilitates

collaboration among stakeholders, including

business analysts, developers, testers, and end users.

 They provide a common language for discussing system requirements,

enabling stakeholders to communicate effectively and

ensure alignment of expectations.

4. Requirement Prioritization
 Supports requirement prioritization by identifying the most

critical and high-value functionalities of the system. 34

 Use Case Model Objective------------

 By prioritizing use cases based on their importance and business value,

stakeholders can focus development efforts on delivering the
most essential features first, ensuring that they meet key business objectives..
5. Verification and Validation
 Use case models provide a basis for verifying and validating system requirements
throughout the software development lifecycle.
 They serve as a reference for defining test cases, acceptance criteria, and
user acceptance testing (UAT), ensuring that the system
meets the specified functional requirements and user needs.
6. Iterative Development
 Supports iterative and incremental development methodologies by providing a framework
35
for capturing and refining requirements incrementally.
 Use Case Model Objective

7. Documentation and Maintenance

 Serve as documentation artifacts that capture the functional requirements of

the system in a structured and organized manner.

 They provide a reference for developers, designers, and other stakeholders

to understand the system's behavior, making it

easier to maintain and enhance the system over time.

36
 On-line Bookstore System

Register

Customer Order books

Sell used
books

Review books

37
What is the difference with the previous use case?

Sell Item <<

Inc
lud
es
>>

Reorder
<<Includes>>
Sales Clerk

Login

Add to Stock
<<Includes>>

<<Includes>>

Generate
Report

Manager

38
 Use Case Documentation
 Use case documentation is a set of documents that
describe the functional requirements of a
system using the use case modeling technique.
 It provides detailed information about the various interactions between
users (actors) and the system to achieve specific goals or tasks.
 Use case documentation is typically created during the requirements analysis phase
of the software development process and serves as a
key reference for system design, implementation, and testing.
The following slide shows the use case documentation template with different
components
39
 Use Case Documentation Template
Use Case Name
Identifier
Description
Actor
Pre Condition
Post Condition
Extends
Includes

Basic Course of Action

1………………………………………
2. ……………………………………….
3. …………………………………………………………..

Alternative Course of Action:

…………………………………………………………………..
…………………………………………………………………………….. 40
 Activity 1
 On-line Bookstore is a web application that can be accessed by the store’s registered
customer, whereby each customer can order books, review one or more books sold in
the book store, and sell used books to other customers. Before performing any one of
these transactions, the customer must first log-in into the system using their user id
and password kept in their account. The customer can also take a book he/she
ordered.
 Problems:

 Identify the Use Cases and draw a use case model(system use case)
 Write the Main Flow of Events
 Prepare Use Case Documentation for one of the use cases you have identified
41
“sell used book”
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out

Customer Order books

<<include>>

<<include>>
Sell used Log-in
books
<<include>>

Review books

42
 Use Case Documentation to Sell Used Book
Use Case Name Sell Used Books
Identifier UI-001
Description This use case describes the process by which a Customer sells their used
books.
Actor Customer
Pre Condition  The Customer must be logged into their account on the book selling system.
 The Customer must have one or more books they wish to sell.
Post Condition  The listed books are made available for sell.
 The Customer receives notifications of any sales or inquiries about their
listed books.
Extends
Includes SellUsedBooks use case <<includes>> LogIn use case
43
 Use Case Documentation to Sell Used Book -----
Basic Course of Action:
1. The CUSTOMER clicks the Sell Used Books button on the Home Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the used books that he/she wants to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the information that the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are accurate. If yes, the CUSTOMER clicks
the OK button on the web page.
7. The system updates the USED BOOKS table in the database.
Alternative Course of Action:
8. If the Customer input the required information of the sell used Books wrongly
9. Go to Step 3
44
 Assignment 1
Read the following problem domain of University Registration System and answer the
following questions (1-4).
 Professors indicate which courses they will teach on-line. A course catalog can be prepared and
printed to start to teach. The system allow students to select on-line four courses for upcoming
semester and no course may have more than 10 students or less than 3 students. When the
registration is completed, the system sends information to the billing system. The system allows
a Professors to obtain course rosters on-line. And the system enables students can add or drop
classes on-line.
1. Identify all the Use Cases(functionality of the system)
2. List down the actors with its corresponding description.
3. Draw System Use Case Diagram
45
This chapter To be continued TO NEXT
PART (Part III)

46