Complete use case
Allen Holub (Allen@holub.com) Chief Technology Officer, Netreliance, May 2001
This article is the continuation of the series of articles about the OO design process I have written. The first seven parts covers the planning phase, from the initial design to problem statement, and start use cases. Before the next month, I will end the discussion of the use case this month.
I will continue to fill in the remainder of this use case template for "deposit" use in this article. As in the last month, I not only fill in the template, but also provide a detailed note for the process of thinking. This template is partially described in some extent this month to describe the true substance part because it actually describes the workflow of the progressive progress. This workflow is required when the user is running by using an example.
In my last column article, it tells about half of the use case template content. I will continue this topic.
Fill in the use case template for "deposit"
Dependency
Similar to: 2.0. Children take money from the account. (Equivalent?) Previous example: 4.0. Parent account includes: 6.1. Parents approve a deposit after one use: 6.0. Parents approve earlier deposits.
This list is tentative. For example, the "similar" relationship of the use of Example 2.0 may actually be "equivalent" relationship.
prerequisites
Accounts must exist.
enter
The child earned some money.
Program
("All the way the wind") Philip done after the day's housework decided to save the $ 2.25 to Allen Bank. (If he is doing a family every day, I may now go bankrupt.) He entered the bank, and wandered a deposit slip to the cashier. After filling the deposit slip, put the deposit slip and his passbook to the sanner. The cashier requested certain authentication before accepting the deposit slip, and then deposit the deposit slip to the bank executive. Bank executives (parents) approve deposits in deposits, then return it to the horses, and the people will update the PHILIP's passbook to display this transaction. Then the sanner will return to Philip, and he can enjoy the deposit balance that you are growing.
Please note that in this scenario description, I carefully use the problem (for example, "passbook," "" in the previous section of this series). As long as I introduce new concepts here - the situation does happen - I have to return to the head to modify the problem to introduce new vocabulary. An important (also difficult) target for designers is to keep all design documents to maintain "coordination". If the changes in a document affect another document, then these two documents must be changed immediately. For example, I am intended to say that "the walker makes a log item that reflects the savings transaction", because "log" does not belong to the vocabulary in this area, "the passbook" belongs to it. For design, there is no difference between "log" or "passbook".
Also note that I didn't use the word "system". "System" does not do anything; all work is done by participants who play "carefully designed" roles. Some participants (children) are real people. Other participants (cashier) are fully automated. There are also some participants (bank executives) in some cases automated, in some cases, the real person (some responsibilities of the bank executive by parents rather than computer). What is important is "role". As for participants playing "role", it is not automated.
In this scenario, the money is actually added to the account, more accurately, this deposit is entered into a state of "unapproved" state. Any parent can approve the transaction in subsequent time. In other words, deposits are in the "detain" state before approved. The cashier will return to the child and will reflect this deposit on the passbook, but the money cannot be taken out from the account before the parent signed on the deposit order. (This program is different from the "all the way to the wind" that there is no parent to approve deposits.) In this program, parents save money for children (unlike the trading approved by children).
At this moment, compared to other words that are not too losing, I think the word "child" is quite wrong. I also use the words of children - rather than using children, customers or other equivalents - is because internal consistency in the entire design document focuses. But I still hope that I can make more cautious when I choose terms.
The second program actually introduced a new use case. This is my previously didn't realize: "Parents approve priority to deposit". This is indeed an independent use case, even if it is approved in the current use case (means a child case: parental approval).
This part of the workflow is a key, so I will use the slightly different format that I have been using so far and how the workflow is developed. First, I will model "all the way to wind" as a simple list.
"All the way the wind" program:
The child receives the deposit slip from the cashier and fill out. The child submits the deposit slip and the passbook to the sanner. Cashier verify that the child's identity is effective. The cashier will pay the bank executives to obtain approval. The bank executive returns the deposit slip to the NS, marked as approved. The cashier writes a record in the child's passbook to display this deposit. The cashier will pay the pass to the child.
Although it is very effective for simple workflow linear lists, it cannot meet the requirements when the workflow is complicated.
Constantine and Lockwood recommends that use like "in any order when nonlinear operation:" is followed by a list. You can also use "simultaneously" to follow a list of concurrently.
Maybe I am a person who likes visualization, I found that these only use the text to express the use case will make people confused. When the use case is very complicated, I prefer the UML workflow chart. The UML of "all the way to the wind" is shown in Figure 1.
Figure 1. "All the way the wind" workflow chart
The symbol is almost exclusive. Each box represents an activity and the arrow indicates the workflow. Starting from the solid circle and ends with an air circle. These columns, called "Swim Lane", identifies classes responsible for performing activities (or subsystems).
When you look at the picture, I noticed that some places can have parallelism. That is, some activities (verifying the identity and approval deposits) can be done in parallel. (You may find that if these activities are executed before these activities are performed before the next step, the order they execute is not important.)
Figure 2 shows the modifications made to Figure 1 for reflecting parallelism. A crude horizontal line starting with a parallel behavior (on the top of the flow chart indicating this set of behavior) is called "fork" (fork). The bottom line (indicating this, these parallelism must be synchronized before proceeding with the next step) is called "Join).
Figure 2. Modified "all the way to the wind" to reflect parallelism
Now I have returned to two other options and tried to merge them into the "all road" chart. (Modified Figure 3.) Usually, if it is impossible to merge these schemes or the merged graphs are very awkward, then these additional scenarios may be independent use cases, rather than the current use case. Of course, these programs are currently consolidated.
In I realized that if I allow parents to do a child's role, the workflow is in the same way as "all the way", solving the parents for the deposit of the child. That is to say, the parents' password can be used to log in to the child's account. I will put this result in the active map (Figure 3) and the business rule part (below). The second program (parents are not present) is slightly difficult because I have to introduce branches (in Figure 3 with a diamond shape indicated by an input arrow and multiple output arrows). Control the condition of which output path (called "Guard) is a text tag on the online. Merge (also represented by a rhombus, but multiple input arrows and an output arrow) tag condition behavior terminates. Each branch should have a corresponding merge.
All complicated situations between "bifurcation" and "conjunction" can be expressed as follows: Try to verify the identity of the child and mark deposits in the case of parents, or marked as unauthorized when parents are not present (this The two processes are inseparable from the order). The passbook is updated when both activities (verification and tags) are completed.
Please note that the original program describes the instructions to detail unapproved deposits. When using this picture, we can clearly see that the unapproved deposit detained in the passbook is much more convenient than the out of the sonas, so I do it. I turned back to modify the program description to reflect this change.
Figure 3. Addition of additional programs to "all the way to wind"
Rear condition
New account balance = old account balance deposit amount
Note that this use case contains two different operations that do not have to occur (deposit requests and deposit approval). However, this is indeed a single use case with a single result. The account balance will change, even if the deposit activity is separated from the approval activity.
Output
Updated passbook.
This part will be where the output form is displayed (eg, in the form of a report). I will postpone this part until the article began to solve the UI in the article.
Business rules (related to the field)
Parents must be approved by parents before deposit effective. Interest Self-deposit is calculated on the same day, even after a few days later. Unapproved deposits can be in unprotected states, waiting for parents to sign. They don't "expire". Parents' password will verify the child. That is, parents can log in as a child.
Demand (related to implementation)
The deposit must be automatically "saved". There is no "File / Save" menu here. Explicitly "revocation" is not necessary. You can use money to revoke deposits. When the child looks at the passbook, the deposit of "detain" must be displayed. Show the deposit detained in gray.
If I say "highlight in some way" instead of "display with gray", then I will adventurize the meaningful specification. At the end, the specification must be clear. Since you have to make a decision, then you will start now. If you do a wrong decision, you can always go back to make changes (of course, before the specification is officially approved).
Decision for me to make a mistake is better than deciding. Many of the so-called specifications I have seen are too straightforward, so that hundreds of different programs can be generated from this specification, and all the programs are in line with this specification. This unclearness is harmful than it, because it prompted you to do some incorrect work.
In the current case, I think this problem is too trivial, so I don't have to decide. As long as this is highlighted, it is not important to do it. Thus this decision can postpone the official UI design process. If the concept of highlighting is fuzzy, the various programmers that implement the design will be implemented according to the understanding of this concept, resulting in ui inconsistency, and the result is more difficult to use.
Realize annotations
There is currently no login concept. Looking at these programs, Philip does not make a few deals at a time. In fact, it is more likely that he only makes a transaction, but forgets to cancel it. (This is the behavior I observed at home - Philip often plays a game machine in the morning, and I will find that the game console is still driving after 12 hours, that is, after he goes to bed, accept this behavior, accept deposits Single also requires some kind of verification that seems to be more secure. This is also the original way of operation of the true bank. Similar to logging, it is indicated to the security guard before being allowed to enter the bank. (That may be a reasonable method, but I don't choose it.) Please note that there is no ban in this case to remember who Philip is. That is, the customer is labeled "trusted" in some way in the scope of this use case, so that the subsequent transaction can be performed without the need to repeat the verification process. "Trusted" attribute can be canceled by logout, or simply cancel this property after a given time. (For example, if you still have any activities after you have two minutes later, you will become untrustful.) (Before we start the real object modeling, you may not understand this annotation, so if you don't understand it now, don't have to Worried.) In most cases, the child is an external object. That is to say, there is no programmed object in the system to indicate a child; more accurately, the child is the physical user of the system. On the other hand, since an object in the system must handle verification, the concept of children's identity will certainly be modeled. "Available funds" is different from "current balance". (The latter does not reflect unapproved transactions.) Since the child thinks deposit is deposit, whether it is approval, the passbook should display the value of the two. Anyway, telling the child "detain" working principle is not harmful.
I haven't sure how to detention in UI is the best. One of the solutions is to detention in the deposit order, but the deposit will be displayed correctly after the deposit will be approved by the deposit slip. Another possible solution is that the deposit icon is displayed on the passbook as the approved deposit, but with some visual tag (gray text?) Indicating the deposit being detained.
The latter is better, but this means that the use case of "Parents approved the current deposit" will be significantly different from the use of "Parents approved the deposit".
Please note that if the sanner is approved for parents, the child will have to invite the Nassuna to see the passbook, so that the cashier can display the detained deposit slip and passbook.
The best way to solve parents may be the deposit order itself on the UI. Perhaps there is a "approved" box that will pop up a small dialog box after selecting it to enter the signature. Another method is to have an "approval signature" column on the deposit order, and parents can enter "consent" phrases in it. (Please pay attention to the approved instructions - for example, the signed copy - should appear on the approved deposit order). Please do not display X (or at least to: Once the signature is verified); if the signature is verified, it is not necessary to disclose the number of fed characters through the verification. Here are some access control issues. Participants who play children can specify deposits, but they cannot approve deposits. (Approved the account balance and passbook being updated.) Players playing parent roles can specify deposits and approve deposits. The system must be able to distinguish these two roles - password verification is sufficient.
Interests that detain the funds will be accumulated, even if they cannot be used. The best way to deal with interest is to treat the passbook as a list of transactions, sort by date. When the deposit is not approved, it will be inserted in the trading list in the ranked order. Interest will be recalculated from the time of recently inserted transactions. If this method is used, unapproved transactions do not actually have interest.
However, you may want to show the growth of interest according to the number of days, so it is not enough to listen to the transaction like the real bank passbook or bank bill. You actually need a line of items every day. But there will be a lot of rows. A reasonable compromise is to display the previous 30 days of information on the basis of the daily interest, and the remaining part of the memory is as follows, the standard bank bill is displayed, and it may be announced once a week. This is the complete use case introduction. In order not to make you boring, I don't introduce the rest of the use case in the subsequent article, I will put the entire process of setup bills on my website (see Resources) so you can browse in the spare time. Next month I will continue this design process: study UI design (it is essential, not only because we will have to build it, but also because the UI can be used to verify these use cases and provide useful communication tools).
