From use case to software architecture


Published on

How to apply USECASE in Software Architecture?

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

From use case to software architecture

  2. 2. Overview Use cases & Architects Use cases benefits Different Approaches Challenges Extending use-case
  3. 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. 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. 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. 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. 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. 8. Example banking system
  9. 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. 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. 11. Use case vs. Algorithm
  12. 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. 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. 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. 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. 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. 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. 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. 19. Challenges for complex use cases  Model ◦ Explosion ◦ Making sure the requirements are good  Team ◦ Efficiency ◦ Fragmentation  Process ◦ Details too early ◦ Quitting Time
  20. 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. 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.
  22. 22. Bridging the gap between “what” and “how” the trick is in writing use case correctly
  23. 23. 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 !!!
  24. 24. 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
  25. 25. 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
  26. 26. 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 ?
  27. 27. Step 2: Organize the Team  The teams (sizes and structure) that will be involved should be determined.
  28. 28. 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
  29. 29. 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
  30. 30. 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.
  31. 31. Step 6: Organize the Model  The simplest form of organizing the model is by level of detail .
  32. 32. 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.
  33. 33. 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.
  34. 34. Step 9: Refactor the Model  Three relationships can be used to structure use cases: ◦ Extend ◦ Include ◦ Generalize
  35. 35. 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 . 
  36. 36. Step 11: Add Future Requirements  Capture Change cases ◦ Preparing for change. ◦ future enhancements.
  37. 37. 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).
  38. 38. 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 
  39. 39. Karabash way example:
  40. 40. Karabash way example:
  41. 41. 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. 
  42. 42. 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 
  43. 43. Ahmad Karawash, PhD Email: