OO System analyst Path--use Case Analysis Series (7)--Preparation of use case specification--business rules and entity descriptions

Let's talk about business rules first. The author is accustomed to dividing the business rules into three kinds.

One is the global rule, which is generally related to all use cases rather than to a particular use case, such as actor to manipulate the use case must obtain the appropriate authorization, the action of the use case is related to the authorization level, or the user's actions in the system are recorded and so on. These rules are used by the authors, and they are also recommended to be written into the supplemental specification of use cases, as they are generally not directly related to specific business functional requirements. Sometimes, such rules are also written to the software architecture documentation. We will discuss the use case supplementary statute later.

The second is the rule of interaction. This rule arises in the use case scenario, such as what data must be filled in when an order is submitted, and whether the user's identity is legitimate. Of course, including general understanding of the business process flow rules, such as the amount of more than 10,000 yuan orders are designated as VIP orders into special processes. Such rules are generally written in the use case specification. Interaction rules are actually two more special, an entry condition, also known as a precondition, that is, actor satisfies what conditions to start the use case, and the other is the export condition, also known as the post condition, which is the result of the use case after the end. See the example later.

The third is the intrinsic rules. The so-called intrinsic rule refers to the rules of the business entity itself, and does not vary by external interaction. For example, each order must have at least one commodity, the same number of goods can not be greater than 5 pieces. It also includes the familiar data parity rules, such as the ID number must be 15 or 18 digits, the postcode must be 6 digits and so on. Such rules are intrinsic to the business entity, and should therefore be written to the domain model document, which is later referred to in the example.

Readers may find it troublesome to have different habits and understandings of classifying rules in such a way. But the author has a good reason for doing so. First, global rules have nothing to do with specific use cases, they are actually the characteristics that the system should have, and these rules are designed to allow the system to be responsible for the implementation of these features. The reader can consider with the actual consideration, the general authorization, the transaction, the backup and so on the characteristic all is realizes by the system framework, the concrete function does not implement them. If the reader has had the experience based on a framework development application will certainly agree with the author. Second, the interaction rules are created in the use case scenario, and they specify what conditions the business will respond to. In general, this part of the rule is the most complex, and most unstable, most likely to change. What you call a constant change in demand is believed to come from this. It is therefore necessary to list these rules separately and to give them attention and management. At the same time, this part of the rule is usually implemented in the system with the control class, as in the MVC pattern, as well as in BPEL in the SOA architecture. If the requirement is unavoidable to be changed, the interaction rule is extracted separately and designed to be a highly scalable structure is an effective coping method. Third, the intrinsic rules have nothing to do with external interactions, no matter who, under what circumstances to submit orders, must have at least one commodity; no matter which country you are in, what road you drive on, the brakes are essential. What does this intrinsic nature make you think of? Object-oriented encapsulation principle, right? Such rules should be implemented into your entity classes, regardless of whether your business entity is Entitybean,javabean,pojo or COM +, according to the object-oriented encapsulation principle, the intrinsic logic must not let it expose to the outside.

This classification provides a good level Reference for organizations with a higher degree of software maturity. If you are an architect, you should focus on the global rules; If you are a designer, you should focus on the rules of interaction; If you are a programmer, you should focus on the intrinsic rules.

