This part includes a review of the concepts used in UML to illustrate how these concepts are integrated in system modeling. This section does not detail each concept, and the detailed description can be found in the top part of this book.
Chapter 3 UML Entrepreneurs This chapter uses a simple example to initiate the concepts and views used in UML. The purpose of this chapter is to organize high-level UML concepts into a range of smaller views and charts to visualize these concepts, indicating how to describe a system with a variety of different concepts and how to organize various views together. The general statement is impossible, and many concepts are omitted. To get a more detailed description, see the next chapter to explain the details of the UML view and the details of this book. The example used in this chapter is the cinema ticketing system for computer management. This is a well-designed example, with a small amount to emphasize the various components of UML. This is an example of intentional simplification, ignoring the details. An integrity of an actual system cannot be introduced with such a small amount of space unless there is a large number of repetitive description. 3.1 There is no significant division boundaries between the various components and concepts in the UML view UML, but for convenience, we use views to divide these concepts and components. The view is just a subset of the UML modeling components that express the feature of the system. The division of the view has certain arbitrarily, but we hope this view is just intuitive. One or two-specific diagrams are used in each class view representing various concepts in the view. At the top level, the view is divided into three views: structural classification, dynamic behavior, and model management. Structure classification describes structural members and their relationships in the system. Cylinders include classes, use cases, components, and nodes. Types lay the foundation for research system dynamic behavior. The class element view includes a static view, an example view and an implementation view. Dynamic behavior describes the behavior of the system over time. The behavior is described with a change in the instantaneous value extracted from the static view. Dynamic behavioral views include state machine views, active views, and interactive views. Model management illustrates the layered tissue structure of the model. The package is the basic organizational unit of the model. Special packs also include models and subsystems. The model management view spans other views and organizes these views based on the system. UML also includes a variety of components with extended capabilities, which are limited but very useful. These components include constraints, constructors, and marking values, which are suitable for all view elements. Table 3-1 lists the views included in UML and views and the main concepts related to each diagram. This table cannot be regarded as a rule of a set of dead boards, which should be deemed to have guidance for UML routine use methods because UML allows a hybrid view. Table 3-1 UML view and Figure 3.2 Static view Static view The concept of the application field and the internal concepts related to the system implementation. The reason why this view is called static because it does not describe system behavior related to time, such behavior is described in other views. Static views are mainly composed of inter-class relationships, including: association, generalization, and various dependencies such as use and implementation. A class is a description of the concept of an application domain or application solution. Class diagrams are organized by class as centered, other elements in the class diagram or belong to a class or associated with the class. The static view is implemented with a class diagram, because it is centered on class, so it is called a class diagram. In the class diagram, the category is represented by the rectangle, and its attributes and operations are listed in the division. If you don't need to express more information, the tissue can be omitted. A class may appear in several figures. Attributes and operations of the same class are listed in one figure, and in other figures can be omitted. The connection between the relationship class box is represented, and different relationships are different from the modifiers at the connection and connecting ends. Figure 3-1 is a class diagram of the ticketing system, which is only part of the ticket system. A few important classes are shown, such as Customer, RESERVATION, Ticket, and Performance. Customers can book several times, but each booking can only be performed by a customer. There are two booking methods: personal ticket or package; the former is just a ticket, the latter includes more than one ticket. Every ticket is not a personal ticket is one of the tickets, but it is not a ticket in the package. There are more tickets for each show to be available, and each ticket corresponds to a unique seat number. Each performance name, date, and time are identified. 3.3 Using an example view is a model diagram of the system function that can be observed by an external user known as the participant.
The use case is a functional unit in the system that can be described as a interaction between the participant and the system. The use of an example model is to list the use cases and participants in the system, and which participant is displayed which use case is performed. Figure 3-2 is a diagram of an example of a ticket system. Participants include ticket sellers, supervisors and public telephone booths. The public telephone booth is another system that accepts the customer's booking request. In the application model of the ticket office, the customer is not a participant because the customer does not directly deal with the ticket office. Use examples include purchasing tickets through a public telephone booth or ticket employee, buy pre-ticket (only by ticket sellers), ticket supervision (should be required by the supervisor). Tickets and book tickets include a common part - pay for the credit card (for the full description of the ticketing system, etc., other use cases, such as ticket challenges, etc.). Use examples can also have different levels. Use examples can be described with other simpler use cases. In the interaction view, use the example as a collaboration in the interaction diagram. Figure 3-2 Example Figure 3.4 Interaction View Interaction View describes the order relationship between each role of the execution system function. The class is a description of an object that serves a particular role in the interaction between the system, which distinguishes it to other objects of the same class. The interaction view shows the system control flow across multiple objects. The interaction view can be represented by two diagrams: sequential diagrams and collaboration diagrams, which have different focuses. 3.4.1 Sequence diagram sequence diagram represents the time order of the transmitted message between the objects. Each type element role is represented by a lifeline - that is, the vertical line represents the life of the object in the entire interaction process. The arrow connection between the lifeline represents the message. The sequence diagram can be used to perform a scene description - the historical process of a transaction. One purpose of the sequence diagram is used to represent the order of behavior in the case. When an example of a routine is performed, each message in the sequence diagram corresponds to a trigger event that causes the conversion in a class operation or state machine. Figure 3-3 is a sequence diagram depicting this use case. Customers triggered this use case in the public telephone booth. The payment of the payment in the sequence diagram includes the two communication processes of the ticket office and the public telephone booth and the credit card service. This sequence diagram is used for the initial stage of system development, and is not included with the interface information between users. For example, how the seat is arranged; the detailed description of various seating is not yet determined. Despite this, the most basic communication in the interaction process has been expressed in the sequence diagram of this use case. Figure 3-3 Sequence Figure 3.4.2 Collaboration Figure 3 Multifiers to the chain buildings between objects and objects in one interaction. Objects and relationships are only meaningful in interaction. The class element role describes an object, and the associated role describes a chain in the collaborative relationship. Collaborative diagram uses geometric arrangements to represent each role in interaction (Figure 3-4). Arrows attached to the class dollar representative message. The order of the message is described in the number of messages at the message arrow. One purpose of the collaboration map is to represent a class operation. Collaboration drawings can explain the parameters and local variables used in class operations and permanent chains in operation. When a behavior is implemented, the message number corresponds to the nested call structure and signal transfer process in the program. Figure 3-4 is a collaboration diagram of the booking interaction in the development process. This figure shows the interaction between the various objects involved in the booking. The request is issued from the public telephone booth and requires the information from each performance. The pointer DB returns to the TicketSeller object represents a local temporary link to a certain performance information, which is held during interaction, and the interaction is ended. The ticket party has prepared a lot of performances; the customer has a choice of various prices, locks the selected seat, and the ticket selection returns the customer's choice to the public telephone booth. When the customer is selected in the seating table, the selection is declared, the remaining seats unlock. The sequence diagrams and collaboration maps can represent interactions between objects, but their side focus is different. The geometric arrangement of the sequence diagram is used to express the time order of the message, and the correlation between each role is implied. Collaborative diagram uses the geometric arrangement of each role to represent the relationship between the characters, and use the message to illustrate these relationships. These two diagrams can be selected as needed in practice. Figure 3-4 Collaboration Figure 3.5 Status Chart State Chart is a model diagram of all processes that may experience the class object. The state machine consists of various states of the object and the conversion of the connection these states.
Each state gives a time period modeling of a certain condition in its lifetime. When an event occurs, it triggers the transition between states, causing an object to be converted from one state to another. When executed with the conversion-related activity, the conversion also occurs at the same time. The state machine is expressed. Figure 3-5 is a state diagram of the object of the ticket. The initial state is the Available status. A portion of the ticket is reserved for the reservation before the ticket starts. When the customer is booked, the predetermined ticket is first locked. At this time, if the customer still wants to buy this ticket, this vote may be sold to the customer, may also be unlocked because customers do not do not unlock the status. . If you exceed the specified deadline, this ticket is automatically unlocked. The reservoir can also change the ticket for other performances. If so, the original appointment ticket can also be sold. The state diagram can be used to describe a subscriber interface, a device controller, and a subsystem having feedback. It can also be used to describe the behavior of passive objects across multiple different stages in the lifetime, all of which have their own special behavior at each stage. Figure 3-5 State Figure 3.6 Active view activity diagram is a variant of the state machine to describe the activities involved in the workflow of the algorithm. The active status represents an activity: a workflow step or an operation execution. The activity diagram describes a set of sequential or concurrent activities. The activity view is reflected in the activity map. Figure 3-6 is an active diagram of the ticket office. It expressed the activities to be done in a drama (this example is for reference only, and it is not necessary to complicate problems with the experience of the show). Arrows illustrate the order-dependent relationship between the activity - For example, before planning progress, you must first choose the show. The bold horizontal segment represents bifurcation and combined control. For example, after schedule the progress of the entire repertoire, you can publicize reports, buy the script, hire actors, prepare items, design lighting, processing costumes, etc., all of these activities can be carried out simultaneously. The scripts and actors must already have it before the rehearsal. This example illustrates the purpose of the activity map is modeling for workflows in the real world of human organizations. Modeling to things is the main purpose of the activity map, but the active map can also be modeled in the software system. The active diagram helps understand the execution behavior of the system's high-level activity, and does not involve the establishment of the messaging details necessary for the collaboration map. The input and output parameters required for the activity with the relationship stream of the connection activity and the target flow state are used. Figure 3-6 Active Figure 3.7 The view model described earlier in the physical view is modeled in the application field in accordance with logical perspectives. Physical views are modeled to the application itself, such as the component organization of the system and the configuration established on the running node. Such views provide mechanisms that map classes in the system into physical components and nodes. Physical view has two: implementation views and deployment views. Implementing a view as a system-building model-component, a software unit that constructs applications - also includes a dependency between components to estimate the impact on system components to the system. Implement the view as a component diagram. Figure 3-7 is a component diagram of the ticketing system. There are three user interfaces in the figure: the interface between the customer and the public telephone booth, the interface between the ticket sellers and the online booking system and the supervisor queries the ticket. The ticket component components accept requests from ticket sellers and public telephone booths; the credit card payment is handled between credit card main components; there is a database member of a storage ticket information. The component diagram represents various components in the system. In the actual physical configuration of individual systems, there may be multiple backups of a component. Figure 3-7 The small circle in the components represents the interface, that is, the serving of the service. The solid line from the components to the interface indicates the service provided by the component in the interface. The dotted arrow from the component to the interface illustrates the service provided by this component. For example, purchasing a personal ticket can also be purchased directly from the public telephone booth, but purchase group tickets can only pass the ticket seller. The deployment view describes the arrangement of the running component instance on the node instance. The node is a set of running resources such as computers, devices, or memory. This view allows evaluation of allocation results and resource allocation. Deploy views are expressed in deployment diagrams. Figure 3-8 is a description layer deployment diagram of the ticketing system. The figure shows the components and each node included in the system. The node is represented by a cube graphic.
