A preliminary overview of UML

Original: UML First glance

This chapter uses a simple example to take a first glance at the concepts and views used in UML. The purpose of this chapter is to organize high-level UML concepts into a series of smaller views and diagrams to visualize these concepts, explain how to describe a system in a variety of different concepts, and how to organize the various views together. The generality of the explanation cannot be exhaustive, and many concepts are omitted. For a more detailed explanation, see the next chapter for a description of the UML views and the details of this book's Daquan section.

The example used in this chapter is the computer-managed cinema ticketing system. This is a well-designed example, with the aim of emphasizing the various components of UML in a small amount of space. This is an example that has been deliberately simplified, ignoring the details. Unless there is a lot of repetition, a complete model of a real system is not likely to cover every component used in UML with so little space.

1.1 UML View

There is no obvious dividing line between the various components and concepts in UML, but for convenience, we use views to classify these concepts and components. A view is just a subset of a UML modeling component that expresses the characteristics of a system in one aspect. There is some randomness in the division of views, but we hope that this view is only intuitive. Use one or two specific diagrams in each class of views to visually represent the various concepts in the view.

At the top level, the view is divided into three view domains: Structural classification, dynamic behavior, and model Management.

Structure classification describes the structure members and their relationships in the system. A class element includes classes, use cases, artifacts, and nodes. The class element lays a foundation for studying dynamic behavior of the system. A class meta view includes a static view, a use case view, and an implementation view.

Dynamic behavior describes the behavior of the system over time. Behavior is described by the change in the instantaneous value extracted from the static view. Dynamic behavior views include state machine views, active views, and interactive views.

Model Management illustrates the hierarchical organizational structure of the model. A package is the basic organizational unit of a model. Special packages also include models and subsystems. The Model Management view spans other views and organizes these views according to system development and configuration.

UML also includes a variety of extensible components that are limited but useful. These components include constraints, stereotypes, and tagged values that apply to all view elements.

Table 3–1 lists the diagrams that UML views and views contain, and the key concepts associated with each type of diagram. This table cannot be viewed as a rigid set of rules and should be seen as a guide to the general use of UML, since UML allows the use of mixed views.

Table 3–1 UML views and diagrams

The primary domain	View	Figure	Key Concepts
Structure	Static view	Class diagram	Classes, associations, generalizations, dependencies, implementations, interfaces
	Use Case view	Use case diagram	Use cases, contributors, associations, extensions, include, use case generalization
	Implementation view	Component diagram	components, interfaces, dependencies, implementation
	Deployment View	Deployment diagram	node, component, dependency, location
Dynamic	State machine View	State machine Diagram	Status, events, transitions, actions,
	Active view	Activity Chart	State, activity, complete conversion, fork, combine
	Interactive view	Sequence diagram	Interactions, objects, messages, activation
		Collaboration diagram	Collaboration, interaction, collaboration roles, messaging
Model Management	Model Management view	Class diagram	Reports, subsystems, models
Scalability	All	All	Constraints, stereotypes, tagged values

2.1 Static View

Static views model The concepts in the application domain and the internal concepts related to system implementations. This view is called static because it does not describe the system behavior associated with time, and this behavior is described in other views. Static views are primarily composed of classes and inter-class relationships that include associations, generalizations, and various dependencies, such as the use and implementation of relationships. A class is a description of the concepts in the application domain or application solution. Class diagrams are organized in a class-centric context, with other elements in the class diagram either belonging to a class or associated with a class. A static view is implemented with a class diagram, which is called a class diagram because it is centered on a class.

In a class diagram, a class is represented by a rectangle, and its properties and operations are listed in a separate grid. If you do not need to express the details, the splitter can be omitted. A class may appear in several diagrams. The properties and operations of the same class are listed in only one diagram and can be omitted from other diagrams.

Relationships are represented by the lines between the class boxes, and the different relationships are distinguished by the modifiers on the line and the end of the connection.

