UML reference manual
Part II Based Overview
Chapter 5 Taking Examples 5.1 Overview When an example view appears before the external user occurs, it captures the behavior of the system, subsystem, or class. It divides system functions into demand useful to participants (ie, ideal users). The interactive function is called an example. Use an example using a series of messages between one or more participants to describe interactions in the system. Participants can be people, or external computer systems and external processes. Figure 5-1 shows an example of an example of a telephone directory sales. This example is an example of simplified actual system. Figure 5-1 Example Figure 5.2 Participant Participants are an idealization concept of external users, processes, or other systems that interact with the system, subsystem or class. As an external user interaction with the system, this is the characteristics of the participant. In the actual operation of the system, an actual user may correspond to multiple participants of the system. Different users can also only correspond to one participant, thereby representing different instances of the same participant. Each participant can participate in one or more use cases. It interacts through exchange information and the use case (therefore also interacting with the system or class in which the use case is located), and the internal implementation and use case of the participant is not related, the participant can be defined in the attribute of its state A description of it. Participants can be defined by generic relationships, in which a participant's abstract description can be shared by one or more specific participants. Participants can be people, another computer system or some runoffed processes. In the figure, the participant is represented by a name written in the following. 5.3 Use case use cases are an external visible system function unit that is provided by the system unit and is expressed by a message exchanged between one or more participants. The use of the use case is to define a coherent behavior without revealing the internal structure of the system. The definition of the use case includes all behaviors necessary for the case - the main order of the execution case function, the different modifications of the standard behavior, and all anomalies under general behavior and its expected reactions. From the user's point of view, the above situation is likely to be an abnormal condition; from a system perspective, they are additional situations that must be described and processed. In the model, each use case is performed independently of other use cases, although there may be such or such implicit dependencies between this use case and other use cases due to the shared object between the use of examples when performing an example function. . Each usage is a longitudinal function block that is mixed with the execution of this function block and other use cases. The dynamic execution of the use case can be described using the interaction of the UML, which can be represented by a state diagram, sequence diagram, a cooperation, or an informal text description. The implementation of the implementation of the example function is achieved by collaboration between classes. A class can participate in multiple collaboration and therefore also participated in multiple use cases. In the system layer, the use case represents the behavior visible to external users throughout the system. A use case is like system operations that can be used outside users. However, it is different from the operation, and the use case can continuously accept the input information of the participant during the execution process. Use examples can also be applied to small units such as subsystems and independent classes. An internal use example represents a part of the system to present the behavior of another part. For example, an example of a class represents a coherent function, which is a class that provides other special effects in the system. A class can have multiple use cases. The use case is a logical description of a part of the system part, it is not a significant component for system implementation. So, each use case must be mapped with a class that implements the system. The behavior of the use case corresponds to the status conversion of the class and the operation defined by the class. As long as a class acts as a multi-role in the implementation of the system, it will implement a part of multiple use cases. A part of the design process is to find a class with obvious multiple roles without introducing confusion, to achieve the use case function involved in these roles. Implementation with the collaboration between the examples. Examples can participate in multiple relationships in the system (Table 5-1) in addition to their participants. Table 5-1 The relationship between the use cases is shown in Figure 5-2, and the use case is indicated by an ellipse inside, with a solid line connection between the participants communicated with it. Figure 5-2 relationship between the use cases Although the example of each use is independent, an exemplary can be described in other simpler use. This is a bit like a class can be defined by inheriting its superclass and adding additional description.
