The following shows a step-by-step integration of three use cases in a unified use case statechart. Each step shows the effects of building of the statecharts on the use cases. Each use case modification resulted as a solution to a particular ambiguity detected while building the unified use case statechart. The effects on the system scope are also shown.
TO BE CONTINUED…
I shall use a turnstile system specification to demonstrate how we can detect and handle use case problems described in my previous post Use Case Problems.
I shall start with three initially specified use case scenarios and a system boundary definition:
The corresponding use case diagram:
The system sequence diagrams emphasizing input/output events:
Over the last 7 years I had the opportunity to analyze and evaluate literally thousands of use cases. While being a good and effective technique, writing use cases is difficult. They are difficult especially since it is hard to specify them “correctly”.
Why?
First of all, use cases most often describe “envisioned” processes, that is, processes that are still not developed and put in place. It is difficult to envision things correctly from the first shot.
Second, use cases are most often specified by non-technical people for technical people. This is simply due to reasons they are used in the first place:
As such, use cases really span two different worlds, the world of problem domain and the world of problem solution. In such environments, it is usually technical people who see all use cases and put them in a context. Putting all use cases in this context allows technical people to see all the problems with use cases.
So, what are these problems?
The problems are that the typical result of an initial use case analysis and specification is a set of use cases with:
In short, the quality of the use cases is typically not good. Specifying consistent, high quality use cases is hard. Is it worth it? It depends if you find it easier clarifying and fixing user requirements at the use case analysis stage or at the later design or even coding stages.
See upcoming examples on how to deal with use case problems.
The basic technique preached by many OOAD/UML and intro OOP books is to use noun underlining as a technique for coming up with an initial set of domain concepts. On its own, there is nothing wrong with this technique, but combined with a principal heuristic of OOAD – that OOA conceptual model should serve as a main source of concepts for OOD conceptual model, that is, that domain classes should be the main source of design classes – in my experience leads to major problems. Many analysts and designers simply directly reuse or insist on direct mapping of the design classes to domain classes, that it leads to less-than-optimal design solutions.
Why? Just analyze this small example in which I use noun-underlining technique to generate initial set of OOA concepts, but intentionally do not follow the heuristic of reusing OOA conceptual model for OOD conceptual model:
Problem description:
There are two baskets in a field. One has 666 oranges in it, and the
other one has 1000 oranges in it. I need to know how many oranges
there are all together.
OOA Model:
OOD Model:
OOP Model:
Try to come up with a solution following the traditional OOAD heuristic of preserving domain classes in the design and you will see the difference.
This is the collaboration diagram for the rentItems operation. See Examples category for related posts.
Click on the thumbnail to see the full image:
This is the system sequence diagram that shows that shows the interactions between the actor and the system in the video store domain. Following diagram, I provide contract specification for the operations. See Examples category for related posts.
Click on the thumbnail to see the full image:
Name: rentItems
Responsibilities: Items are rented to customer.
Use Case: Rent Items
Invariants:
Pre-Conditions:
Post-Conditions:
Name: closeSession
Responsibilities: Customer’s account is closed and system is ready for new task.
Use Case: Rent Items
Post-Conditions:
Now, when we know the five main aspects, two main kinds of specifications, and two main kinds of systems that we are specifying, we should discuss the available techniques. Overall, we have four different sets of techniques to capture different system aspects (communication and interfaces are typically specified using the same techniques):
Now, the secret! It is important to note that most of these techniques do not specify only one aspect! For example, although the main purpose of the use cases is to capture functional and behavioral aspects, use cases capture also certain communicational and conceptual decomposition aspects.
Moving to UML… The specification methods that use UML rely upon the use of use cases, use case diagrams, sequence diagrams, statecharts, and class diagrams. Together, they cover all five main aspects of a system that have to be specified.
Each of main UML modeling artifacts captures multiple modeling concerns, with more emphasis on some than the others:
Now, since you know what aspects each modeling technique is covering, the secret of a good model is to have all techniques modeling a particular aspect consistently! So, no matter which modeling notation, what type of software system and what development stage you are working at, make sure you model these five aspects and model them consistently!
Many beginners learn and do modeling by studying a particular modeling language, such as Unified Modeling Language (UML). In my experience, this is not good. It makes it harder to understand and grasp the basic concepts and ideas. This results in a significant waste of time and misuse of modeling techniques. Learning modeling by studying a modeling language forces you to focus on how to model something rather than focusing on what should be modeled first. The most effective way learn modeling is by learning and understanding what exactly should be modeled first, and only then how it should be modeled! In this article I’d like to share with you some basics of what to model.
In order to effectively use different modeling techniques, it is important to understand different system aspects that have to be modeled. Most modeling techniques focus on modeling a particular aspect of a domain system. Although, in many articles in software and systems engineering literature, this division is represented slightly differently, there are five main aspects of a system that should be modeled:
Functional aspects describe functions that a system or a component provides. Behavioral aspects describe how functions are temporally or logically related. Conceptual decomposition aspects describe a breakdown of a system into subsystems, components, data entities, devices, etc. Communicational aspects describe how functions and concepts interact, i.e., how they are spatially related. Interface aspects describe protocols for accessing a system’s or a component’s functionality, i.e., the intersection of the conceptual decomposition and the communication concerns.
A typical further division is on the system and internal aspects. System aspects describe the system as a black box, and thus we have system functions, system behavior, system communication with the system’s environment, system interfaces, and system conceptual decomposition with respect to system’s environment. Internal aspects describe the properties of the internal components of the system. At this level, we usually see component functions, component behavior, component communication, component interface, and internal conceptual decomposition specifications. This division on the system and internal aspects, although important, is not particularly relevant from the perspective of the modeling techniques as the same techniques are typically used to specify both system and internal aspects of the system. So, the same techniques apply for modeling of the system as a whole as well as for the modeling of its components. The same applies to any intermediate decomposition levels.
Another typical division is on analysis models and design models. Analysis models describe a domain system, while design models describe software system that will partially or fully automate the domain system. Again, from the perspective of the modeling techniques, this division does not make any difference since you’ll be using the same modeling techniques both for modeling of the domain system (analysis model) and software system (design model).
So, before studying a particular modeling language and how to model, try to learn what has to be modeled. Learning the basic aspects of systems helps in handling the difficulties that arise from the fact that systems are composite in nature and that we commonly deal with multiple systems, i.e. domain systems and the systems that we are currently building.
Reference and an excellent further reading:
R.J. Wieringa. A survey of structured and object-oriented software specification methods and techniques. ACM Computing Surveys, 30(4):459-527, December 1998.
This is the conceptual diagram depicting the entities that exist in the video store domain. See Examples category for related posts.
Click on the thumbnail to see the full image:
Following is a use case that captures a simplified process of renting items from a video store. In the use case description, red color indicates system’s actions. See Examples category for related posts.
Name: Rent Items
Use Case Number: UC16
Authors: Davor Svetinovic
Business Event: Customer arrives at the rental desk with items for rent.
System: Rental desk computer system.
Actors: Clerk (initiator)
Purpose: To capture process of renting items from the video store.
Priority: 10/10-core business process, crucial for business operation
Overview: Clerk receives items from the customer; she enters them into the system; system calculates the rent total; system captures info about rented items and payment.
References: R23, R34, R45, R46
Related Use Cases: UC11 (Credit-Card Payment), UC12 (Cash Payment)
Preconditions: Customer is a member of the Video Store.
Typical process:
1. Clerk receives items for rent and starts renting process. 2. Clerk enters customer ID into the system. 3. System verifies customer ID. 4. System prompts for item IDs. 5. Clerk enters item IDs. 6. System checks which rental plan minimizes the rental cost for all items (see Note 1). 7. System computes the total for all items and displays it. 8. Clerk receives payment from the customer (If payment by Credit-Card see UC11, if by cash see UC12). 9. System stores information about rented items and rental plan used (info about rental plan needed for the marketing and recommender systems). 10. System marks items as rented (needed for Items Inquiry Use-Case). 11. Clerk ends session (closes account).Alternative 1:
4. [Customer ID not recognized] System aborts. 5. Clerk enters customer ID again (back to step 2) (or registers customer — precondition 1. does not hold).Alternative 2:
8. Clerk does not receive payment. 9. Clerk closes the customer’s account.Note 1:
Currently store has three plans:
Plan A: two old movies for 80% of regular value.
Plan B: two new movies for 90% of regular value.
Plan C: after ten Plan B rents, customer has one new movie for free.