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

This article mainly introduces "what are the skills of UML modeling". In the daily operation, I believe that many people have doubts about the skills of UML modeling. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the questions of "what are the skills of UML modeling?" Next, please follow the editor to study!

Write use cases from the participant'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.

Use cases record only behavioral requirements.

Use cases 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.

In UML use case modeling techniques, 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.

Create 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 template (see tip "documenting use cases").

Organize use case diagrams consistently.

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.

In UML use case modeling techniques, use cases should describe both how actors 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 course of action is very important.

If all goes well, the basic action process will be used-but don't forget the alternative process. Alternative procedures are introduced 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 connection.

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.

Let the use case drive the user documentation.

The purpose of the user documentation 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.

Let the use case drive the demonstration.

In UML use case modeling techniques, part of the software development process is to inform the project fund manager of the results of the work, so it is sometimes necessary to provide demonstrations. 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.

At this point, the study of "what are the skills of UML modeling" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.