Chapter 4 static view 4.1 Overview
Static views are the basis of UML. The elements of static views in a model are meaningful concepts in applications. These concepts include concepts in the real world, abstract concepts, implementation concepts, and concepts in the computer field, that is, various concepts in the system. For example, a theater ticketing system has various concepts, such as tickets, reservations, reservation plans, seat distribution rules, online booking and redundant information.
The static view describes the object structure. An Object-Oriented System unifies data structures and behavior features into an independent object structure. Static views include all traditional data structure ideas and data operation organization. Data and operations can be quantified as classes. Data and behavior are closely related to objects. For example, a ticket object can carry data, such as price, performance date, and seat number. This object can also be operated based on it, for example, reserve this ticket or calculate its price at a certain discount.
Static views describe behavior entities as discrete model elements, but do not include the details of their dynamic behavior. The static view regards these behavior entities as objects that are specified, owned, and used by the class. The dynamic behavior of these entities is described by other views describing their internal behavior details, including the interactive view and the state machine view. A Dynamic Graph requires a static view to describe the objects of Dynamic Interaction-if you do not first understand what interaction is, you cannot clearly explain how the interaction works. Static views are the basis for creating other views.
The key elements in the static view are the class elements and their relationships. A class element is a modeling element that describes a thing. There are several types of metadata, including classes, interfaces, and data types. Other elements, including use cases and signals, are specific to behavior. The implementation goal is after the categories of subsystems, components, and nodes.
To facilitate understanding and reusability of models, a large model must consist of smaller units. A package is a general organizational unit that owns and manages model content. Any element can be owned by the package. A model is a package used to describe the complete system view, and is more or less independent of other models when used-this is the basis for mastering more detailed packages that describe the system.
An object is a discrete unit separated from a system that the modeler understands and constructs. It is an instance of the class-the object is an identifiable state, and the behavior of this state can be stimulated. It is an identity entity whose structure and behavior are described by the class.
The relationships between class elements are correlated, generalized, and different dependencies, including implementation and usage relationships.
RMB 4.2 million
A class element is a discrete concept in a model. It has identities, States, behaviors, and relationships. There are several types of metadata, including classes, interfaces, and data types. Other types of elements are the embodiment of behavior concepts, Environmental things, and execution structures. These elements include use cases, participants, components, nodes, and subsystems. Table 4-1 lists several types of elements and their functions. Meta-Model glossary includes all these concepts. Because classes are the most familiar terms, we should first discuss them and then define other concepts based on the differences between classes and other concepts. Table 4-1 elements of various types
1. Class
Class represents the discrete concept in the modeling application field-physical entities (such as aircraft), commercial things (such as orders), logical things (such as broadcast plans) applications (such as canceling keys), computer-related (such as hash tables), or behavior (such as a task ). A class is a descriptive symbol of a group of objects with the same structure, behavior, and relationship. The attributes and Operations used are attached to the class or other class elements. Class is the core of the organizational structure of object-oriented systems.
An object is a discrete entity with an identity, status, and stimulating behavior. Objects are used to construct individuals in the actual operating system, and classes are used to understand and describe individual concepts of many individual objects.
Class defines a group of objects with States and behaviors. Attributes and associations are used to describe the status. Attributes are usually expressed by pure data values without identities, such as numbers and strings. Association is represented by the relationship between objects with identities. Individual behaviors are described by operations. The object life cycle is described by the state machine attached to the class. The class representation is a rectangle consisting of a cell box with class names, attributes, and operations. 4-1.
Figure 4-1 class Representation
A group of classes can share common states and behavior descriptions with generalized relationships and inheritance mechanisms established in them. Generalization associates more specific classes (subclasses) with more common classes (superclasses) that contain the same features of several subclasses. A class can have zero or multiple parent classes (superclasses) and zero or multiple descendants (Child classes ). A class inherits the state and behavior description from its parent and ancestor, and defines the State and behavior description inherited by its descendant.
A class has a unique name in its owner. This owner may be a package but sometimes another class. The class is visible to its owner. The visibility shows how it is used by classes outside its visible users. The multiple classes indicate how many instances can exist. Generally, there can be multiple instances (zero or multiple instances with no explicit restrictions ), however, during execution, an instance only belongs to one class.
2. Interface
An interface describes the behavior of an object without the implementation and status of the object. The Interface contains operations but does not contain attributes, and it has no associations that are visible to the outside world. One or more classes or components can implement an interface, and each class can implement operations in the interface.
3. Data Type
The data type is used to describe simple data values with missing identities. Data types include numbers, strings, and enumerated values. Data types are passed through values and are immutable entities. Data Types have no attributes, but can be operated. The operation does not change the data value, but the data value can be returned as a result.
4. Layered meaning
Classes can exist in the meaning layers of the model, including the analysis layer, design layer, and implementation layer. It is important to describe the actual state, relationship, and behavior when expressing the concept of the real world. However, concepts such as Information Hiding, effectiveness, visibility, and methods are irrelevant to concepts of the real world (they are concepts at the design Layer ). The class at the analysis layer represents the logical concept or application in the application domain. The analysis layer model should represent the modeling system as little as possible, and fully describe the necessary logical components of the system without involving execution and construction.
Some concepts are directly related to classes when they represent high-level designs, these concepts include State locating of specific classes, efficiency of navigation between objects, separation of external behaviors and internal implementations, and accurate operation descriptions. The design layer class encapsulates State information and its operations in a discrete unit. It illustrates key design decisions, information locating, and object functions. The design layer class includes the real world and computer systems.
Finally, when implementing program code, the form of the class is closely related to the selected language. If the functions of a common class cannot be implemented directly in languages, you have to give up on them. The Implementation Layer class directly corresponds to the program code.
The same system can accommodate multiple levels of classes. implementation-oriented classes implement more logical classes in the model. An Implementation class declares a class using a specific programming language. It obtains a class in an accurate format as required by the language. However, in many cases, analysis, design, and implementation information can be nested in a separate class.
4.3 relationship
The relationships between class elements include associations, generalization, streams, and various forms of dependencies, including implementation relationships and usage relationships (see Table 4-2 ).
The Association describes the semantic connections between individual objects of a given class. Associations provide connections between objects of different classes that can interact with each other. The rest of the relationships involve descriptions of the class meta itself, rather than their instances.
The generalized relationship connects the parent class Meta (superclass) with a more specific descendant class Meta (subclass. Generalization is conducive to the description of the class element. Redundant declarations are not required. Each declaration must contain a description inherited from its parent class. The Inheritance mechanism constructs a complete class meta description using the additional description of the generalization relationship. Generalization and inheritance allow different class meta-shared attributes, operations, and their relationships, without repeated descriptions.
The implementation relationship is explained and linked with the implementation. Interfaces are descriptions of behaviors rather than implementations, while classes contain the structure of implementations. One or more classes can implement one interface, and each class implements operations in the interface separately.
Stream links two versions of an object in a continuous manner. It indicates the conversion of the value, status, and position of an object. The stream relationship can connect the class meta-roles in one interaction. Stream types include changing to (different versions of the same object) and copying (creating a new object from an existing object.
Dependencies associate behavior and implementation with classes that affect other classes. In addition to implementation relationships, there are also several dependency relationships, including trace relationships (a loose connection between elements in different models) and refined relationships (A ing between two different levels of meaning), use relationship (another element is required in the model), binding relationship (specify a value for the template parameter ). Dependencies are often used to represent the relationship between specific implementations, such as the implementation relationship at the code layer. Dependency is useful when summarizing the organizational unit of a model, such as a package. It shows the architecture of the system. For example, compile constraints can be expressed by dependencies. Table 4-2 link types
4.4 Association
Association describes the discrete connections between objects or instances in the system. An association is a class element that contains two or more ordered tables and is connected when replication is allowed. The most common Association is a binary association between class elements. One of the associated instances is the chain. Each chain consists of a group of objects (an ordered list), and each object comes from the corresponding class. A binary chain contains a pair of objects.
Associate Information with the relationship between objects in the system. During system execution, the connections between objects are established and destroyed. Association is the "adhesive" used in the entire system. Without it, there are only isolated classes that cannot work together.
If the same class appears more than once in association, a single object can be associated with itself. If the same class appears twice in an association, the two instances do not have to be the same object. This is usually the case.
Any connection point associated with a class is called the Association end, and many information related to the class is attached to its endpoint. The Correlated end has features such as name (role name) and visibility, while the most important feature is the diversity. Duplication is very important for Binary associations because it is complicated to define N-yuan associations.
Binary join is represented by a line connecting two classes. As shown in Figure 4-2, there is an associated role name on the link, and the multiple roles are added to each endpoint.
Figure 4-2 Association notation
If an association is both a class and an association class, that is, it can have its own attributes (4-3 ). If an associated attribute is unique in a group of related objects, it is a qualifier (4-4 ). A qualifier is used to identify unique object values from a group of related objects in an association. The qualifier is very important for modeling names and identity code. It is also an index for designing models.
Figure 4-3 Association class
Figure 4-4 limit Association
In the analysis phase, Association indicates the logical relationship between objects. There is no need to specify directions or care about how to implement them. Avoid unnecessary associations as much as possible because they do not add any logical information. In the design phase, Association is used to describe the design decision on the data structure and the separation of duties between classes. At this time, the direction of association is very important. In order to improve the object access efficiency and locate specific class information, some necessary redundant associations can also be introduced. However, in this modeling phase, the association should not be equal to the pointer in the C ++ language. Navigative associations in the design phase represent State information useful to a class, and they can be mapped to programming languages in multiple ways. Association can be implemented using a pointer, nested class, or even a completely independent table object. Other design attributes include visibility and chain modifyability. Figure 4-5 shows some associated design features.
Figure 4-5 associated Design Features
1. Aggregation and composition
Clustering indicates the correlation between the part and the overall relationship. It is represented by a line segment with an empty diamond at the endpoint, And the empty diamond is connected to the clustering class. Composition is a stronger form of association, with the unique responsibilities of the overall management part. It is represented by an solid diamond object attached to the composition end. Each class that represents a part has a separate association with the class that represents the whole, but for convenience, the connections are combined, and the entire group is now associated with a tree. Figure 4-6 shows the clustering Association and composition Association.
Figure 4-6 aggregation and composition
2. Chain
A link is an associated instance. A chain is an ordered table of the objects involved. Each object must be an instance of the corresponding class in the association or an instance of such descendants. Links in the system constitute part of the system status. Links do not exist independently of objects. They get their own identities from the objects associated with them (in database terms, the object list is the key of the chain ). In terms of concept, associations are significantly different from related classes. In practice, Guan Unicom often uses pointers to related classes, but they can be implemented as the inclusion object separated by the connected classes.
3. Bidirectional
The associated different ends are easily identified, even if they are of the same type. This only means that different objects in the same class can be associated with each other. Because the two ends are differentiated, the Association is asymmetric (except for some examples), and the two endpoints cannot exchange with each other. In general, this is a consensus: just as the subject and object in a verb phrase cannot be exchanged. Associations are sometimes considered bidirectional, which means logical relationships work in both directions. This point of view is often misunderstood, and even involves some methodologists. This does not mean that each class "understands" other classes, or that classes and classes can access each other in the implementation. This only means that any logical relationship has its inverse nature, regardless of the reverse nature, it is not easy to calculate. If the association only crosses one direction but not the other, the Association is considered to be navigation.
Why do we use basic models instead of commonly used pointers in programming languages to represent associations? The reason is that the model tries to explain the purpose of the system. If the relationship between the two classes is represented by a pair of pointers in the model, the two pointers are still related. The association method indicates that the relationship is meaningful in both directions, regardless of how they are implemented. It is easy to convert the association into a pair of pointers for implementation, but it is hard to show that the two pointers are inverse to each other unless they are part of the model.
4.5 Generalization
The generalized relationship is the relationship between the general description of the class element and the specific description. The specific description is based on the general description and is extended. The specific description is exactly the same as the general description. All features, members, and relationships include supplemental information. For example, a mortgage is a specific type of lending. A mortgage maintains the basic features of lending and adds additional features, such as a house that can be used as a collateral for lending. The description is generally called "parent". The specific description is called "sub-loan", "sub-loan", and "mortgage. Generalization is used in class elements (classes, interfaces, data types, use cases, participants, signals, etc.), packages, state machines, and other elements. In a class, the term superclass and subclasses represent the parent and child.
Generally, it is represented by an arrow pointing from the child to the parent, and an empty triangle pointing to the parent (4-7 ). Multiple general relationships can be represented by a tree composed of arrows. Each branch points to a subclass.
Figure 4-7 generalized Representation
General Purpose
Generalization has two purposes. The first purpose is to define the following conditions: When a variable (such as a parameter or a procedure variable) is declared to carry the value of a given class, the class (or other element) can be used) this is called the alternative principle (proposed by Barbara liskov ). This principle indicates that an instance of the descendant can be used no matter when the ancestor is declared. For example, if a variable is declared to have a loan, a mortgage object is a valid value.
Generalization makes it possible for multi-state operations, that is, the implementation of operations is determined by the classes of the objects they use, rather than by the caller. This is because a parent class can have many sub-classes, and each sub-class can implement different variants defined in the same operation in the class overall set. For example, the calculation of interest on mortgages and car loans is different, and each of them is the calculation of interest deformation in parent loans. A variable is declared to have a parent class, and an object of any subclass can be used, and any of them has its own unique operations. This is especially useful because you can add a new class without changing the existing polymorphism call. For example, a new type of lending can be newly added, and the existing code used to calculate the interest operation is still available. A multi-state operation can be declared in the parent class without implementation. Its Child classes need to supplement the implementation of this operation. This incomplete operation is abstract (its name is in italic ).
Another purpose of generalization is to allow the parent to define the added description while sharing the components defined by the ancestor. This is called inheritance. Inheritance is a mechanism by which object descriptions of a class are aggregated from the declared part of the class and its ancestor. The shared part that inherits the description is declared only once and can be shared by many classes, instead of repeatedly declaring and using it in each class. This sharing mechanism reduces the scale of the model. More importantly, it reduces the changes that must be made to update the model and the unexpected pre-and post-definition inconsistency. Inheritance works in a similar way for other components, such as States, signals, and use cases.
4.5 inheritance
Each generalized element has a set of inheritance features. Includes constraints on any model element. For Class elements, they also include some features (such as attributes, operations, and signal reception) and associated participants. A subclass inherits the inherited features of all its ancestors. Its complete features include inherited features and directly declared features.
For the class element, attributes without the same feature mark will be declared multiple times, whether directly or inherited, otherwise a conflict will occur and the model form is incorrect. In other words, attributes declared by the ancestor cannot be declared again by future generations. If the class interfaces are consistent (with the same parameters, constraints, and meanings), the operation can be declared in multiple classes. The attached statement is redundant. A method can be declared by multiple classes in the hierarchy, and the method attached to the descendant replaces (reloads) the method with the same feature Mark declared in any ancestor. If two or more copies of a method are inherited by a Class (through multiple inheritance of different classes ), then they are conflicted and the model format is incorrect (some programming languages allow you to explicitly select one of them. We found that it would be simpler and safer to redefine methods in future classes ). The constraint in an element is the combination of the element itself and the constraint of all its ancestors. If they are inconsistent, the model format is incorrect.
In a specific class, each inherited or declared operation must have a defined method, either directly defined or inherited from the ancestor.
4.5.2 multi-Inheritance
If a class element has multiple parent classes, it can obtain Inheritance Information (4-8) from each parent class ). Its features (attributes, operations, and signals) are the union of all its parent features. If the same class appears on multiple paths as the parent class, each member of the class has only one copy of it. If the features with the same characteristics are declared by two classes, and these two classes are not inherited from the same ancestor (I .e. independent declaration), the declaration will conflict and the model form is incorrect. Because experience tells our designers to solve this problem on their own, UML does not provide a conflict solution in this case. Languages like Eifel allow explicit resolution of conflicts by program designers, Which is safer than implicit conflict resolution principles, which often surprise developers.
Figure 4-8 multi-Inheritance
4.5.3 single and multi-category
In the simplest form, an object belongs to only one class. Many object-oriented languages have this restriction. There is no logical necessity for an object to belong to only one class. We only need to observe objects in the real world from multiple perspectives. In a more general form of UML, an object can have one or more classes. The object looks like it belongs to an implicit class, and this class is a subclass of each direct parent class-multiple inheritance can avoid declaring a new class, which improves efficiency.
4.5.4 static and dynamic class Elements
In the simplest form, an object cannot change its class after it is created. We once again demonstrate that this restriction is not logically necessary, but is initially designed to make the implementation of object-oriented programming languages easier. In a more general form, an object can dynamically change its class, so that it will get or lose some attributes or associations. If Objects lose them, the information in them will be lost and cannot be restored later, even if the object is changed back to the original class. If this object has properties or associations, they must be initialized when they are changed, just like initializing a new object.
When multiclass classification and dynamic classification are used together, an object can get or lose a class during its life cycle. Dynamic classes are sometimes called roles or types. A common modeling mode is that each object has a unique static inherent class (that is, the class that cannot be changed during the object's life cycle ), add zero or more corner classes that can be added or removed during the life cycle of the object. The inherent class describes the basic features of this object, while the role class describes the temporary features. Although many programming languages do not support multiple dynamic classifications in class declarations, it is still a useful modeling concept and can be mapped to associations.
4.6 Implementation
An Implementation relationship connects a model element (such as a class) with another model element (such as an interface). An interface is only a description of behavior rather than a structure or implementation. The customer must support at least all operations of the provider (either inherited or directly declared ). Although the implementation relationship means that there must be a descriptive element like an interface, it can also use a specific implementation element to imply that its description (rather than its implementation) must be supported. For example, this can be used to represent the relationship between an optimization form of a class and a simple and inefficient form.
The general description can be associated with the specific description. Generalization links elements on the same semantic layer (for example, on the same abstract layer), and is usually within the same model. Implementation relationships are connected to elements in different semantic layers (for example, an analysis class and a design class; an interface and a class), and are usually established in different models. There may be two or more class levels at different stages of development. The elements of these class levels are linked by implementation relationships. The two levels do not need to have the same form, because the implemented classes may have implementation dependencies, which are irrelevant to specific classes.
The implementation relationship is expressed by a dotted line with closed empty arrows (4-9), which is similar to the generalized symbol.
A special folding symbol is used to represent the interface (without content) and the class or component that implements the interface. The interface is represented by a circle, which is attached to the rectangle (4-10) that represents the class Element Through solid lines ).
Figure 4-9 Implementation relationship
Figure 4-10 interface and implementation icon
4.7 dependency
Dependency indicates the semantic relationship between two or more model elements. It only connects the model elements themselves and does not need a group of instances to express their meaning. It indicates a situation where changes to the provider may require or indicate changes to customers in the dependency.
According to this definition, association and generalization are dependent, but they have more special semantics, so they have their own names and detailed semantics. We usually use the word dependency to refer to other relationships. Table 4-3 lists some dependencies in the basic UML model.
Table 4-3 dependency types
Tracking is a conceptual expression of the connection between elements in different models. These models are usually models of different stages in the development process. Tracing lacks detailed semantics, which is especially used to trace the system requirements across models and trace the changes in models that affect other models.
Refinement represents the relationship between two forms of a concept at different development stages or at different abstract levels. This does not mean that the two concepts will coexist in the final model. One of them is usually an imperfect form. In principle, there is a ing between imperfect and well-developed concepts, but this does not mean that the conversion is automatic. Generally, a more detailed concept includes the designer's design decisions, which can be determined through many ways. In principle, changes to one model with an offset mark can be confirmed by another model. In fact, the existing tools cannot complete all these mappings, although some simple mappings can be implemented. Therefore, refinement usually reminds modelers of the relationship between multiple models in a predictable manner.
Export means that one element can be obtained by calculating another element (and the exported element can be explicitly included in the system to avoid Iterative Computing at too much cost ). Exporting, implementation, refinement, and tracing are abstract dependencies-they link different forms of the same potential thing.
The behavior or implementation of one element affects the behavior or implementation of another element. This usually comes from implementation-related issues, such as the need to define another class before compiling a class. Most dependencies can be obtained from code, and they do not need to be explicitly stated unless they are part of a top-down design-style system (for example, use a predefined component or function library ). A special relationship can be described in detail, but it is often ignored because the purpose of the relationship is to highlight the dependency. The exact details can be obtained from the implementation code. The constructors used include calls and instances. A call indicates that a method in a class calls an operation of another class; an instance indicates that a method of one class creates an instance of another class.
Several types of dependencies allow some elements to access other elements. The access dependency allows one package to view the content of another package. The introduction of dependency can meet higher requirements. You can add the name of the target package content to the namespace of the imported package. The user dependency is an access dependency that allows the customer to view the private content of the provider.
Binding is a parameter that assigns a value to the template. It is a highly structured relationship with precise semantics, which can be achieved by replacing the parameters in template backup. Use and bind dependencies to include strong semantics into the element at the same semantic layer. They must be connected to elements at the same layer of the model (either the analysis layer or the design layer, and at the same abstraction layer ). The tracking and precision dependencies are more vague, and the elements of different models or different abstraction layers can be connected.
An instance of a link (meta-link, not limited to dependencies) indicates that one element (such as an object) is an instance of another element (such as a class.
The dependency is represented by a virtual arrow pointing from the customer to the provider, and a constructor keyword is used to differentiate its type, as shown in Figure 4-11.
Figure 4-11 dependency
4.8 Constraints
UML provides a set of concepts and relationships for the modeling system in the form of model element diagrams, and some of them are better expressed in words, that is, the advantages of the text language. A constraint is a Boolean expression that can be expressed by strings interpreted in a specific language. Symbols, constraints, or programming languages in natural language, set theory can be used to represent constraints. UML defines a constraint language, OCL, which is conducive to expressing UML constraints and is expected to be widely supported. For details, see OCL introduction and [warmer-99.
Constraints can be used to indicate non-local relationships, such as restrictions on the associated path. Constraints can be particularly used to express existing features (if x exists, the C condition is true) and general features (for all y in Y, condition D must be true ).
Some standard constraints have been pre-defined as standard elements by UML, including various constraints in the Child-class relationship in association and generalization in an XOR relationship.
For details, see chapter 14th.
The constraint is expressed by a text expression in a Large arc. It can be a formal or natural language. A text string can be written as a comment or appended to the dependency arrow. Figure 4-12 shows some constraints.
Figure 4-12 Constraints
4.9 instance
An instance is a running entity with an identity, that is, it can be differentiated from other running entities. It has a value at any time, and the operation value on the instance will also be changed.
One of the purposes of a model is to describe the possible states of a system and their actions. The model is a description of the potential and the possible behavior history of the existing object set and object experience. The static view defines and limits the possible configurations of running system values. The dynamic view defines a way for the running system to pass from one configuration to another. In short, static views and various dynamic views built on them define the structure and behavior of the system.
A specific static configuration of a system is called a snapshot at a specific time point. Snapshots include objects and other instances, values, and links. An object is a class instance, which completely describes the direct instance of its class and the indirect instance of the class's ancestor (if allowed, the multiclass classification object may be a direct instance of multiple classes ). Similarly, a chain is an associated instance and a numerical value is a data-type instance.
The object has a data value for each attribute of its class, and each attribute value must match the data type of the attribute. If an attribute has optional or multiple duplicates, the attribute can have zero or multiple values. A chain contains multiple values. Each value is a reference of an object of a given class or a descendant of a given class. Objects and chains must comply with their classes or associated constraints (including both Explicit Constraints and embedded constraints such as multiple ).
If each instance of the system is an instance of some elements of a good system model and the instance meets all the constraints of the model, it indicates that the system status is a valid system instance.
A static view defines a group of objects, values, and links that can exist in a separate snapshot. In principle, any combination of objects and links consistent with the static graph is a possible configuration of the model. However, this does not mean that each possible snapshot can or will appear. Some snapshots may be static but not dynamic in the system's dynamic diagram.
The UML action section describes the effective sequence of snapshots, which may be the result of the influence of internal and external behaviors. A Dynamic Graph defines how the system converts from one snapshot to another.
4.10 object graph
The Snapshot graph is the image of the system at a certain time point. Because it contains the object image, it is also called an object graph. As a sample of the system, it is useful. For example, it can be used to describe complex data structures or represent behavior (4-13) in a series of snapshots ). Remember that all snapshots are system samples rather than system definitions. The system structure and behavior are defined in the definition view, and the creation of the definition view is the goal of modeling and design.
The static view describes possible instances. In addition to samples, actual instances do not always appear directly in the model.
Figure 4-13 object chart
|