Figure 3–1 is a class diagram of the ticketing system, which is only part of the ticketing system domain model. Several important classes are represented in the figure, such as customer, reservation, ticket, and performance. Customers can make multiple bookings, but each booking can only be performed by a single customer. There are two ways of booking: A personal ticket or a package, the former being a ticket and the latter including multiple tickets. Each ticket is not a personal ticket is one of the package, but not the individual ticket is one of the package. Each show has multiple tickets available for booking, and each ticket corresponds to a unique seat number. Each performance is identified by the name, date and time of the play.

Figure 3– 1 class diagram of the ticketing system

3.3 Use Case view

The use Case view is a model diagram of the system functionality that is known to external users as participants. A use case is a functional unit in a system that can be described as an interaction between the participant and the system. The use case model is used to list the use cases and participants in the system, and to show which participant participates in which use case is executed.

Figure 3–2 is a use case diagram of the ticketing system. Participants included conductors, supervisors and public telephone booths. A public telephone kiosk is another system that accepts customer requests for tickets. In the application model of the ticket office, the customer is not a participant because the customer does not deal directly with the ticket office. Use cases include purchase of tickets through a public telephone kiosk or conductor, purchase of reservation tickets (only through the conductor), ticket supervision (upon request of the supervisor). Ticketing and reservation tickets include a common part-that is, paying by credit card (a complete description of the ticketing system includes other use cases, such as ticket exchange and ticket inspection).

Use cases can also have different levels. Use cases can be illustrated with other, simpler use cases. In the interactive view, the use case is implemented as a collaboration in the interaction diagram.

3.4 Interactive views

The interactive view describes the sequential relationship between the various roles that perform system functions passing messages to each other. A class element is a description of an object that plays a particular role in the interaction within the system, which distinguishes it from other objects of the same kind. The interactive view shows a system control process that spans multiple objects. The interactive view can be represented by two diagrams: Sequence diagrams and collaboration diagrams, each with different emphases.

3.4.1 sequence Diagram

A sequence diagram represents the chronological order in which messages are routed between objects. Each of the class meta roles is represented by a lifeline-that is, a vertical line represents the lifetime of an object throughout the interactive process. The arrow lines between lifelines represent messages. A sequence diagram can be used to make a scene description-the historical process of a transaction.

One purpose of a sequence diagram is to represent the order of behavior in a use case. When performing a routine, each message in the sequence diagram corresponds to a class operation or trigger event that causes a transition in the state machine.

Figure 3–3 is a sequence diagram that describes the use case for buying tickets. The customer's call at a public phone box and ticket office triggered the execution of this use case. Payment in sequence diagram This use case includes two communication processes between the ticket office and the public telephone booth and credit card service. This sequence diagram is used in the early stages of system development and does not include complete interface information with the user. For example, how the seats are arranged, and the detailed descriptions of the various seats are not yet determined. However, the most basic communication in the interactive process has been expressed in the sequence diagram of this use case.

3.4.2 Collaboration Diagram

A collaboration diagram models the chain between objects and objects that make sense in a single interaction. Objects and relationships are meaningful only when they interact. A class meta role describes an object in which the associated role describes a chain in a collaborative relationship. The collaboration diagram uses geometric permutations to represent the roles in the interaction (3-4). The arrows attached to the class meta role represent the message. The order in which messages occur is indicated by the number at the message arrows.

One purpose of a collaboration diagram is to represent an implementation of a class operation. A collaboration diagram can describe the parameters and local variables used in the class operation and the permanent chain in the operation. When a behavior is implemented, the message number corresponds to the nested call structure and the signal passing process in the program.

