How to apply USECASE in Software Architecture?

1. By
AHMAD KARAWASH

2. Overview
Use cases & Architects
Use cases benefits
Different Approaches
Challenges
Extending use-case

3. Overview

Use cases are a powerful tool used in the
systems analysis phase to describe the
behavioral aspect of the system being
developed.

Use case describes a scenario in which a
user interacts with the system being defined
to achieve a specific goal .

A use case defines a goal-oriented, set of
interactions between external actors and the
system under consideration.

4. USE CASE

A complete set of use cases specifies all the
different ways to use the system, and
therefore defines all behavior required of the
system.
Actors

5. Overview
The main artifacts of the use case model include:

Actor list – A list of all the actors found and their
relationships.

Use Case Packages – can be used to divide the
work between the different teams.

Use case diagrams – The diagrams are the
graphical representations of the use case model.

The use-cases text –Word documents containing
the use cases.

Use case views – Several views that help
understand the model from different angles.

6. Vocabulary

Actor – External parties that interact with
the system

Use Case – A sequence of actions that the
system performs that yields an observable
result of value to an actor. [Booch 1999]

Use Case Model - Bag that contains
◦ Actors list, packages, diagrams, use cases,
views

7. Software architecture

Architecture is the fundamental organization of a
system embodied in its Components , their
relationships to each other, and to the environment,
and the principles guiding its design and evolution.

The System Architecture is the set of entities, the
properties of those entities, and relationships among
them that define structure of the system.

8. Example banking system

9. Architecture views
More than one aspect of software must be modeled
and designed
 Many architect use “Kructen’s 4+1” model of these
views
o Logical view
o Process view
o Deployment view
o Implementation view


The “plus one” is:
use-case view

10. What Do Architecture Views Capture?

Logical view (design view)
◦ Architecturally significant parts, such as layers,
subsystems, components, etc.

Process view
◦ Processes or threads that make up the system.

Deployment view
◦ Do parts of the system on separate hardware
components?

Implementation view
◦ Source files, binaries, DLLs, SW components, etc.
• Use case view
◦ Use cases show how the end-user interacts with the
system.

11. Use case vs. Algorithm

12. Use Cases benefits

Promote customer involvement in defining
the requirements.

improved business requirements analysis
and documentation.

improved communication between business
and technical teams.

improved project scoping and planning.

high-level of re-use.

13. Use Cases benefits

Reduce project risks, development time and
costs.

Error-handling, by defining sequences that
may lead to failure .

show the system in different angles .

Perspective provided by use cases
reinforce the ultimate goal of software
engineering:
“ what the system should do ? “

14. Use cases & Architects ?!

Requirements drive the design !!!

Help force designers focus on concrete
issues.

Help identifying technical and business
risks.

Can be used to help Verify & Validate the
model.
 Are we building the product right?

15. Use cases & Architects ?!

Help manage complexity
 Layers
 Focus on real user needs

Groundwork for user manual, test cases.

Help us work in iterations.

16. Use cases & Architects ?!
(cont.)

Architectural design workflow (Kruchten 2003):
◦ Select scenarios : criticality and risk
◦ Identify main classes/components and their
responsibility
◦ Distribute behavior
◦ Structure into subsystems, layers and define
interfaces
◦ Define distribution and concurrency
◦ Implement architectural prototype
◦ Derive tests from use cases
◦ Evaluate architecture

17. Naïve approach
The naïve process for building a use case
model is very straightforward [Armour,2001]
1. Find Actors
2. Find Use Cases
3. Describe the Use Cases

18. Challenges

The problem is that such a simple process just
doesn't cut it when it comes to large and
complex systems.

The model is inflicted with duplicates.

Inconsistencies between use cases – starting
from boundaries mismatches and ending in
contradicting use cases.

19. Challenges for complex use
cases

Model
◦ Explosion
◦ Making sure the requirements are good

Team
◦ Efficiency
◦ Fragmentation

Process
◦ Details too early
◦ Quitting Time

20. Challenges

They don’t capture Non-behavioral
requirements :
◦ Performance , security , Modifiability.
◦ Environment constraints (such as specific OS,
Hardware etc.)

Wasting energy on detailing requirements.

Large delays in the project schedule.

21. Challenges

Problematic for complex and large system.

Suggested use cases may still really be lists of
features (too simplistic /not practical).

Poor for distributed systems.

Not as good at representing dynamic
component architectures.

