From use case to software architecture

50 %
50 %
Information about From use case to software architecture

Published on February 14, 2014

Author: karawash



How to apply USECASE in Software Architecture?


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

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.

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

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.

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

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

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.

Use case vs. Algorithm

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.

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 ? “

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?

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 case model 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 cases  Model ◦ 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 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

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

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 ?

Step 2: Organize the Team  The 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 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

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

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.

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

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.

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 Model  Three 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 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).

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 

Ahmad Karawash, PhD Email:

Add a comment

Related presentations

Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...

In this presentation we will describe our experience developing with a highly dyna...

Presentation to the LITA Forum 7th November 2014 Albuquerque, NM

Un recorrido por los cambios que nos generará el wearabletech en el futuro

Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...

Microsoft finally joins the smartwatch and fitness tracker game by introducing the...

Related pages

Enterprise Architect - the UML CASE tool for software ...

Mapping Use Cases to Activity Diagrams. Often, early analysis of business processes will result in a collection of activity diagrams which describe how ...
Read more

Use case - Wikipedia, the free encyclopedia

... for small or easy project use. As good complements to use case ... Architect; MagicDraw; Rational Software's ... Use Case Modeling: Software ...
Read more

SWE 621: Software Modeling and Architectural Design ...

Software Modeling and Architectural Design Lecture Notes on Software Design ... From Use Case Models to Software Architecture • H. Gomaa, ...
Read more

Enterprise Architect - UML Design Tools and UML CASE tools ...

Software and Systems ... Project managers can use Enterprise Architect to: ... Enterprise Architect's Use Case Metrics capability makes it easy to ...
Read more

Designing Software Product Lines with UML: From Use Cases ...

Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures ... Software architects should evaluate the book in person.
Read more

Example: Software Architecture Document

Software Architecture ... A description of the use-case view of the software architecture. The Use Case View is important input to the selection of ...
Read more

An Introduction to Software Architecture

Garlan & Shaw: An Introduction to Software Architecture 3 heterogeneous styles can be combined in a single design. Next we use six case studies to ...
Read more

Software Architecture Document -

Software Architecture Document. ... Advanced Use Case Modeling: Software Systems. Upper Saddle River, NJ. 425 pages. Dean Leffingwell, Don Widrig. 2001.
Read more

UML Use Case Diagrams, Free Examples and Software Download

... the UML Use Case Diagrams templates and shapes are in the Software folder. ... Edraw is an ideal software to draw UML use case diagrams.
Read more