Figure 3–4 is a collaborative diagram of the post-booking interaction in the development process. This diagram represents the interaction between the various objects involved in the booking. A request is made from a public telephone kiosk asking for information on a performance from all performances. The pointer that is returned to the Ticketseller object, DB, represents a partial temporary link to a performance profile that is persisted during the interaction and discarded at the end of the interaction. The ticket seller prepares a number of tickets for the show, and the customer makes a selection at various prices, locks the selected seat, and the conductor returns the customer's choice to the public telephone booth. When the customer makes a selection in the seating chart, the selected seat is declared and the remaining seats are unlocked.

Both sequence diagrams and collaboration diagrams can represent interactions between objects, but their focus is different. Sequence diagrams use the geometric arrangement of messages to express the chronological order of messages, and the correlation between roles is implicit. The collaboration diagram represents the relationships between roles using the geometry of each character, and describes them with messages. In practice, these two graphs can be selected as needed.

3.5 State Machine View

A state machine view is a model diagram of all the processes that a class object may experience. A state machine consists of the individual states of an object and the transitions that connect those states. Each State models a time period in which an object satisfies a condition in its lifetime. When an event occurs, it triggers a transition between states, causing the object to transition from one state to another. Transitions also occur at the same time as the transformation-related activity executes. State machines are expressed by state diagrams.

Fig.-3–5 is a state diagram of the ticket. The initial state is the available state. Some of the tickets are reserved for the reservation before the ticket starts to be sold. When a customer is booking a ticket, the booked ticket is first locked, and the customer still has the option to buy the ticket, so the ticket may be sold to the customer and may be unlocked because the customer does not want the ticket. If the customer has not made a selection beyond the specified period, the ticket will be unlocked automatically. The reservation can also be used for other performances, if so, the original reservation ticket can also be sold externally.

A state diagram can be used to describe user interfaces, device controllers, and other subsystems with feedback. It can also be used to describe the behavior of passive objects that span many different phases of life during a lifetime, in which the object has its own special behavior at each stage.

3.6 active View

An activity diagram is a variant of the state machine that describes the activities involved in the workflow that executes the algorithm. An activity state represents an activity: the execution of a workflow step or an action. An activity diagram describes a set of sequential or concurrent activities. The activity view is represented by an activity diagram.

Figure 3–6 is the activity Chart of the ticket office. It represents the activities to be performed on a play (this example is for reference only and does not have to be taken too seriously by the experience of the theatre to complicate the problem). Arrows describe the sequential dependencies between activities-for example, before planning the progress, first choose the repertoire of the show. The bold horizontal line segment represents fork and union control. For example, after arranging the entire repertoire, you can advertise, buy scripts, hire actors, prepare props, design lighting, and process costumes, all of which can be done at the same time. Before the rehearsal, the script and the actors must already have.

This example shows that the purpose of the activity diagram is to model the work flow in the real world of human organizations. Modeling things is the main use of activity diagrams, but activity diagrams can also model activities in software systems. Activity diagrams help you understand the execution behavior of high-level activities on the system, without involving the messaging details necessary to build a collaboration diagram.

Represents the input and output parameters required for an activity using a relational flow of connection activity and object flow state

3.7 Physical View

The view model described earlier models the concepts in the application domain in a logical perspective. The physical view models the implementation structure of the application itself, such as the component organization of the system and the configuration established on the running node. Such views provide a mechanism for mapping classes in a system into physical artifacts and nodes. There are two kinds of physical views: implementation view and Deployment view.

Implementing a view as a component model of a system-a component that constructs an application's software unit-also includes dependencies between the components to estimate the possible impact of modifications to the system artifacts to the system through these dependencies.

The implementation view is represented by a component diagram. Figure 3–7 is a component diagram of the ticketing system. The figure has three user interfaces: the interface between the customer and the public phone booth, the interface between the conductor and the online booking system, and the supervisor's interface to inquire about the ticketing situation. The Ticket party component order accepts requests from the conductor and the public telephone booth; The credit card Manager component handles credit card payments; There is also a database widget that stores the ticket information. The component diagram represents the various components in the system. In the actual physical configuration of individual systems, there may be multiple backups of a component.