Here I would like to say Han:). The author has read an article "The Architect is dead" (I'm sorry I can't remember the source and the author, if there is any offense please Haihan, the author's view is that after the architectural design is completed, usually to the end of the final change, since at first it is impossible to take into account all the possibilities, such as in the development process of continuous summary, refactoring, The final architecture will come naturally, if so, what is the use of the architect? I think this statement is reasonable, but to see the software organization structure and software process definition, can not be generalized. The author of "Frame" is an XP fans, for the XP software process, there is no need to architect this role, even the design does not need, development, testing, improvement, refactoring ..., of course, from the outset did not intend to follow a stable approach to do, the architect is not necessary. The architect is dead in XP, but still alive in RUP:). The software industry has been arguing with XP and Rup, the author does not intend to enter this dispute in this article, but the words have been here, the way to express the author's point of view. Both XP and RUP are excellent software methods, but each has its own scope of adaptation. For small and medium sized companies and small to medium software, XP is a very effective management method, which can greatly reduce management, development costs and technical risks. But if XP doesn't apply to big companies and large projects, RUP is a good fit. Can you imagine what it would be like for Lockheed Martin to develop a F-35 fighter with an XP approach? No one knows the future of the aircraft as a whole is what, anyway, first build a out, fell looking for reasons, improve, reconstruct, rebuild a .... It's okay, let's embrace the change and recreate it. Oh, that XP under what circumstances apply? If you are the owner of a grocery store and don't know what kind of merchandise is popular, it does not matter, first into a small batch of goods, sold on a period of time, the popular goods more into the unpopular, and more exchanges with customers, customers like what the goods we go into what, continuous improvement, the end will be customers. If the boss does business analysis first, customer relationship analysis, consumption curve analysis .... It's not open yet, it's going to go bankrupt. In addition, RUP and XP are not either or the relationship, in the process of making F-35, for the overall aircraft, with the RUP is suitable, specific to the engine provider, it is a big can XP, and ultimately as long as the provision of qualified engine OK.

The digression says a lot, the book goes to the True story. After classification of business rules, they should be investigated by category.

Global rules are difficult to investigate from users, which is often a blind spot for users. This is mainly by the experienced system analyst, or architect and the client's IT department (if any), from the business characteristics, application environment, industry regulations, laws and regulations, and so on to summarize, and then obtain the approval of the client side.

Interaction rules come from the use case scenario, where each interaction in the scene may imply a rule. This requires more discussion with the customer. Please refer to the 3rd article in this series on stakeholder discussion, the most important source of interaction rules is business and business managers, and it is best not to find business executives.

The intrinsic rules are for business entities, so make a list of the attributes of each business entity and find out their rules. The most important source of intrinsic rules is the business performer, and the demand staff should communicate with them more.

Now let's talk about the attributes of the business entity. The attributes of a business entity should be described in business terms, not computer terminology, at this stage. The research scope is each entity in the domain model derived from the previous model, and the original source of the attribute is the customer's various actual forms, as well as the various requirements that the customer presents during the communication process. If the business entity has a state and is more complex, there should be a statechart diagram to illustrate when modeling. Refer to the state diagram below the ' book ' business entity in the modeling example provided in this system article. Please note that in the example provided later in this article, the business entity description looks like a data table, but it is definitely not a datasheet. It is a business perspective description of the entity attributes in the business. System analysis is not about design, there is no idea of design or implementation in your mind, and these ideas can mislead you into making unsuitable decisions. Your job is to fully describe the business through a reasonable model and to obtain the approval of the client side. Any method of "thinking" for customers and architects, designers and even programmers is not appropriate.

Finally, this article provides an example of a use case specification, and each use case should write a use case specification. The example provided in this article basically comes from the template provided by the RUP, but in actual work the author makes some changes for the reader's reference. The blueprint for this example is also an example of an online library that has been used in this system article. Click here to download the case specification example, click here to download the modeling example.

Here, the demand process is almost over. But we do have some work to do. If the organization that the reader is working with is using RUP to do the demand, the client or the supervisor may not be satisfied with this requirement document. They will ask you in GB. At the same time, so far, we have produced a number of separate graphics and documents, for customers, this is indeed a bad document structure. Is it necessary to include rational Rose in the customer's purchase list so that you can read the requirements documents you provide? Obviously this is not possible, so the documentation provided to the user is still in the traditional "requirements specification" as well. The next article will discuss how to integrate our analysis costs into the requirements specification. Incidentally, we discuss the creation of the use case Supplemental specification and the system prototype as well as its role. Please look forward to it.