Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "what are the skills of UML use case modeling". The editor shows you the operation process through actual cases, the operation method is simple and fast, and it is practical. I hope this article "what are the skills of UML use case modeling" can help you solve the problem.

UML use case Modeling skills

◆ writes use cases from an actor's point of view and in an active voice.

The use case should be written in the active voice: "the student indicates the intention to participate in the seminar" rather than the passive voice "the intention of the seminar is indicated by the student". Also, use cases should be written from the perspective of actors. After all, the purpose of the use case is to understand how the user operates the system.

Write the solution text, not the functional requirements.

Use cases describe a series of actions that are valuable to participants, not feature sets. For example, the enroll Seminar use case describes how students interact with the system to participate in the seminar. It does not describe what the user interface looks like or how it works. There are other models to describe this important information, such as user interface models and supplementary specifications. Object-oriented analysis is very complex, so several models need to be used for it, and each model should be applied appropriately.

The ◆ use case records only the behavioral requirements.

Use cases in UML use case modeling are neither class nor data specifications. This is a kind of information that should be captured by the conceptual model, which in the object world is modeled through the UML class model. You tend to refer to the classes described in the conceptual model. For example, the "attend a workshop" use case includes concepts such as "workshop" and "student", which will be described by the conceptual model.

◆, don't forget the user interface.

System use cases often refer to main user interface (UI) elements, which are often referred to as "boundaries" or "user interface" items, such as HTML pages and reports. Use cases sometimes refer to minor UI elements, such as buttons or data entry fields, but this level of detail is not common.

◆ creates a use case template.

Use cases contain a considerable amount of information that can be easily recorded in common formats. You should consider developing your own templates in UML use case modeling (see tips "documenting use cases").

◆ consistently organizes use case diagrams.

The general approach is to draw inheritance and extend associations vertically, drawing inheritance / extension use cases under the parent / base use case. Similarly, include associations are usually drawn horizontally. Note that these are simple rules of thumb-as long as you follow them all the time, the resulting diagram will be easy to understand.

◆ don't forget the response of the system to the actions of the participants.

Use cases should describe both how participants interact with the system and how the system responds to these interactions. For example, in the "join a workshop" use case, if the system does not respond when the student indicates that they want to attend the seminar, the student will leave frustrated.

The ◆ alternative action process is very important.

If all goes well, the basic action process will be used-but don't forget the alternative process. Alternative processes are introduced into UML use case modeling to describe potential usage errors as well as business logic errors and exceptions. This important information is necessary to drive the design of the system, so don't forget to model them in the use case.

Don't be bothered by the association with ◆.

I'm not sure what happened, but I'm always thinking about include and extend associations, and the correct use of (uses) and extends associations in older versions of UML has never been well described. As a result, use case modeling teams often argue about the correct application of these associations, wasting amazing time on interesting but minor parts of the entire modeling technology. I once worked in an organization that banned the use of and prototypes, and a few weeks later, when I realized that the company still needed these concepts, I had to withdraw this extreme solution. at this time, the organization has not yet reached a consensus on their correct use.

◆ lets use cases drive user documentation.

The purpose of user documentation in UML use case modeling is to describe how to use the system. Each use case describes a series of actions taken by participants by using the system. In short, the use case contains information from which to start writing a safe question for party users. For example, you can use the "attend a seminar" use case as a basis for writing the "how to attend a seminar" section of your system's user documentation.

◆ lets use cases drive the demonstration.

Part of the software development process is to inform project fund managers of the results of their work, so demonstrations are sometimes required. Because use cases are written from the user's point of view, they contain valuable insights into what money managers might want to hear in the presentation. In other words, use cases usually contain the logic needed to develop a presentation.

That's all for "what are the techniques for modeling UML use cases?" Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.