Detailed explanation
ALLEN HOLUB (Allen@holub.com) Chief Technology, Netreliance 2001 April
In this month's article, I will continue to fill in the first (deposit) use case template for the article on the use case planning last month. I don't only fill in the template and provide detailed comments on the process of thinking about the process.
Several initial annotations for how to build an example document are ready. Consider how to use the template, I have arranged all the templates. However, the order of creating a template is rarely the same as the order of the template. I have introduced the use case in the order of the template, but when I really put things together, I will not stick to a form. I started from the name and description, then enter and launch a little program work, then enter and add an annotation of the realization, and then turn over and make certain plans work. Then, I fill in the desired part of the desired result, adding the post condition, so that a round of one round is done.
In addition, in the real world situation, few people can develop throughout the use alone. Ideally, the business-related components (with example name, description, program, user objectives may have a desired result) will be mainly developed by the marketing party, and the engineering party plays a consultation role. Technical items (dependencies, pre-conditions, and post conditions, formal workflow analysis, implementation needs and annotations) will mainly come from engineering, and marketing organizations have a consulting role. Business rules and demand usually create together. If a reality customer - the actual user of the product - is also better in the process.
You will design a few components parallel. It is natural to find problems to date when developing cases, and should be returned to the problem statement before forgetting. Save all kinds of documents that contain all phases are real problems with large design, but it is critical. Once the defects when thinking about the problem, you must immediately change all the corresponding documents. I usually work in me, I will put the problem, all related example descriptions, UML maps and code are placed in front of me. When the method taken is not pair, it is important to roll back to the previous design, but I don't know if any automated document management packages can do the real "painless" rollback, know that the design is made up of many types. Document - drawings, formatted text, ASCII source, etc. - consists, and they may be influenced by changes. (If anyone knows the document management system that can compete for this task, please send me an email.)
Now let's see the first use case.
Sample use case
Name 1.0. Little child deposits funds into the account. Describe the child (customer) deposits the money into his / her account. Before the deposit takes effect, it must be recognized by the bank executive / parent.
This is the concept of an authorization in the context, and it is an instance of how to write a use case to identify the defects in the problem statement. When I handled this case for the first time, I wrote "Parents and this use case." But my later idea is "How can I prevent children from being stored in any number of money?" The recognized concept solved this problem, but Also introduced a few interesting solutions, I will discuss it.
The original problem statement is indeed related to security issues, but the way used is not working. Here is the corresponding part of the original problem statement:
Original problems have several security issues. Like real banks, children can't make deposits or withdrawals through themselves; they must ask banks to do this. Bank handles this transaction and updates the passbook. In other words, the child handed the money to the bank, and the bank put the money in the account. Bank takes out the money from the account and handed over to the child. (In fact, this means that only parents can deposit or withdraw money, but parents should handle withdrawal requests as required, otherwise children think that banks are a liar that does not let them get their own money.)
Looking back, the bank will take the money from the account and deliver the kind of exercise, because the bank does not do that thing (the bank executive, the bank is not done). Therefore, I have returned and modified the problem to make parents more consistently discovered in this case in this case. Here is the part of the correction:
Corrected problem statement
There are several security issues. Only bank executives (ie parents) can change interest rates, set up new accounts (and initial balances) or turn off account. Despite the vast majority of transactions, children can use banks completely independently, some transactions (deposits and loans) require approval of parents / bank executives to complete. This transaction is visible for children and is displayed on the passbook, but unapproved deposits cannot be used for withdrawals. Parents need to be approved by withdrawals. The withdrawal requirements will cause a check to be printed. These checks can be used like a real world check. If the check is lost, a command to stop paying (requires charge). Check can be handed over to the bank (parent) to exchange cash.
I am thinking about the question of the check at the time of writing - another example of how the design process works. When considering problems from different angles, some parts of the problem are found.
Of course, after changing the problem statement, it is now necessary to obtain the approval of the field expert to check in new versions. (Since I do myself, it is a field expert, it is simple.)
The expected result of the account balance becomes larger user target child: makes the account balance as much as possible and focused on the accumulation of wealth. Parents: Make sure children do not use unauthorized arbitrary deposits to expand the balance.
Please note that the system's different users have different goals, and these goals are often mutually exclusive. The child wants the account balance to be arbitrarily, and parents want to ensure that only true funds - the truly funds of children - are deposited. This kind of target conflict is not rare, so one of the main points of current exercises is identifying (and resolved) these conflicts.
Participant / Roles I will identify roles using the CRC-Card format discussed last month. Similarly, this list is gradually developed during the operation of the program; you are here seeing the final form of the list.
Please note that some participants are automated (cashier) and others are real people. It is also important to pay attention to some participants are passive objects (passbooks) in the system. This is where the use case developed with the UI may be different. The use case of the UI style is usually only the role of the actual user of the system. In the OO system, even if it is considered to be passive objects, it is also defined on its responsibilities and operations. (For example, the passbook may print itself.)
Kid (Bank Customer)
Fill in the deposit slip. Hold a passbook. Teller (requesting a child) Parent (bank executive)
Approve deposit Teller (request deposit) Teller
Pay deposit slip. The deposit will be permitted from the bank executive. Update the passbook. PARENT (Authorized Transaction), KID (request) Account ???????? Passbook
Tracking trading history Kid (see it), Teller (updated it) Deposit Slip
Identify deposit amount kid (fill in it), Parent (recognize it), Teller (pass it to passbook), passbook (record it)
Keep in mind that the organization I introduced here is more designed for easy use cases instead of the creator of the use case.
Surprisingly, I can't think of what the Account class can do in this system. The current balance is saved by the passbook, and the passbook also saves the record of the account transaction. So I suspect that the account and passbook are one thing; Account is done to assign some identification information to the transaction record. But if the child / customer holds their passbook, there is no need to store identity information in the account; just get a passbook from the child and find the account they own. This problem actually emphasizes the difference between the physical relationship (ER) of the database style and the object-oriented (OO) worldview. A worldview map is another worldview called an object-relational map, and this mapping is very straightforward because there is a coordination of two conflict organizational strategies. A good object model rarely generates a good database mode (vice versa). In the current example, a ER worldview may treat Customer, Account, and Passbook as a valid entity. Customer includes customer-specific identification information and identifies the various accounts owned by the customer. The Passbook contains trading history, and Account contains account specific information, such as the current balance. Since I have just discussed the reasons, the object model does not work in that way. Since there is no thing to do it needs Account, then it is not a legitimate class.
In the OO system, the class should not exist if there is no matter; there must be a responsibility (operation). In fact, the class is defined in full depending on what it can do - it is used to implement data that should be hidden in the external world. Accounts may package data, but I can't think of any operation it will perform, so Account is not a suitable class. (For more information on the OO system in this way, see Resources.)
On the other hand, the worldview of the object modeling and entity modeling is fundamentally different. Object modeling is almost only interested in operation - what is doing. Object implementation These operations must be saved in the early stage of design processes. Object buildings care about static properties only when it can be used to distinguish between one type of object and another type of object. (For example, employees have salary, and ordinary people don't, so the salary attribute can be used as the distinction feature of Employee.) However, database entity modeling only focuses on static properties - the operation is non-substantive. The net result is the organization of the entity modeling is the organization of the curse (there is no state data, one-to-one and multi-to-many relationships between classes.) In the OO system, it appears everywhere.
The final cultural conflict problem surrounds static data. For example, in the OO system, members of the committee will be effectively included in the committee class. That is, members will be static attributes of the COMmittee class. In a relational system, it is more common that the committee identifies as the attribute of the member (so that you can connect or select on the committee name).
But my approach is against the principle of the previous. Although I have already said earlier, I still have "account" to temporarily reserve some of the operations on the list in the list. But I suspect that Account will eventually disappear.
Half template has been completed - to some extent, this is less meaningful, because these parts of the template are more useful for organizing my thoughts, rather than actually explaining the progress of the use case. Next time I will provide more meaningful parts of the use case definition: the program and activity map. As the use case progresses, these parts actually try to develop workflows.
Reference
This article continued the series of articles on the OO design process. The first six parts are:
