Title: No head, no tail - Project development note: How to write the outermost use case ?!
Key words: structural development, use case drive development
February 14: The street is everywhere, holding a flowers, is lively than the New Year! !
The project will enter the final implementation phase, and each subsystem has also started sweeping. Since many problems in the project are due to the reason, when discussing with members of the project team, sometimes it is still not consciously returned to the project, which has not been done, thus getting more from the project. experience of.
How to write the outermost use case
There are very many questions about UML on the market, about USE CASE, about RUP books. But there is no idea of how we already have structured ideas, or, when our brain has a global and overall design idea idea, to summarize USE CASE?
The outermost use case is the highest level of the master actor outside the use case. Simply put is the most abstract description of this system to complete what work. If the outermost use case is unclear, you can see "Write an effective use case" (Alistair Cockburn, Machinery Industry Press)
Briefly introduce our project. Since the background will have a large impact on the USE CASE design, this will be described here.
The goal of this system is to produce a cross-enterprise information platform to serve the target company's customers. These services are divided into many aspects, such as the company's financial situation to the bank, providing a report to the manufacturer's sales situation. Provide shopping malls and store goods, providing information to logistics, installation of service company delivery, and arrangement information. Earn the cost of improving sales efficiency and reducing transportation loss.
Set the target company for a company, information platform name B system.
The following is a description of the outermost use case for this system:
¨ Project The outermost use case of the initial description
------------------------------------
u use case name
Outermost use case
u brief description
Company A decided to allow its business partners and the ultimate users to access B systems through the Internet to achieve the purpose of reducing A company's local staff and enhanced work efficiency. The B system is responsible for completing the transfer service, other business processing, and report management. Some system maintenance personnel are also responsible for managing basic information identification and implementation. Including four use cases: base setting subsystem, incoming subsystem, other business processing subsystems, report subsystems.
U use case range
Cross-enterprise information platform
u master executor
client
U use case level
Baiyun (highest level)
u front condition
New business production
u Trigger event
Customer has the needs of purchase
U master success scene
l System maintenance personnel Operating Basics Settings the data of subsystem maintenance base settings.
l Operator operating the transfer of the invoicing subsystem to complete the transfer service.
l The operator analyzes the results of the business by reporting system.
l The operator completes other business processes in the system through other business subsystems. (Note, other business subsystems include subsystems such as financial funds, emphasizing the subsequent example description)
u expand
no
u unresolved problem
no
------------------------------------
Designing the outermost use case of this version, because there are some similar products in the company and Demo. So the first feeling in my mind is that we will have several menu items, such as basic settings, purchase management, sales management, inventory management, financial fund management, report printing subsystem, etc. After another abstraction, we define the outermost use example as described above.
This description should not be wrong, but when you go down your other sub-use cases and sub-sub-use cases, when you use this outermost use case, you will appear: 1. When you start from the foundation setting, We define some common object settings, such as product settings, price settings, warehouse settings, institutional settings, etc., but in each setting, it is not very clear in the specific definition in each setting. So when we correspond to the sub-use cases in the foundation setting, there is a feeling that these settings come from.
2. When communicating with customers, customers often don't care about what your setting is going to do, and they are most concerned about whether they can run business. So from the perspective of concern, this outermost design makes us deviation from the systematic concern when we communicate with our customers. (Example: We made Demo gave customers, customers did not make too many questions about our basic settings. But in the test version submitted to the customer, I found that some base objects are not designing, this time is the system to modify.)
........................
That is to say, our design may be in such a form by this outermost use:
Consider how many basic setting objects design - "Consider Business Processing -" and modify the design of the foundation setting object based on the characteristics of the business process
So, in general, the case where the outermost use case of this type is designed to be designed and developed from the design and development method of the design of the structured design (the person who designs this use case design must be a programmer or The previous dry process is designed. This design is from the developer's angle, not from the designer's perspective. (After writing this note, I communicated with a friend, and he told him that there was also this type of error before.)
¨ The second description of the premiere example description
------------------------------------
u use case name
Outermost use case
u brief description
Company A decided to allow its business partners and the ultimate users to access B systems through the Internet to reach the workload of A company's local staff and improve work efficiency. The B system is responsible for completing sales business and reporting sales. Some system maintenance staff must also set security access levels for customers and staff. Including four use cases: increasing service (local), increase service (customer), report business, and manages secure access rights.
U use case range
Cross-enterprise platform
U use case level
Baiyun (highest level)
u master executor
client
u front condition
Customer has the needs of purchase
U master success scene
l The customer contacts A operator by phone, email, requested a new service. A company operator processes service requests through the B system.
l The customer directly passes the client, requests and processes new services.
l The customer can query the sales situation and other relevant statements through B system.
The system maintenance personnel of L B will set the customer and the operator for secure access rights.
u expand
no
u unresolved problem
no
------------------------------------
This outermost design method should be said to be considered completely from the user's perspective, and some, this outermost layer does not completely include the latest menu we have implemented before system. (There is no foundation setting, etc.). But it should be said that this outermost use case is convenient for us to focus on the focus to users really need? The true considers from the user's perspective.
So for friends who have experienced and developing experiences, I think it is possible to do the following two points on the processing of the outermost use case:
1. Transform your angle, don't come up with you, you think you think must exist. Instead, it should be placed in the user's perspective 2. Learn to give up. Do not engage the outermost use case into a premium abstract form of a system final design version. Use this Dongdong and the final design are not necessarily exactly the same. (Sufficient service systems such as basic settings may not be displayed in the outermost use case.)
The above statement is just some of my feelings, maybe not necessarily correct. The outermost use case should be said that there are many ways to choose, perhaps, may have a lot of "correct" design methods for "correct" outermost use cases. The above two types of division should be said to be correct from the perspective of the outermost use case, but if the impact on the development of the subsequent process, my feeling is that it will be better than the first way. It can be said that it is clear. Friends If there are some other experiences, welcome to communicate with me. Mailto: viktoryu@hotmail.com
