(Connected to the previous period)
The main contents of the first two periods are as follows:
First, standard modeling language UML overview
Second, the standard modeling language UML static modeling mechanism
Use example
2. Class diagram, object map and package
Thousands of years ago, human beings have begun to effectively simplify complex problems with classification methods, helping people understand the objective world. In object-oriented modeling technology, we use the same method to map objective world entities to objects and are summarized into a class. Class (CLASS), objects (Object) and the association between them are the most basic elements in object-oriented technology. For a system that wants to describe, its class model and object model reveals the structure of the system. In UML, class and object models are represented by class diagrams and object maps, respectively. Class diagram technology is the core of the OO method. Figure 1 shows a class diagram of a financial insurance system.
(1) class diagram
Class Diagram Describes the static relationship between classes and classes. Unlike the data model, it not only shows the structure of the information, but also describes the behavior of the system. Class diagrams are the basis for defining other pictures. On the basis of the class diagram, the state diagram, cooperation, and the like further describe the other features of the system.
(2) Class and object
Object (Object) is related to our understanding of the objective world. We usually describe a specific entity in the objective world with an object. The class (CLASS) is a description of a class having the same features. The object is an instance of a class (Instance). When establishing a model model, we should try to keep consistent with the concept of the application field, so that the model is more in line with objective facts, easy to modify, easy to understand and easy communication.
Class Description A type of object's properties (attribute) and behavior (Behavior). In UML, the visualization of the class is a rectangle that divides three plaids (the following two plaids can be omitted). In Figure 1, "Customer" is a typical class.
Get acquisition and name the top grid contain the name of the class. Naming of class should try to use the terms in the application, which should be clear, unambiguous, to facilitate mutual understanding and communication between developers and users. The acquisition of the class is a process that relies on people's creativity. It must work with the field experts to carefully analyze, the concepts in the field, define their meaning and interrelation, and analyze the system, and use the field Terminology is named. In general, the name of the class is a noun.
The lattice in the middle of the class contains the properties of the class to describe the common features of the object. This item can be omitted. Figure 1 "Customer" class has the characteristics such as "customer name", "address". The following factors should be considered: * In principle, the attributes of the class should be described and distinguished by each particular object; * Only the feature of interest is only included in the properties of the class; * System modeling is also Affect the choice of attributes. According to the detailed level of the figure, each attribute can include the visibility, attribute name, type, default and constraint characteristics of the attribute. The syntax of the attribute of the class is: visibility attribute name: Type = default value {constraint characteristics} In "Customer" attribute, "Customer Name" attribute is described as "- Customer Name: String = Default Customer Name ". Visibility "-" indicates that it is a private data member, its property name is "customer name", type "string" type, the default value is "default customer name", there is no constraint characteristic. Different attributes have different visibility. Commonly used visibility has three kinds of public, private, and protected, which are represented as " ", "-", and "#" in UML. Type indicates the type of this property. It can be basic data types, such as integer, real, Boolean, etc., can also be a user-defined type. It is generally determined by the programming language involved. The constraint feature is an explanatory description of the user's nature of this attribute. For example, "{read-only}" indicates that this property is read-only attribute. Operation of the class This item can be omitted. Operation is used to modify, retrieve the properties of the class or perform some actions. Operation is often also referred to as a function, but they are constrained in the inside of the class, and can only act on the objects of the class. The operand, the return type, and the parameter table form an operation interface. UML specified the syntax for the operation: the visibility operator name (parameter table): Return Type {constraint characteristic} In Figure 1, "customer" class has "customer address" operation, where " " indicates that the operation is public operation. When calling, the parameter "customer name", the parameter type is a string, and the return type is also a string. The class diagram describes the static relationship between classes and classes. After defining classes, you can define all kinds of relationships between classes.
(3) Association indicates that there is a semantic connection between the two classes. For example, a person works as a company, a company has many offices. We think that there are some semantics between people and companies, companies and offices. In the class diagram model of the analysis, it is established between the corresponding human and corporate classes, corporate classes, and office classes. At the top of Figure 1, there is a "belonging to" / "signing" association: each "insurance policy" belongs to a "customer", and "customer" can sign multiple "insurance orders". In addition to this association, there are other two associations in Figure 1, indicating that each "insurance policy" contains a number of "insurance policy", and the project on each "insurance policy involves a single" insurance category ". The associated direction is associated may have a direction, indicating that the associated order is used. Adipontollas with arrows represent the direction, referred to as navigability in UML. We will only have the association of navigation representation in one direction, referred to as a unidirectional association, and a navigation representation in both directions, called Bi-Directional Association. In Figure 1, the "Insurance Order" to the "Insurance Order" is one-way association. UML stipulates that the association without arrows may mean unknown, unspeakable or the association is two-way associations, and therefore, one of them should be explicitly used.
The associated naming is that the association can be two-way, the most complex naming method is given a name in each direction, such a association has two names, which can use small black triangles to represent the direction of the name (see Figure 1 in the uppermost) "Belongs to" / "sign" association). There are several ways to renovate the associated naming. It is whether the naming helps to understand the model.
The role is associated with a class involved in a role. For example, in Figure 2, "Company" is associated with the "employee" role in "employees". "Employers" and "employees" are called role names. If the role name is not marked on the associated, the name of the class is hidden as a role name. The role also has multiplex, indicating how many objects can participate in this association. In Figure 2, employers (companies) can hire multiple employees, expressed as "*"; employees can only sign a work contract with an employer, expressed as "1". Multipleness indicates the upper and lower boundary restrictions of the number of participating objects. "*" Represents 0 ~ ∞, that is, a customer can have no insurance policy, or there can be any more insurance policy. "1" is a shorthand of 1..1, that is, any insurance policy only comes from one customer, can be represented by a single number or a combination of numbers and scope discontinuous. Associated class associations may be recorded, which can be recorded in an associated class. Figure 3 is an associated class in which the associated class is introduced on the basis of FIG. The association class is connected to the associated connection. Figure 4 is another method of achieving the above objective, that is, enabling the employment relationship into a formal class. Aggregation is a special form of association (AGGREGATION). The relationship between the aggregation representation is the overall relationship. A car contains four wheels, a steering wheel, an engine and a chassis, which is an example of aggregation. In the demand analysis, "including", "consisting", "divided into ... part", etc., often designed to be aggregated. The aggregation can be further divided into shared aggregation and composed. For example, the topic group contains many members, but each member can be a member of another topic group, i.e., some can participate in multiple overall, we call it sharing aggregation. Another situation is that overall has part, partially coexisting, if the overall does not exist, and some will disappear, which is called composition. For example, we open a window that is composed of a title, an outer frame, and a display area. Once die, each part disappears. In UML, the aggregation is expressed as a hollow rhombus, which is expressed as a solid rhombus. It should be noted that some object-oriented masters are different from the definition of aggregation. Everyone should pay attention to other object-oriented methods and differences defined in UML.
(4) Inheritance Relations will have an element that has a common feature is abstracted, and further classifys by increasing its connotation. For example, animals can be divided into flying birds and beasts, people can be divided into men and women. In the object-oriented method, the former is called a general element, a base type element or a parent element, and the latter is referred to as a special element or child element. Generalization defines the classification relationship between general elements and special elements. In UML, inherit is shown as a connection of a hollow triangle. As in Figure 1, customers are further classified into individual customers and group customers, using inheritance relationships. There are three requirements for inheritance in the UML definition: * Special elements should be exactly consistent with the general elements, the associations, attributes, and operations of the general elements, and special elements are implied; * Special elements should also contain additional information; * Allows the use of general elements, special elements should also be used.
(5) Dependency has two elements x, y, if the definition of modification element X may cause modifications to the definition of another element y, referred to as Dependency, in element X. In the class, dependency is caused by various reasons, such as: a class to another class; a class is a data member of another class; a class is another type of operational parameters of another class. If a class of interface changes, any message it issued may no longer legal.
(6) Abstract levels and refinements of class diagrams need to be noted that although the class diagrams are used at different stages of software development, these class diagrams represent abstraction of different levels. In the demand analysis phase, class diagrams are concepts in research areas; in design phases, class diagrams describe interfaces between classes and classes; in the implementation phase, the class diagram description software system is implemented. According to Steve Cook and John Dianiels, class diagrams are three levels. It should be noted that this view is also suitable for any other model, but it seems more prominent in the class diagram. Concept layer concept layer (conceptual class diagram) describes the concept in the application. Classs that implement them can be drawn from these concepts, but both have no direct mapping relationship. In fact, a conceptual model should be independent of its software and programming language. Description Layer Description Layer Diagram Description Software The interface portion of the software is not the implementation of the software. Object-oriented development methods attach great importance to differences between interfaces and implementations, but in practical applications, this difference is often ignored. This is mainly because the concept of the oo language is together with the implementation. Most ways are also imitated in this practice due to the influence of language. This situation is now changing. An interface can be described with a type (TYPE), which may have a variety of implementations because of the implementation of the environment, run characteristics, or the user. The implementation layer only has a concept that is really classified in the implementation layer and discloses the implementation of the software. This may be the most common class diagram of most people, but in many cases, the class diagrams of the description are more likely to understand and communicate between developers.
It is important to understand that the above level is critical to the drawing graphs and read classes. However, because there is no clear boundaries between each level, most modeling people can distinguish them when they draw. When drawing, you should start from a clear hierarchy; when reading the picture, you have to figure out which level concept is drawn. To properly understand the class map, first, the above three levels should be correctly understood. Although it is not an integral part of three levels into three levels, they are very useful for modeling or evaluation models. Although people seem to have emphasized to achieve layer graphs so far, these three levels can be applied to UML, and the other two levels of class are more useful.
The refinement concept is introduced. Refining is the term in UML, indicating a description of the more detailed layers of things. Two elements A, B describe the same thing, and their difference is different from the abstraction level. If the element B is a more detailed description on the basis of element A, the element B is refined to refine the element a, or called element a fine Chemical formation element B. The refined graph is expressed as the element B pointing to the element A, a broken line with a hollow triangle (do not reverse the direction!). Refining is mainly used in cooperation between models, indicating the relevance of different levels of abstract models in each stage, often used to track the evolution of the model.
(7) Constraints in UML, can be used to represent rules with constraints. The constraint is an expression in parentheses "{}" to represent an immediate logical statement. In programming languages, constraints can be implemented by an assertion.
(8) Object maps, objects and chain UMLs have the same representation as the class diagrams. Object charts can be seen as an instance of class diagrams. Object is an instance of a class; a link between objects (LINK) is an example of association between classes. The object is similar to the graphical representation of the class, all of which are divided into two plaids (below the plaids). The above lattice is an object name, and there is an underscore under the object name; the following lattice record attribute values. The graphic representation of the chain is similar to the association. Object maps are often used to represent an example of a complex class diagram. (9) Package an oldest software method problem is: How to split large system into a small system. One idea to solve this problem is to set a number of classes into a higher level, form a collection of highly polymerized, low coupling classes. This idea is loosely applied to many object technology. This packet mechanism is called a package (see Figure 5) in UML.
Not only the class, any model element is used to use the package mechanism. If there is no inspiration principle to guide the group's packet, the grouping method is arbitrary. In UML, the most useful and emphasis on the most inspiration principle is dependent. The package chart mainly shows the level of dependencies between the classes and the dependencies between these packages. Sometimes the inheritance relationship and composition relationship between packets and packages are also displayed. The contents of the package are in Figure 5, the "system internal" package is composed of the "insurance policy" package and "customer" package. Here, the "insurance policy" package and "customer" package are the content of the "internal" package. When the content of the package is not required, the name of the package is placed in the main box, otherwise the name of the package is placed in the small square box in the upper left corner, and the content is placed in the main box. The content of the package can be a list of classes, or another package diagram, or a class diagram. Dependency and inherit of Figure 5, "Insurance Failure Filling Interface" package depends on the "insurance policy" package; the entire "system internal" package depends on the "Database Interface" package. The relationship between the general packets and special packages can be used to explain the concept of general and special examples in inheritance. For example, a special package must meet the interface of the general-purpose package, similar to the class inheritance relationship. Through the "Database Interface" package, the "System Internal" package can use the Oracle interface that can also be used using Sybase interface. A general package can be marked as {ABS Tract}, indicating that the package is only defined an interface, and the specific implementation is completed by a dedicated package.
(10) Other model elements and representation of model elements and representation mechanisms used in mechanism classes are relatively rich. Due to space limitations, it cannot be introduced here. There are also the following model symbols and concepts: Category template (interface), parameterized class, Template, Qualified Association, multi-dimensional association (N-Ary Association) ), N-Ary Link, Derived, Type (Type), and Note (Note).
(11) Several proposed class diagrams using class diagrams are almost all the pillars of all OO methods. When modeling the standard modeling language UML, you must have a clear understanding of the various elements introduced by the UML class map. The following recommendations for modeling the class diagrams: * Do not try to use all symbols. From simple start, for example, classes, associations, properties, and inheritance. In UML, some symbols are only used in special occasions and methods, only when needed. * Painted by the correct views according to the different phases of the project development. If it is in the analysis phase, the concept layer class diagram; when starting the software design, you should test the layer diagram; when a particular implementation technology is examined, the layer class diagram should be achieved. * Don't draw a model for each thing, you should put your energy in key areas. It is best to draw a few critical graphs, often use and constantly update modifications. The biggest danger of using class diagrams is prematurely into the implementation details. To avoid this danger, you should focus on the concept layer and the description layer. If you have already encountered some trouble, you can reflect from the following aspects. * Whether the model truly reflects the actual situation in the research field. * Whether the elements in the model and the model have a clear purpose and post (in the object-oriented method, the system function is ultimately assigned to each class, this mechanism is the duties). * Model and model elements are moderate. The too complex model and model elements are difficult to survive, and they should be broken down into several parts that cooperate with each other.
(12) Terminology Comparative The following table lists the most commonly used four UML terms and compared to the terms corresponding to other methodologies to help readers understand the Similarities and differences of UML and other modeling languages. (Endlessly)
