In this business analysis training, you will learn OOA and UML. Topics covered in this session are: • Introduction to OOA and UML • Stated vs Un-stated • Software Analysis and Design • Modeling • UML • Why UML • Overview • Types • Use Case Diagram For more information, visit this link: https://www.mindsmapped.com/courses/business-analysis/business-analyst-training-for-beginners/

1. Business Analysis
Training
Introduction to OOA and UML

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