By AHMAD KARAWASH

FROM USE CASE TO SOFTWARE

ARCHITECTURE

OverviewUse cases & Architects Use cases benefitsDifferent ApproachesChallenges Extending use-case

OverviewUse 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.

USE CASEA complete set of use cases specifies all

the different ways to use the system, and therefore defines all behavior required of the system.

Actors

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.

VocabularyActor – 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

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.

Example banking system

Architecture viewsMore than one aspect of software must be

modeled and designedMany architect use “Kructen’s 4+1” model of

these viewsoLogical viewoProcess viewoDeployment viewo Implementation view

The “plus one” is: use-case view

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.◦ So they affect and influence all other views.

Use case vs. Algorithm

Use Cases benefitsPromote 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.

Use Cases benefitsReduce 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 ? “

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? Are we building the right product?

Use cases & Architects ?!Help manage complexity

Layers Focus on real user needs

Groundwork for user manual, test cases.

Help us work in iterations.

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

Naïve approach

The naïve process for building a use casemodel is very straightforward

[Armour,2001]

1. Find Actors 2. Find Use Cases 3. Describe the Use Cases

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.

Challenges for complex use casesModel

◦ Explosion◦ Making sure the requirements are good

Team ◦ Efficiency◦ Fragmentation

Process◦ Details too early◦ Quitting Time

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.

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.

Bridging the gap between “what” and “how”

the trick is in writing use case correctly

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 !!!

The MethodologyThe use case model building process

should beextended in order to mitigate these

challenges.

we need a process that is: ◦Ordered◦Controlled◦Not too complicated◦Not too demanding◦Flexible

Methodology Steps1) Define System Boundary2) Organize the Team3) Build a Problem Domain Object Model4) Find Actors5) Find Use Cases6) Organize the Model7) Prioritize Use Cases8) Describe Use Cases9) Refactor the Model10) Verify and Validate11) Add Future Requirements12) Knowing When to Stop

priorities

TeamValidate

UC Verify

Refactor

PDOM

VisionDiagram

Step 1: Define System BoundaryThe 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 ?

Step 2: Organize the TeamThe teams (sizes and structure) that

will be involved should be determined.

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 Car

Watch

Policeman

Work in

Beat

Beat Car

Is aAllocated to

Beat Team

AreAllocated to

Drive

Police HQ

Watch Commander

Is a

Commands

Emergency CenterDistrict

Commands

Commands Has an

Rapid Response Car

Is a

Sector

Is made of

Is made of

Allocated to

Step 4: Find ActorsFinding actors is a recommended task for

any use case modeling effort. No need to make an exhaustive list of all the

actors.

Emergency Center Supervisor

User

Watch Commander

Emergency Center Operator

HQ Watch Commander

Cop

Step 5: Find Use CasesThere 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.

Step 6: Organize the Model

The simplest form of organizing the model is by level of detail .

Step 7: Prioritize Use CasesModern 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.

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.

Step 9: Refactor the ModelThree relationships can be used to structure

use cases:◦ Extend ◦ Include◦ Generalize

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 .

Step 11: Add Future Requirements

Capture Change cases◦Preparing for change.◦future enhancements.

Step 12: Knowing When to StopProject Level

◦Complete list of actors and goals.◦Customer approval.◦Design ready.

Iteration Level◦Covered all currently prioritized use

cases.◦Level of detail (packages).

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

Karabash way example:

Karabash way example:

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.

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

QUESTIONS ??Ahmad Karawash, PhD

Email: ahmad.karawash@gmail.com