This document provides an introduction to object-oriented analysis (OOA) and the Unified Modeling Language (UML). It discusses why modeling software systems is important and introduces UML as a standard modeling language. The core components of UML include diagrams like use case diagrams, which visually depict interactions between external users and a system. Use case diagrams show actors, use cases, and relationships between them like generalization, inclusion, and extension. The document uses examples and exercises to demonstrate how to construct use case diagrams for modeling different systems and scenarios.

1. Unified Modeling
Language (UML):
The Complete Guide

2. Page 2Classification: Restricted
Agenda
• Introduction to OOA and UML
• Stated vs Un-stated
• Software Analysis and Design
• Modeling
• UML
• Why UML
• Overview
• Types
• Use Case Diagram

3. Page 3Classification: Restricted
Introduction
• Object Oriented Analysis and Design is an important skill for Business
Analysts as well as Technical Architects
• The design is dependent on a good analysis

4. Page 4Classification: Restricted
Why Do We Need Object Oriented
Analysis or a Structured Analysis?

5. Page 5Classification: Restricted
5
Stated vs Un-Stated

6. Page 6Classification: Restricted
6
Another Example

7. Page 7Classification: Restricted
7
Software Projects (2012 Report)
How Successful are Our Projects?
Source: Standish Chaos Report (2012)

8. Page 8Classification: Restricted
8
Where does it go wrong?

9. Page 9Classification: Restricted
Software Analysis and Design

10. Page 10Classification: Restricted
Modeling
• Describing a system at a high level of abstraction
– A model of the system
– Used for requirements and specifications
• Is it necessary to model software systems?

11. Page 11Classification: Restricted
What is UML?
• UML stands for “Unified Modeling Language”
• It is a industry-standard graphical language for specifying, visualizing,
constructing, and documenting the artifacts of software systems
• The UML uses mostly graphical notations to express the OO analysis and
design of software projects.
• Simplifies the complex process of software design

12. Page 12Classification: Restricted
Why UML for Modeling
• Use graphical notation to communicate more clearly than natural
language (imprecise) and code(too detailed).
• Help acquire an overall view of a system.
• UML is not dependent on any one language or technology.
• UML moves us from fragmentation to standardization.

13. Page 13Classification: Restricted
Types of UML Diagrams
• Use Case Diagram
• Class Diagram
• Sequence Diagram
• Collaboration Diagram
• State Diagram
This is only a subset of diagrams … but are most widely used

14. Page 14Classification: Restricted
Use Case Diagram
• Used for describing a set of user scenarios
• Mainly used for capturing user requirements
• Work like a contract between end user and software developers

15. Page 15Classification: Restricted
Use Case Diagram (core components)
Actors: A role that a user plays with respect to the system, including human
users and other systems. e.g., inanimate physical objects (e.g. robot); an
external system that needs some information from the current system.
Use case: A set of scenarios that describing an interaction between a user
and a system, including alternatives.
System boundary: rectangle diagram representing the boundary between
the actors and the system.

16. Page 16Classification: Restricted
Use Case Diagram (core relationship)
Association: communication between an actor and a use case;
Represented by a solid line.
Generalization: relationship between one general use case and a
special use case (used for defining special alternatives)
Represented by a line with a triangular arrow head toward the parent
use case.

17. Page 17Classification: Restricted
Generalization

18. Page 18Classification: Restricted
Use Case Diagram (core relationship)
Include: a dotted line labeled <<include>> beginning at base use case and
ending with an arrows pointing to the include use case. The include
relationship occurs when a chunk of behavior is similar across more than one
use case. Use “include” in stead of copying the description of that behavior.
<<include>>
Extend: a dotted line labeled <<extend>> with an arrow toward the base case.
The extending use case may add behavior to the base use case. The base class
declares “extension points”.
<<extend>>

19. Page 19Classification: Restricted
Use Case Diagram (core relationship)

20. Page 20Classification: Restricted
Use Case Diagram (core relationship)

21. Page 21Classification: Restricted
Use Case Diagrams
Library System
Borrow
Order Title
Fine Remittance
Client
Employee
Supervisor
Boundary
Actor
Use Case

22. Page 22Classification: Restricted
Use Case Diagrams

23. Page 23Classification: Restricted
Types of Actor
Actors
Primary Actor Secondary Actor

24. Page 24Classification: Restricted
Types of Actor

25. Page 25Classification: Restricted
Exercise

26. Page 26Classification: Restricted
Use Case Specification

27. Page 27Classification: Restricted
Exercise

28. Page 28Classification: Restricted
Use Cases for the Exercise

29. Page 29Classification: Restricted
Actors for the Exercise

30. Page 30Classification: Restricted
Relationship between the actors

31. Page 31Classification: Restricted
31
• Object-oriented analysis and design (OOAD) is a technical approach used in
the analysis and design of an application or system through the application
of the object-oriented paradigm and concepts including visual modeling.
• This is applied throughout the development life cycle of the application or
system, fostering better product quality and even encouraging stakeholder
participation and communication

32. Page 32Classification: Restricted
Thank you