OO System analyst Path--use Case Analysis Series (4)--general steps and methods of business modeling

Before the start of this chapter, the commercial application system development has gone through three stages:

The first stage takes the computation as the center, the analysis design revolves the program The running efficiency, the algorithm merits, the storage optimization carries on. The 90 's university courses are all about that.

The second stage takes data as the center, analyzes the design around the data flow, and simulates the business process with the data flow. This is the so-called process-oriented analysis model.

The third stage is people-centered, analysis and design around the human business needs, use requirements, feel the requirements. This is also the present Image object Analysis mode.

Creating a business model using the OO method must first define the stakeholders. No matter how complex the business system is, no matter what industry it is, its essence is people, things, objects, rules. People are the center of everything, people do things, things are created, rules restrict people's things. The human drive system, the matter manifests the process, the matter records the result, the rule is the control. Oo or UML, complex surface is actually just a simple rule, the system analyst to figure out what people, what people do, what things produce, what rules in the middle, and then people, things, the relationship between the definition, business modeling is basically completed. At this point, the system analyst has fully understood the user requirements, you can enter the system modeling phase.

The author sums up some typical stakeholder types and their general expectations. The next step is to define their expectations. This process is the process of obtaining a business use case. The experience that I can share with you is through the following steps, which are not the only ones that are correct, and they are instructive for less experienced system analysts.

The author has done a modeling example, there is a need to have readers please to the author's blog Resource Center download, example above an online library requirements for the blueprint set up a business use case model, after the concept model, System model to extract the borrowing process as an example. Don't remember, you can look behind.

Modeling the first step, identify users from the stakeholders. and define the relationships between these users. In Rose, you should use the Business actor type. Refer to the requirements described in the previous article, download the example

The second step is to find out what each user is going to do, which is business use cases, and should use the Business usage case type in rose. Refer to the type and granularity of use cases to help determine the granularity of use cases. The author strongly recommends that for each business actor to draw a business use case diagram, which can be a good embodiment of the human-centric analysis mode, and it is not easy to miss business actor need to do. The concerns of participants in a business use case that are easily missed by a participant-centric view can be eliminated in step fourth. Download instance

The third step is to use the business scenario diagram to help analyze the business process, and in rose, this phase is best to use activity diagram activities diagram. At this stage, the business scenario diagram is very important, and during the drawing process, the system analyst must use the user name defined in the first step as the swim lane name, using the business use case name defined in the second step as the activity name. The reason why you have to do this is that if you can't fully describe the business process using the defined business actor and business use case, then there must be a problem with the previous definition, and you need to look back to see if business actor and business Use case definitions are imperfect or wrong. If not all business actor and business use cases are used, either you should check what is missing from the business process research, or you should check to see if you have defined some useless business actor and business uses cases. At the same time, drawing a business scenario diagram can also be very helpful in selecting the appropriate use case granularity and keeping all use cases to the same granularity. Download instance

Step fourth, draw the use case scenario diagram. Unlike a business scenario diagram, a use case scenario diagram paints only the execution of the use case for one use case. The author still strongly recommends the use of activity diagram. In drawing a use case scenario diagram, you must use the business user defined in the first step as the swim lane. The reason for this is that it helps you find errors in defining business use case diagrams, such as whether or not a potential user of a business use case is missing. Not every business use case needs to be plotted, and only two or three-step business use cases are not necessarily drawn to the business use case diagram, but still need to be documented in the business use case specification document. Download instance

Step fifth, from the activity diagram plotted in step three or fourth, find the results that each activity will use or produce. This is the process of finding things. When found, the relationship between these things should be established. In Rose, this is called the business entity model. You should use the business entity type. Download instance

The sixth step, in the above process, at any time to supplement the Glossary glossary. All of the business vocabulary, professional vocabulary, and so on in this process are used in the modeling process to explain the terminology required. This document will be an important guarantee for the model to build a consensus understanding of the model.

The seventh step, according to the owner, the boss and other stakeholders mentioned in the expectations of the establishment of a good model, determine the scope of business, decide which business use cases in the system building scope. There are two scenarios for business use cases that are not intended to be included in the building, one is that the business use case is invoked, then it should be changed to the boundary type, meaning that it will be an external interface in the future. The other is that the business use case proactively invokes the business use case within the system, then it should be changed to business actor type. Unlike ordinary business actor, business actor, which is converted from a business use case, is not a person, but is usually an external system process, so you should add a boundary element between the business use case and it in the called System. means that our system will provide an interface for such an external process. Strictly speaking, those business use cases that need to be included in the scope of construction should produce a business case realization, and later design work will be summed up in these implementation uses. But I think this step is not very critical, in fact, I often omit this step, but the collaboration diagram, like activity diagram, class interaction diagram directly under the business usecase under the instructions. However, in this example, the author is modeled according to the normal method. Download instance

It should be noted that the above steps are not complete at once, and may result in adjustments to the previous steps in each step. Even if modeling is complete, the above steps should be executed again from beginning to end when a change is encountered or a new problem is discovered. This is also the iterative development model advocated by RUP.

After the above steps, we have established a complete business model. But this is by no means the whole of modeling work, and the above process only illustrates the process of building a complete business model, which cannot be said to establish a good business model. Because the process does not refer to the business analysis process. The analysis process is based on the experience of the system analyst, the understanding of OO and the ability of grasping the industry business, summarizing, sorting, abstracting and reconstructing the original business model to build a more efficient, reasonable and scalable model. This process cannot be explained in steps. Perhaps later I will specifically for model analysis to write something. In addition to the model, there are at least three kinds of documents for business architecture documents, use case statutes and supplemental use case statutes. Because the model can better embody the business architecture, it is difficult to express business rules and non business requirements, which need to be described in the documentation. For example, the precondition and the post condition of a use case is a business rule. Readers can find templates for these documents in the RUP document.

Notice: The next article I will describe how to build a system conceptual model based on business model. First of all, the system conceptual model is based primarily on the business/use case scenarios and business entity models established by the third, fourth, and fifth steps. This also highlights the importance of scenarios and entity models.