(Connection period) 4. Standard modeling language UML application field
The goal of UML is to describe any type of system with a wide range of systems with a wide range of applications. One of these most commonly used a model of a software system, but it can also be used to describe systems in non-software domains, such as mechanical systems, enterprise organizations, or business processes, and information systems that handle complex data, industrial systems or industries with real-time requirements. Process, etc. In short, UML is a general standard modeling language that models any system with static structures and dynamic behavior. In addition, UML is suitable for different phases of demand specifications to the system completion during system development. In the demand analysis phase, use cases can be used to capture user needs. The external role of the system and its functional requirements for the system (use case) are described by modeling. Analytical phases mainly care about the main concepts in the domain (such as abstraction, classes, and objects, etc.) and mechanisms, need to identify these classes and their relationships between them, and describe them with UML class. To implement use cases, collaboration between classes, which can be described by UML dynamic models. In the analysis phase, only models of the problem domain (the concept of the real world), regardless of the classes that define technical details in the software system (such as classes that handle user interfaces, databases, communications, and parallelism). These technical details will be introduced during the design phase, so the design phase provides a more detailed specification in the construction phase.
Programming (constructed) is a separate phase that converts classes from the design phase into actual code with object-oriented programming languages. When establishing an analysis and design model with UML, try to avoid converting the model into a certain specific programming language. Because in the early stage, the model is just a tool for understanding and analyzing the system structure, and it is very disadvantageous to establish a simple and correct model.
The UML model can also be used as a basis for the test phase. The system typically requires unit testing, integration testing, system testing and acceptance testing. Different test teams use different UML maps as test basis: unit test use class diagrams and class specifications; integrated test use parts graphs and cooperation diagrams; system test use case diagram to verify the behavior of the system; the acceptance test is performed by the user, Verify that the results of the system test meet the needs determined in the analysis phase.
In summary, the standard modeling language UML is suitable for describing any type of system with object-oriented technologies, and is applicable to different stages of system development, from demand specifications to test and maintenance after the system is completed.
Second, the standard modeling language UML static modeling mechanism
Any modeling language is based on a static modeling mechanism, and the standard modeling language UML is no exception. The static modeling mechanism of the UML includes the use case (Class Diagram), a Class Diagram, a Package, a component diagram, and a configuration diagram (DEPLOYMENT DIAGRAM).
Use example
(1) Use case model (use case model, in terms of object-oriented development and traditional software development, people understand demand based on typical use scenarios. However, these use scenarios are informal, although often used, it is difficult to establish a formal stationery. The use case model is first used by Ivar Jacobson in the development of the AXE system and joins the OOSE and Objectory methods he advocated. The use case method has caused great attention to the object-oriented field. Since the publication of Ivar Jacobson in 1994, the concept of use of the use case has been widely accepted in the object-oriented field, and it is considered to be the second generation of object-oriented symbols. The use case model describes the system function as understood by the External Executers. The use case model is used in the demand analysis phase, and its establishment is the result of system developer and user repeated discussion, indicating the consensus of developers and users to demand specifications. First, it describes the functional requirements of the system to be developed; secondly, it looks a system as a black box, understands the system from the perspective of external executors; third, it droves the development of various phases after demand analysis, not only development In the process, the implementation of all systems is guaranteed, and it is used to verify and detect the system developed, which affects the various stages of development and various models of UML. In UML, a use case model is described by several use case diagrams, with an example map main element is a use case and an executter.
(2) Use case, from essentially, one use case is a typical interaction between the user and the computer. Taking the word processing software as an example, "some of the aquent space is black" and "Creating an index" are two typical use cases. In UML, the use case is defined as a series of actions performed by the system, and the result of the action execution can be perceived by the specified executor.
Figure 1
In UML, the use case is expressed as an ellipse. Figure 1 shows an example of a financial trade system. Among them, "Risk Analysis", "Transaction Valuation", "Trading", "Set Boundary", "Transaction", "Evaluation Trade", "Update Account", etc. are all instances of the use case. In summary, the use of examples have the following features: • Use an example to capture some user visible needs and implement a specific user objective. • Use examples are activated by the executive, and provide exact values to the executive. • The use case can be large, but it must be a complete description of a specific user objective. (3) The actor (actor) actor refers to the role that the user played in the system. Its graphical representation is a small person. There are four executors in Figure 1: trade managers, marketers, salespersons and billing systems. There are many marketers in certain organizations, but they all play a same role in the system, and use an executor. A user can also play a variety of roles (performers). For example, a senior marketing personnel can be both a trade manager or an ordinary marketing personnel; a marketer can also be a salesman. When dealing with the executor, it should be considered, rather than a person or work name, this is important.
In Fig. 1, the line segment without an arrow will connect the executor and the use case to the exchange information, referred to as communication links. The executor triggers the use case and exchanges information with the use case. A single executor can contact multiple use cases; in turn, a use case can contact multiple executives. For the same case, different executives have different roles: they can take values from the examples or participate in the use case.
It should be noted that the executor is represented by the image in the case of the example, although executed, but the executor is not necessarily a person. For example, the executor can also be an external system that may need to obtain information from the current system and interact with the current system. In Figure 1, we can see that the billing system is an external system that requires an account.
Through practice, we found that the executivers are very useful for providing the use case. In the face of a large system, it is often very difficult to list the use case. At this time, you can list the executor's list, then list it for each executor, the problem will become easier.
(4) Use and Extend Fig. 1 In addition to the connection between the executor and the use case, there are additional two types of connections to represent the use and expansion relationship between the use case. Use and extensions are two different forms of inheritance relationships. When a use case is similar to another, it can be extended by more than one action. For example, in Figure 1, basic use cases are "transaction". Once all, everything is going well, but it may also have a factor that disturbed smooth transactions. One of them is to exceed certain boundary values. For example, the Trade Organization will regulate maximum trade for a particular customer, and the conventional actions provided by the given example cannot be performed, but to do some changes. We can make changes in "transaction" use cases. However, this will mix this use with a large pile of special judgment and logic, so that the normal process is embarrassed. In Fig. 1, the routine action is placed in the "transaction" use case, and the unconventional action is placed in the "transaction of the boundary", which is the essence of the extended relationship. When there is a large block of action exists in several cases, it can be used when the action is description, and it can be used. For example, reality risk analysis and transaction valuation requires evaluation trade, and can separately define a use case, ie "evaluation trade", and "risk analysis" and "transaction valuation" use cases will use it. Please pay attention to the similarities and different points between extensions and use. Both of them mean those common behaviors from several use cases and put them in a separate use, and this use case is used or expanded in several other use cases. But the purpose of use and expansion is different.
(5) The acquisition of the use case model is almost in any case. Use examples to access demand, planning, and control projects. The acquisition of the use case is one of the main tasks of the demand analysis phase, and it is the first thing to do. Most uses will be generated during the demand analysis phase of the project and discovers more use as the work is discovered, and these should be added to existing use cases in time. Each use case in the use case is a potential requirement.
a. Get the executor getting the use case first to find out the executor of the system. You can identify the executor by answering the answers to some questions. The following questions are available for reference: · Who uses the main function of the system (main user). · Who needs to support their daily work. · Who will maintain, manage the system normally (auxiliary users). • Systems need to manipulate which hardware. • The system needs to interact with which other systems, including other computer systems and other applications. · People or things interested in the results of the system. b. Once the use case obtains the executive, you can make a problem for each executor to obtain the use case. The following questions are available for reference: • What functions are required for the executor to provide the system? • What types of executives need to read, generate, delete, modify, or store. · What are the system events that must be reminded? Or what the executor must remind the system? How do these events represent the function in the use case? · In order to completely describe the use case, you need to know some of the executive some typical functions. Can you be automatically implemented by the system? There are some unimportant issues (ie, what is the problem of the entire system): · What kind of input output does the system do you come? Where is the output? · Current running system (perhaps Is there a major problem with some manual operations instead of a computer system? Need to note that the last two problems do not mean that there is no performer or useful examples, just getting the use case, I don't know what the executor is. A use case must be associated with at least one executor. It should also be noted that different designers have different degrees of utilization. For example, Ivar Jacobson said that he needs 20 use cases for a ten-year-old project. In an item of the same size, Martin Fowler uses more than 100 cases. We believe that any suitable use case can be used, and the process of determining the use case is the process of extracting and summarizing the acquired use case. For a ten-year-old project, twenty use cases seem to be too small, more than 100 cases It is too much to keep the relative balance between the two. (Endlessly)
