OO System analyst Path--use Case Analysis Series (2)--What is a use case

I found that today, almost Eminence Oo and UML, there are still a lot of system analysts who have a smattering of Oo and UML, and even many system analysts who have been using UML for a long time.

So I intend to write a series of articles, will be a summary of the work experience over the years. For beginners to play a role in the Enlightenment, but also hope to throw bricks, and all the way prawns together to explore and improve together.

This series of articles will be based on my understanding of OO and system analysis, starting with UML, elaborating the object-oriented requirements analysis method, process, and taking Rup as an example to illustrate how to combine OO processes with software processes to make a real OO application.

Well, today is the first one. Think very far, I do not know whether to go on, hehe: lol:

What are the use cases? The original English is usecase, literal translation came to become a use case. This is also a more appropriate term, the literal direct understanding is the use of examples. Another popular definition is that a use case is a collection of activities that interact with the user (actor) and provide the user with observable and meaningful results.

This definition is still more puzzling, the author found many candidates using use cases to do the requirements of the system analyst, some have been used for more than two years, but still can not grasp the nature of use cases, although they claim to be proficient in UML.

The most common misconception is that the use case is the division and description of the function, and that a use case is a function point. In this understanding, the use case becomes just a copy of the function block diagram in the earlier requirement, many people use use cases to divide the subsystem, function module and function point. If so, there is no need for use cases at all. Interestingly, a good part of this understanding error is due to the lack of understanding of Oo thinking, essentially, a system analyst who uses a use case as a function point has a process-oriented set of ideas, although they are using OO tools, oo language, known as object-oriented development, But the shadow of the process has not been completely erased from their minds.

If a use case is not a function, what is it? By definition, is it a function to provide a user with an activity that performs the result? My answer is: wrong! A feature is a computer term that is used to describe a computer, rather than a term that defines a requirement. The function actually describes the input--> to compute the--> output. What does that make you think? DFD picture? This is a typical process-oriented analysis model. So I say that the analyst who uses a use case as a function point is actually doing a process-oriented analysis.

While the use case is not a computer term, UML is often used in other industries in addition to its application in the computer industry. Use cases are a requirement methodology, although the software crisis and OO development contributed to its birth and was perfectly integrated into the OO system, forming UML, but it is not really a special product in the software industry. If you want to explain from a functional perspective, use cases can be interpreted as a series of "functional" combinations that accomplish a specific goal, and these "functions" reflect different combinations of scenarios for different applications. In fact, it may be more appropriate to interpret a use case as one of the participants (actor). Such a thing has the following characteristics:

One, this matter is relatively independent. This means that it does not need to interact with other use cases to complete the participant's purpose alone. In other words, the matter is complete from the "function". Readers may think that there is a correlation between use cases. such as extension, such as implementation, such as inheritance, it does not look independent. On this issue, the author will be in the follow-up article detailed description. Here's a little explanation, the relationship between use cases is the product of the analysis process, and this relationship is typically generated in the conceptual layer use case phase and the system layer use case phase. For business use cases, this feature is obvious.

The results of the implementation of this matter are observable and meaningful to the participants. For example, the system monitors the participants ' actions in the system and backs up the data before the participant deletes it. Although it is a necessary part of the system, it should not appear as a use case in the requirements phase. Because this is a background process and is not observable to the participants, it should be defined in the system use case analysis phase. For example, the login system is a valid use case, but the password is not. This is because the login system is meaningful to the participants, so that he can obtain identity authentication and authorization, but the password is not meaningful, entered the finished? What's the result?

Third, this matter must be initiated by a participant. There is no use case with no participants, the use case should not start automatically, and should not initiate another use case. A use case is always initiated by one participant and satisfies feature two. For example, taking money from ATM is an effective use case, but ATM bills are not. Because ATM is not for no reason to spit money, otherwise, I will be every day at the ATM side, life without worry.

Four, this matter must be in the form of verb-object phrase. That is, the thing must have a receptor for action and action. For example, drinking water is a useful use case, while "drink" and "water" are not. Although the common sense of life tells us that in the absence of water, we will not make a drink of this action, water must also be drunk, not slip in, but I see a lot of use cases like "calculation", "Statistics", "Report", "Output", "input" and so on.

In addition to the above features, the author thinks that the meaning of the use case is deeper. First, there is a requirement methodology behind the use case. Its core is to focus on the participants (different from the computer system), to describe the day-to-day work that he wants to do from a participant's point of view (different from the way the business process describes it), and to analyze how these routines interact (different from how the data flow is described). In other words, the primary goal of use case analysis is not to figure out how a business is done step-by-step, but to figure out how many participants there are. What does each participant do? Business process analysis is the follow-up work. Second, the use case is simply for OO, and its ideas are perfectly compliant with OO. The use case analysis approach attempts to identify all relatively independent participants and events in the problem area and treats the business process as the result of the interaction between these participants and events (described in UML with an activity or sequence diagram). Therefore, after the use-case approach is absorbed into Oo, UML can appear in a complete form, and the use case becomes the true Oo core. In Rup, this core role is played to the extreme, creating a software process approach to use case driven (usecase driven), in which all processes and artifacts of software production are built around the use cases.

It can be said that use case analysis is the first step of OO. If the use-case analysis itself is problematic, the impact on the business architecture, the software architecture, is significant and will greatly weaken the OO advantage-reuse, extension. The author thinks that software reuse can be divided into three levels, the lowest levels of reuse are code-level reuse, which is supported by OO language features such as inheritance, aggregation, polymorphism, and higher-level reuse as component-level reuse, supported by design patterns, such as Factory mode, builder mode The highest level of reuse is service level reuse, which is largely supported by application servers and communication protocols, such as the recently hot-fried SOA (service-oriented application) architecture. The good or bad of use case analysis may have little effect on the reuse of code-level and component-level, but the effect on service-level reuse is enormous. The author thinks that service level reuse is the highest state of Oo, and the good structure of use case analysis is the foundation of this realm.

Gossip:

Are you oo today?

If your analytical habits are the first to figure out how many business processes you need to investigate, first draw the business process flow chart, then track down, identify each step of the business processes involved in the department or post, figure out what the participants in this step and fill out the results of the form, and care about how the user to the form to the next link. So unfortunately, you're still doing the process-oriented thing.

If your analysis habit is to find out how many departments, how many positions, and then identify the business representatives for each job, ask them similar questions: What do you usually do? Who assigned this thing? Do you need to be notified or communicated to someone after you have done it? Do you need to fill out any form to do this matter? .... So congratulations, you have OO!