OO system analyst path-case analysis series (1)-What is a case

I found that today, when Oo and UML are almost the same, many system analysts still have a thorough understanding of OO and UML, and even many system analysts who have been using UML for a long time.

So I plan to write a series of articles to summarize my work experience over the years. It is an enlightening function for beginners. I also hope to give a brick-and-mortar look and discuss it with prawns and improve it together.

This series of articles will focus on my understanding of OO and system analysis. Starting from the basics of UML, I will describe the object-oriented requirement analysis methods and processes. I will take the RUP as an example, this article describes how to combine the OO process with the software process to implement a real OO application.

Well, today is the first article. I wish I could stick to it.

What is a use case? The original English format is usecase, which is a case after literal translation. This is also a more appropriate name. A literal understanding is an example. Another popular definition is that use cases are a set of activities that interact with users and provide users with Observability and meaningful results.
This definition is still quite confusing. I have found that many system analysts who use cases for their needs have been using them for more than two years, but still cannot grasp the nature of the use cases, although they are known to be proficient in UML.

The most common misunderstanding mistake is that the use case is the division and description of functions, and that a use case is a functional point. With this understanding, the use case is just a new version of the functional block diagram that was previously required. Many people use cases to divide subsystems, functional modules, and functional points. In this case, there is no need to use cases. Interestingly, a considerable part of the cause of this misunderstanding is that the understanding of OO is not deep enough. In essence, system analysts who regard use cases as function points are still process-oriented. Although they are using OO tools and OO languages, they claim to be doing object-oriented development, however, the shadows of the process have not been completely erased from their minds.

What is a use case if it is not a function? In terms of definition, can a user be provided with an execution result activity? Isn't it a function? My answer is: yes! A function is a computer term used to describe computers, rather than defining requirements. The function actually describes input --> calculation --> output. What do you think? DFD diagram? This is a typical process-oriented analysis model. Therefore, the analysts who regard the use case as a function are actually conducting process-oriented analysis.
The use case is not a computer term. In addition to being used in the computer industry, UML is often used in other industries. The use case is a demand-side law. Although the software crisis and the Development of OO have contributed to its birth, it is perfectly integrated into the OO system, forming the UML, but it is not actually a specialized product in the software industry. If it is necessary to explain from the perspective of functions, use cases can be interpreted as a series of combinations of "functions" to accomplish a specific goal, for different application scenarios, these "functions" reflect different combinations. In fact, it may be more appropriate to interpret the use case as one of the participants. Such a thing has the following characteristics:
1. This is relatively independent. This means that it does not need to interact with other use cases to accomplish the goal of the participants alone. That is to say, this is complete in terms of "functions. Readers may think that there is also a correlation between use cases? For example, extension, such as implementation, such as inheritance, does not seem independent. I will elaborate on this issue in subsequent articles. The relationship between use cases is the product of the analysis process, and this relationship is generally generated in the concept-layer Use Case phase and system-layer Use Case phase. This feature is obvious for business use cases.
2. The execution results of this incident are Observability and meaningful to the participants. For example, The system monitors the operations performed by the participant in the system and backs up the data before the participant deletes the data. Although it is an essential part of the system, it should not be used as a case in the demand stage. Because this is a background process that is not observed by participants, it should be defined in the system case analysis phase. For example, logging on to the system is a valid use case, but the password is not entered. This is because logging on to the system makes sense to the participants, so that they can get identity authentication and authorization, but it does not make sense to enter the password. Is the input complete? Are there any results?
3. This event must be initiated by one participant. There are no use cases without participants. the use cases should not be started automatically or start another use case proactively. Use Cases are always initiated by one participant and meet feature 2. For example, taking money from an ATM is a valid use case, but ATM bills are not. Because ATM does not spit money for no reason, otherwise, I will stay at the ATM every day, and I will have no worries.
4. This must be in the form of a verb-object phrase. That is, it must have a receptor for action and action. For example, drinking water is an effective use case, but "drinking" and "water" are not. Although our common sense of life tells us that when there is no water, people will not drink this action, and water will inevitably be drunk, rather than slide in, however, there are not a few examples I have seen, such as "computing", "Statistics", "Report", "output", and "input.

Apart from the above features, I think the use case has a deeper meaning. First, there is a demand methodology behind the use case. Its core is to focus on participants (different from computer systems) and describe their daily work (different from the business process description) from the perspective of participants ), analyze how these daily tasks interact (different from the description of data streams ). In other words, the primary goal of case analysis is not to figure out how a business is completed step by step, but how many participants are involved? What does each participant do? Business Process Analysis is a follow-up task. Secondly, the use case is born for Oo, and its idea perfectly conforms to oo. The case analysis method tries to find all relatively independent participants and events in the problem field, and regard the business flow as the interaction result between these participants and events (the UML uses the activity diagram or sequence diagram to describe ). Therefore, after the use case method is absorbed into Oo, UML can appear in a complete form, and the use case becomes the true oo core. In the RUP, this core role has been used to the extreme, resulting in the Use Case Driven software process method. In the RUP, all processes and products of software production are built around use cases.

It can be said that case analysis is the first step of OO. If the case analysis itself has a problem and has a great impact on the business architecture and software architecture, it will greatly weaken the advantages of OO-reuse and expansion. The author believes that software reuse can be divided into three levels. The lowest level of reuse is code-Level Reuse, which is supported by OO language features, such as inheritance, aggregation, and polymorphism; the higher level of reuse is component-Level Reuse, which is supported by the design mode, such as the factory mode and builder mode. The highest level of reuse is service-level reuse, this is largely supported by application servers and communication protocols, such as the recently popular SOA (Service-Oriented Application) architecture. The quality of case analysis may have little impact on code-level and component-Level Reuse, but it has a huge impact on service-level reuse. I believe that service-level Reuse is the highest level of OO, while well-structured case analysis is the basis for achieving this level.

Gossip:
Are you Oo today?
If your analysis habits are to first figure out how many business processes you need when investigating your needs, first draw a business flow chart, and then find out the department or position involved in each step of the business process, find out what the participants have done and the result of entering the form in this step, and care about how the user passes the form to the next step. Unfortunately, you are still doing process-oriented things.

If your analysis habits are to first find out how many departments and positions are involved in the survey, then find the business representatives of each position and ask them a similar question: What do you usually do? Who handed in the incident? Who do you need to notify or convey after finishing the process? What forms do you need to fill in to do this ?.... Congratulations! You are already oo!