The small circle in the diagram represents the interface, which is a coherent set of services. A solid line from a component to an interface indicates that the component provides services that are listed next to the interface. The dashed arrows from the component to the interface indicate that this component requires the service provided by the interface. For example, the purchase of individual tickets can be ordered through a public telephone kiosk or directly to the conductor, but the purchase of a group ticket can only be made by the conductor.

The deployment view describes the schedule of running artifact instances that are located on the node instance. A node is a set of running resources, such as a computer, device, or storage. This view allows you to evaluate allocation results and resource allocations.

Deployment views are expressed in a deployment diagram. Figure 3–8 is a description layer deployment diagram for the ticketing system. The diagram shows the components in the system and the artifacts that each node contains. The nodes are represented by a cubic graph.

Figure 3–9 is an instance-level deployment diagram of the ticketing system. The diagram shows the connections between the nodes and them. The information in this model corresponds to the content in the description layer of Figure 3–8.

3.8 Model Management views

Model Management view models the model's own organization. A series of packages consisting of model elements such as classes, state machines, and use cases make up the model. A package may contain other packages, so the entire model can actually be seen as a root package that indirectly contains everything in the model. A package is a basic unit for manipulating model content, access control, and configuration control. Each model element is contained in a package or contained within another model element.

A model is a complete description of a system from a point of view with a certain degree of precision. From a different perspective, multiple models may be established for the same system, such as a system analysis model and a system design model. A model is a special kind of package.

Subsystems are another special kind of package. It represents a part of the system that has a clear interface that can be implemented as a single component.

Model Management information is typically expressed in a class diagram.

Figure 3–10 shows the packages that have been decomposed throughout the theater system and the dependencies between them. The ticket office subsystem has been discussed in the previous example, and the complete system also includes the theatre management and planning subsystem. Each subsystem also contains multiple packages3.9 Extension Components

UML consists of three main extension components: constraints, stereotypes, and tagged values. A constraint is a textual description of a semantic relationship expressed in a formal language or natural language. Stereotypes are new model elements designed by modelers, but the design of this model element is based on UML-defined model elements. The tag value is a named block of information that is attached to any model element.

These components provide a way to extend the semantics of UML model elements without altering the semantics of the UML-defined meta-model itself. Use these extensions to build a customized version of the UML user for a specific application area.

Figure 3–11 illustrates the use of constraints, stereotypes, and tagged values. The constraints on the Repertoire guarantee that the repertoire has a unique name. Figure 3–11 illustrates two associated XOR constraints, an object that can only have one of two associations at a time. It is better to use text to express constraints, but the concept of UML does not directly support text description.

The Ticketddb component stereotype indicates that this is a database component that allows omitting the interface description of the component, because this interface is a common interface supported by all databases. Modelers can add new stereotypes to represent specialized model elements. A stereotype can have multiple constraints, tag values, or code-generation attributes. , a modeler can define an icon for a named stereotype as an accessibility tool for visualization. However, you can use the text form to describe it.

The tagged values in the scheduling package show that Frank Martin will complete the plan by the end of the year. Any information can be written as a tag value under the name of the modeler selected in a model element. Using text is useful for describing project management and code generation parameters. Most of the tag values are saved as pop-up information in the editing tool, and there are usually no tagged values in the officially printed chart.3.10 Relationships between the various views

Multiple views coexist in one model, with many relationships between their elements, some of which are listed in table 3-2. The table does not list all the relationships, but it lists some of the main relationships between elements that are observed from different perspectives.

Table 3-2 Partial relationships between different view elements

Elements	Elements	Relationship
Class	Have	State machine
Operation	Interaction	Realize
Case	Cooperation	Realize
Case	Interactive instances	Sample Scenario
Component Instances	Node instances	Position
Action	Operation	Call
Action	Signal	Send
Activities	Operation	Call
News	Action	Stimulate
Package	Class	Have
Role	Class	Classification

UML first glance (GO)