Could be Vague, ambiguous, and incomplete.

23. Bridging the gap between “what” and “how”
the trick is in writing use case correctly

24. Challenges

Semantics too imprecise –while formal testing/
verification… Leads to too many diagram
notes.

contains specifications needed very rarely.

Requires training/certification when working
with enterprise class systems.

UML is way too big - Long use case templates slow
you down!
A practical reasonable process is needed !!!

25. The Methodology
The use case model building process should be
extended in order to mitigate these challenges.
we need a process that is:
◦
◦
◦
◦
◦
Ordered
Controlled
Not too complicated
Not too demanding
Flexible

26. Methodology Steps
Define System Boundary
2) Organize the Team
3) Build a Problem Domain Object Model
4) Find Actors
5) Find Use Cases
6) Organize the Model
7) Prioritize Use Cases
Diagram
PDOM
8) Describe Use Cases
9) Refactor the Model
UC
10) Verify and Validate
Verify
11) Add Future Requirements
Refactor
12) Knowing When to Stop
Team
1)
Vision
priorities
Validate

27. Step 1: Define System
Boundary

The Requirements Manager and Architect define
the system boundary
◦
◦
◦
◦
What problem(s) are we trying to solve ?
Who are the stakeholders ?
What are the main goals of the system ?
What are the major functional and non-functional
requirements ?
◦ What are the future directions of the product ?

28. Step 2: Organize the Team

The teams (sizes and structure) that will be
involved should be determined.

29. Step 3: Build a Problem Domain
Object Model PDOM


Usually, set of UML object diagrams showing the
relations between the various objects.
Iterative development Class model (UML).
Police HQ
Commands
Commands
Commands
Watch
Commander
Has an
District
Emergency
Center
Is made of
Is a
Allocated to
Sector
Rapid Response
Car
Is made of
Is a
Policeman
Beat
Police Car
Work in
Are
Allocated to
Watch
Beat Team
Allocated to
Drive
Beat Car
Is a

30. Step 4: Find Actors


Finding actors is a recommended task for any use
case modeling effort.
No need to make an exhaustive list of all the
actors.
User
Emergency
Center Operator
Emergency
Center Supervisor
Cop
Watch
Commander
HQ Watch
Commander

31. Step 5: Find Use Cases
There are basically four ways for discovering use
cases:

Scenario Driven - Approach to examine the list of primary
actors and their roles.

Actor/Responsibility - the responsibilities they have for
accomplishing tasks.

Unstructured aggregation – place non-functional
requirements into specific use cases.

Mission decomposition - identifying the actors, events,
business rules etc.

32. Step 6: Organize the Model

The simplest form of organizing the model is by level of
detail .

33. Step 7: Prioritize Use Cases

Modern software projects are built using an
iterative process – this is done both to have a
better control on the project and its progress
and to risks early.

drive the development effort.

34. Step 8 : Describe Use Cases
For complex use case it’s difficult to follow.
It is recommended to use UML's activity diagrams to
visualize
the scenarios.

35. Step 9: Refactor the Model

Three relationships can be used to structure use
cases:
◦ Extend
◦ Include
◦ Generalize

36. Step 10: Verify & Validate the
model
Some Problems type:
Incorrect description of use case.
 Duplicated use case.
 Expected functionality is unavailable.
 Name of use case does not reflect the Goal.
 To little details .


37. Step 11: Add Future
Requirements

Capture Change cases
◦ Preparing for change.
◦ future enhancements.

38. Step 12: Knowing When to Stop

Project Level
◦ Complete list of actors and goals.
◦ Customer approval.
◦ Design ready.

Iteration Level
◦ Covered all currently prioritized use
cases.
◦ Level of detail (packages).

39. New way to deal with complex use
case ( Karabash )
As the size of the use case increases,
some of its advantages will be lost
 Use case chain is a technique to
reduce complexity of large use cases
by transform it into small text chains


40. Karabash way example:

41. Karabash way example:

42. Chains benefits:
Test scenario: set of chain can be
used by tester to generate end-to-end
test scenarios.
 Validation : this way gives us the
manageability to validate the model
with no much effort where no
documenting of the same process
more than once.


43. Chains benefits:
Priority : the chain can be ordered
according to important unit in the
model
 cataloging : catalog of all use case
chains in the model gives us list of all
possible feature of the system


44. Ahmad Karawash, PhD
Email: ahmad.karawash@gmail.com