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: [email protected]
Top Related