Design program dynamic (runtime) behavior
Allen Holub Chief Technology, Netreliance 2001 January
In the previous article, we have refinered the problem description and establish a model of educational software. In this article, we will analyze research examples.
This article continues to explore my OO design process series. The first four parts are:
Getting Started Start Design Software Refining Problem Definition Verification Analysis
This month, I will analyze the dynamic (runtime) behavior of the program. For analysis, I will introduce the concept of use, and will discuss how to build one of them. Next month, I will put this structure in the framework of "Allen Bank".
Introduction to the Example "Problem Description" is now very good. I may have forgotten some of the key things, but silly sitting, don't, I don't want to expect these lost things. I will come out from my my head, just like Athena's head in the head of Zeus. By continuing to advance and study the same problem in another method, these lost things will gradually become clear. Then, the next step is to reproduce the problem, but this time is a research from a dynamic (eg, runtime) behavior. In a sense, the problem description is a static definition of the problem - it describes the problem that the user must solve, but only. Finally, I will make this system's views formally in the form of a static model.
The dynamic definition of the problem is not what must do, but how to do it. That is, it is better to study the problem itself, it is better to study the user to solve the problem. The main tools we use to build our ideas in dynamic behavior are the use case analysis. Dynamic behavior can also be represented in the form of a dynamic model, but before doing it, we must determine what dynamic behavior is. We will use the use case analysis to do this.
First, definition:
The use case is a single task that can produce useful results, executed by the system end user.
"End User" and "Results" can be diverse - for example, end users may be an automated subsystem, and the species of the results can also be fundamentally different from the use case. Sometimes the results are actual products, such as reports, and sometimes the results are company objectives, such as hiring an employee. However, the result is always a value that can be perceived (by the user).
It can be considered that the use case is in line with the user's intent. If the user enters the system to do something, then what do he want to do "What?" For example, login is not a complete use case, because no one will only want to log in and enter the system. You log in is to implement some of the other bigger goals, to perform some practical tasks, and the use case is the definition of the bigger task.
Indicates that the common situation in the use of examples is as common, and a sorted semiconductive use case represents you build a use case. Formal representation usually involves several parts listed in Table 1. (I will explain the contents of each part you will explain.) It is best to see Table 1 as a checklist, not a gap fill a blank form. Not all parts are related to each definition, and can be combined (or ignored) any part in the actual working document.
Moreover, although all categories in Table 1 must be provided, it is not necessary to provide them in the order specified in this table. Usually, it is best to start from the scheme, develop them into formal workflow definitions, and then fill in other details. The order in Table 1 is actually in order to facilitate the user of use, not the creation person.
Our designers have several main objectives in the process of creating the use case:
Improve the gradual understanding of problems. Communicate with end users to ensure that we are really solving their problems. Dynamically organize design (and final procedures) to reflect the real business model in the user's mind. In other words, make sure the program can actually do something useful for actual users. Provide guided instructions and structural frameworks for actual development processes. (In a few months, we will begin to discuss this, and this will be described in detail.) Table 1. Components of formal use examples
Name Description Expected Results User Target Participant / Role Dependence Pre-Condition Scheme Workflow Post Conditions Business Rule Demand Realization Precautions
Use an example definition is a collaboration process. Many of these components are specified by the business side (usually marketing) organizations, while other parts are filled or expanded by the technical parties. User interface design is also an important part of the use case analysis. The UI model (not prototype) provides a number of feedback information that has been properly captured to use. I will discuss the UI design based on the use case next month.
Now let's expand Table 1, explain the various parts of the document in detail.
Name All use cases should have a name. Constantine recommends using a nominal, followed by a direct object (for example: "withdrawing funds" or "check the passbook"). This agreed causes the case of the case that simply identifies the operation performed and the object (or subsystem) affected by the operation. I think this suggestion is good for the current situation, but if you don't want to miss important information, then it is not particularly benefit of adhering the formula. For example, "Customer WITHDRAWING FUNDS from Checking Account" and "Bank Manager from the customer's live account (Bank Manager WitHDrawing Funds from Customer`s Checking Account" is not the same use case. The name of the simple "withdrawing funds" cannot fully explain this.
The name should always be user-centered, not by the system. For example, the "deposit" (centered) is the opposite "accept deposit" (in system-centered). Name from the user's angle instead of naming the system's angle.
No matter which format, the name is critical - the use case must be explicitly identified so that it can be discussed effectively. I usually specify certain identities for each use, so you can easily reference it from other documents. Usually, I prefer to use a very general description, coupled with a hierarchical program (for example, "withdrawal: 1.1").
Description Describe what is implemented. For example, when "withdrawals" or "check the passbook", what is the user wants. Details, but do not describe how users use computer programs.
For example, bank customers will fill in a withdrawal order when withdrawn, and provide this cash on the bank. Then the sanner will pay the payer for the banking personnel to obtain approval. Bank executives check the account balance and formally approved, and so on. Please note that in this discussion, I have never mentioned the computer program, menu, dialog, and the like. With this level, these implementation details are independent. (Of course, although you still need a clear implementation details before starting the encoding. But we haven't started yet.)
I feel particularly headaches to mention the "system" analysis class document. It may be your problem that you have encountered when you create a "system", but it is not your user's question, that is, it is not an important user problem.
The desired results should have useful results according to the definition. There must be a meaningful job. The result is described here. The result may be a report (in this case, an example of a report appearance), an event or condition (now the employee will get medical allowance), or something similar, but must have a useful result. What is the real goal of user target users? Please note that the goal is not the same description. If the "Expected Results" section describes what the user wants to implement, then the "Target" section describes why users get this result.
Know that the user goals can fundamentally affect the development direction of the case. Drawing on the Alan Cooper example, suppose we are responsible for creating a meeting schedule. The use case of us is interested in "Arrange the Conference". The image of the calendar and about the book will be immediately emerged in your mind. But that way is similar to Microsoft Outlook - a bloated but difficult program, it can't actually do useful things for anyone (Allen, tell us what you think about what you think).
So how do I avoid our system like Outlook? To consider the goal. What is the expectation of the meeting? I guarantee that we have the same goal: don't go at all. In addition, our goal is to leave as soon as possible and make the meeting as much as possible. The only way to achieve this goal is to develop an agenda. Therefore, the first step in the "Arranging Conference" is the child use case "create a agenda". (Discussion will be discussed in detail.) The truly determined date and time will become secondary.
Participants in the participant / role case are not natural users, they are the role of natural users related to the system. For example, we are building an attendance card authorization system, then you will immediately want two roles: employee (fill in the attendance card) and manager (approved attendance card). In fact, the same natural person plays two roles at a certain moment, because there are two logical participants: employees and managers.
UML defines these roles into "participants". However, I have been cautious, I decided not to use the term. I think that the actual user is a participant in playing a role associated with the system. Participants are usually outside the system and have nothing to do with the system. It is really important that participants play the role. (Not me alone thinks "participants" is not a good term, see the reference.)
There is a special case regarding the rules of the participant outside the system. Imagine questions about access control: Suppose you are identifying a participant that operates in a program in a program. Therefore, participants appear in the program, map participants to their roles to make the program work.
CRC card For each role, we need to build two critical information:
The participant's responsibility when playing a role. For example, banks have accepted customers' deposits and withdrawals, and accept the bank executive. Participants' collaborators - need to communicate with them. For example, bank outgoing people are collaborate with customers, and also collaborate with banking executives, but the executive will never cooperate with customers.
These categories are the two components of the CRC (representing the Class / Responsibility / Collaborators ") card, which are used for some OO design methods, such as extreme programming of the Kent Beck. (CRC card is developed by BECK and Ward Cunningham for teaching assist; see the reference.)
Since this information is closely linked to participants, not a clear use case (ie, some participants who play a specific role may have to participate in several use cases), so the CRC card is sometimes used as a separate document referenced by individual use cases. It seems practical. Since we will perform UML dynamic modeling, the list of maintenance responsibilities will be very important. The dependency-dependent relationship is sometimes not present - but when a program is quite complicated, there are many cases, that is not more common. Usually, dependencies do not appear immediately, but will gradually expose as the use case model and the evolution of the relevant user interface.
Typical dependencies include one or more relationships:
Subset / combination typically starts analysis of top-level use cases and finds that the subset use case (I call Subcode) occurs when the complex task can be implemented by performing several smaller but independent tasks. Each of these independent tasks is a subset of the primary example. Regardless of the "decomposition subset" or "combination", this is actually a way to start. If you start from a smaller use case, then you can use the "combination" if you can combine them into larger use cases. If you start from a larger use case, then you have to decompose it, use "Decomposition Subscale". For example, although identifying yourself (login) is usually not an example of using it now (you don't just want to identify yourself and enter the system, then shut down, go home), but it may be a child use of other use cases. Moreover, in all cases that need to be identified, the identification process may be the same. The "Identifier I" sub-use case should be created and specified to be similar to the independent use case, and then combined by reference in the primary example. This relationship is very similar to the child use case relationship; do not waste a lot of time to worry about which one is better in "use" and "child use case" relationship, because these two relationships of these relationships when using the use case document Are the same. The main difference between "subset" and "use" is that when the use case is both a subscriber or an independent use case application. (It defines a separate operation of a useful result.) Subset relationship is sometimes used to distinguish a sub-case used by another top-level use case, and the "use" relationship may describe a sub-case used in all occasions. The front / after this relationship establishes a workflow between use. For example, "Registered Customer" must be before "Specify Order" or "Browse Product Catalog". Pre-demand / post relationship representation, but is not dependence. That is, "The goods purchased in the purchase of the goods" use cases must use "registered users", but "registered users" is just before "browsing goods directory" - it is not a necessary condition. Extended / exclusive if the use case B extends with example A (ie, add sub tasks, operation, etc.), then b is a special case of A. (Usually, additional tasks are required to meet special needs in some common use.) For example, "Identifier Manager" may belong to a special case of "identifying employees", because the manager must be identified to have higher than ordinary employees Safety standard. (The programmer refers to this exclusive relationship as a derived. He will say B "from" A to represent B is a special case of A.) Similar to usually, you will notice that two use cases in the workflow are similar to each other. Although there are some small differences between them. Similar relationships indicate that you should pay close attention to similar examples, try finding a common point, which can be broken down into "subset" use cases or equivalents. Equivalence from the user's point of view, two use cases may differ, but their implementation is the same (in the "Allen Bank" example, the logic difference between equivalence cases). Whether the basic code is the same as the user - deposit and withdrawal are different logical operations. In any event, the equivalence case is in the design process.
I found that the UML static model diagram indicates that these dependencies are very useful. (In other words, the formal case mark method of UML is almost worthless.) Constantine and Lockwood have proposed a chart representing the representation of the case relationship, but I prefer to use standard UML, when there is no use of ready-made representations, Standard UML uses a fixed form. I will give a specific example in the future (in the "Allen Bank" project). Pre-condition When running the case, what assumes you will do about the system? For example, the user must have an account in the bank before withdrawing. Therefore, the "Customer Open Account" must be performed first before you can execute the "customer withdrawal".
What are the conditions necessary before you can successfully complete this case? The conditions can be internal or external. For example: The account balance must be greater than the amount of withdrawal.
The solution solution is a short narrative description of someone's use case. From the perspective of the bystander: What happened to the bystander described as an observation event.
Since it is a description, I try to make the scheme abstraction (discuss how to use banks, not the simulated bank computer program). "Philip needs to withdraw money to purchase food. He turned out of a lot of dirty socks from a big pile of socks from the top of the wardrobe. It was found that the deposit balance was enough to meet his needs, and then went to Bank ..."
Some of the programmers believe that the program is worthless, so it does not use the plan, but I found them very useful. The most important use is to clarify my ideas. Usually, when the scheme is completed, I will find the use case that has not been thought of, or I will find a workflow problem that has not been previously emerged. For example, some issues occurred before withdrawals. (If he can't find a passbook, what should I do?)
Imagine a case where there may be several related scenarios. At recent recent OO design special academic sessions, we chose the Vanderbilt University course registration system as a sample item. There is only one advanced use case, namely: "course registration". However, in this use case, we think of several solutions:
I sat down, sign up for all the courses I want to learn, join these classes, I am very satisfied. This solution - everything is unobstructed - call (at least I am called) "all the way the wind" program. I registered the course to learn, but there is a class that is already full, so I was put into the list of candidates. In the future, this class has an empty place, I will be automatically registered, and I will notify me to participate in the class' s learning. Same as subsection (2), but I must learn this course - I have to join this class. Other solutions
When analyzing these programs, I will determine that the second and third programs actually contain an independent use case with "all the way to the wind" scheme.
Please note that some programs are failed, but this group of options should not be regarded as only a "all way to the wind" program and many failure schemes. In the course registration example, a real failure is that you must learn a course before you graduate, but you can't join this class.
In fact, there is no way to fail in most of the most correct use! At first, this amazing discussion is not as shocking as expected. Most computer programs use error messages as a way to cover up programmers. In fact, most "errors" may be processed by the program itself. However, due to the way the programmer is too lazy to find an error, the error message will be printed in most cases so they pushed this job to the user. Take "class full" as an example. The lazy designer will say "Oh, the class you have to participate is full. It is a pity. I can't work", and will pay this situation as a failure: the excellent designer will seek solutions, such as Our alternate list strategy. As a designer, the user should solve the user's problem, not the problem again to the user. Alan Cooper does not even print an error message at all carefully prepared programs. I don't dare to affirm whether the goal is able to be realized, but I will bet you can eliminate 90% of the error messages in most programs, eventually get a more convenient system. In addition, for programmers, please note that there is not a serious fatal error at all in the use case - this error can result in thrown exceptions. These conditions represent the failure of the program - they are related to implementation, but they have nothing to do with the problem area, so they do not belong to the use case analysis. Keep in mind that we are defining questions to solve from the user's perspective, we are not designing computer programs (not yet arrived). The design procedure should wait until we fully understand the problem. The abnormality throwing error condition is actually realizing the needs (see section below), should be listed in the "Requirements" or "Implementation Notes" section.
Do not use the above discussion as an excuse without considering failure conditions. Your goal is to consider all possible failure conditions, then make sure that it will be properly handled every time there is a failure condition. Creating a work document that lists all failed methods will not be harm. This list can then be used as a test table when reviewing the use case to ensure that all failed methods have been considered.
The last consideration, the sales staff will find the program to be useful when summarizing the statement. It is always good to sell products you are building.
Workflows are usually, and the use examples describe a workflow in a simple case ("execute A, then execute B, and then execute C"). Sometimes the workflow is very complicated, so it should not be fully described in the "Description" section, and sometimes charts (such as the UML workflow chart, I will stay in the final discussion) to clearly define the workflow. Fill in this information here.
The rear condition case often changes the system status (for example, the account balance is now declined), rather than generating actual products. In addition, other use cases need to be performed after some use cases to complete the entire task. This type of information should be filled in in the Post Conditions section. That is, the rear condition can be checked after the use case is completed, so that the use case is successful or failed. Example of the rear condition: The new balance is the old balance deducted withdrawal amount.
Business rules business rules are a strategy established by merchants, which may implement the results of the use case. For example, "Your weekly withdrawal may not exceed 20 madlings." Before you use the Example Description, you should not include these rules, but you should specify these rules in some way so that the document can be used correctly and can be used. I have found that these rules are best specified in a separate document and then reference these individual appropriate rules in the Business Rules section.
Demand demand is usually the behavior constraint specified by the customer. ("It must be supported 10,000 transactions per minute.") Reissue again, preferably in a separate document to specify and reference requirements.
Please note that some things called "demand" are actually "demand". UI design is usually specified as a "demand", but true demand is usually not the appearance of the program, but what it does. If the actual user does not expect whether the program uses the kidney nesting purple red button, then there is no "demand" that uses the nesting nesting purple red button, no matter how much you like. (In other words, if the user is concerned, then this is a demand, no matter how small. This is the case.) I have had a customer, he often says "users need [some functions]." What is the user? " Tell me their name so I can call them, and discuss them. "Due to actually there is no such user, it is easy to ignore these needs. This is not to say that the designer sometimes does not consider useful features, but unless there is a real user cares about your innovation, they will not be practical. It is easy to force your users to accept some bad innovations, but these innovations can't do anything, will only give them trouble when users use programs. This temptation should be refused.
One good test for demand is to reject all the so-called needs (UI views, program structure, etc.) specified before the natural product of the design process. This "demand" is just a wrong design. Remove this garbage from the demand document. If you have a well-trained commercial development team, there will be no such "demand" from the beginning in this document.
Finally, please note that OO designers cannot work from the "Function" list. Function lists may be a collection of unsolicited ideas that is uncomfortable, these ideas are suggested by certain customers without the brain consideration. The sales person will then convert this suggestion into "Oh, God, we must design this function!!!", Then we do this. They are mostly recommended in research, but they don't know if they are correct. What you are interested is why these features will be proposed. How does this specific function make the user's work easier? What do users want to implement? Does your other customers want to implement the same thing? Is there a better way to achieve the goal? The most important thing is whether the task we want to perform is the use case we haven't encountered before?
Precautions Although our goal is to use an example document as much as possible in the problem area, it is natural to achieve the details of the implementation of the scheme and workflow. When it appears in your mind, you should capture this information, then this clip can make your grass to make a consideration. These precautions are not specific. They are not norms. In fact, they will affect the implementation and the details related to the current use case. They will guide the design, but do not control this design.
Endy language is therefore, this is the establishment process of the use case. Next month, I will develop some cases for the "Allen Bank" project to demonstrate how to apply this theory. The subsequent article will also demonstrate how to use the UI design, and how to build a formal dynamic model according to the use case.
Reference
Ivar Jacobson, Object-Oriented Software Engineering: a Use Case Driven Approach (Reading: AdDison-Wesley, 1994; ISBN: 0201544350). This book is one of the best books to talk about the use case. Although Jacobson is a pioneer in this field, I still have different opinions on the views such as use cases. But I still listed this book because it is very basic, but it is written to me. Larry Constantine and Lucy Lockwood, Software for Use (Reading: AdDison-Wesley, 1999; ISBN: 0201924781). This book describes the UI design method based on the use case, called the use of usage. This approach is one of the best formal UI design methods. The first quarter of this book collected a good use discussion. LARRY Constantine and Lucy Lockwood, Structure and Style in Use Cases for User Interface. This book provides an overview and expanding the design method discussed in Constantine and Lockwood's work. It is a good summary introduction to this topic. Russell C. Bjork, An Example of Object-Oriented Design: an atm Simulation. These are Bjork Dr. Bjork's class notes in Gordon College. Although I was not satisfied with some information, BJork did introduce a complete design method (including the use case) from the OO design process. Kent Beck and Ward Cunningham, a laboratory for Teaching Object-Oriented Thinking. (Excerpt from Oopsla'89 Conference Proceedings October 1-6, 1989, New Orleans, Louisiana, and Sigplan Notices Volume 24, Number 10, October 1989 Special Issue.) This book describes the initial use of the CRC card in the classroom environment. About the author Allen Holub is the Chief Technology Officer of Netreliance, which is located in San Francisco, which is a global foundation design for implementing security on the Internet.
He has been working in a computer field since 1979, published a lot of articles in magazines (Dr. DobB Monthly, Programmer Monthly, Byte, MSJ, and other magazines). It writes the "Java Toolbox" column for online magazine JavaWorld and writes the "OO Design Process" column for the IBM DeveloperWorks component area. He also hosted the ITWORLD Programming Theory & Practice discussion group.
Allen has eight books widely praised, and the latest one describes the trap and defect of Java threads. He is engaged in designing and building an object-oriented software for a long time (with C and Java). He has been taught OO design and Java since the University of Califer University in 1982. You can access Allen's website http://www.holub.com.
