Unified modeling language UML static modeling mechanism
(This article is reproduced from Software Engineering Expert Network www.21cmm.com)
Any modeling language is based on a static modeling mechanism, and the standard modeling language UML is no exception. The static modeling mechanism of the UML includes the use case (Class Diagram), a Class Diagram, a Package, a component diagram, and a configuration diagram (DEPLOYMENT DIAGRAM).
Use example
(1) Use case model (use case model, in terms of object-oriented development and traditional software development, people understand demand based on typical use scenarios. However, these use scenarios are informal, although often used, it is difficult to establish a formal stationery. The use case model is first used by Ivar Jacobson in the development of the AXE system and joins the OOSE and Objectory methods he advocated. The use case method has caused great attention to the object-oriented field. Since the publication of Ivar Jacobson in 1994, the concept of use of the use case has been widely accepted in the object-oriented field, and it is considered to be the second generation of object-oriented symbols. The use case model describes the system function as understood by the External Executers. The use case model is used in the demand analysis phase, and its establishment is the result of system developer and user repeated discussion, indicating the consensus of developers and users to demand specifications. First, it describes the functional requirements of the system to be developed; secondly, it looks a system as a black box, understands the system from the perspective of external executors; third, it droves the development of various phases after demand analysis, not only development In the process, the implementation of all systems is guaranteed, and it is used to verify and detect the system developed, which affects the various stages of development and various models of UML. In UML, a use case model is described by several use case diagrams, with an example map main element is a use case and an executter.
(2) Use case, from essentially, one use case is a typical interaction between the user and the computer. Taking the word processing software as an example, "some of the aquent space is black" and "Creating an index" are two typical use cases. In UML, the use case is defined as a series of actions performed by the system, and the result of the action execution can be perceived by the specified executor.
In UML, the use case is expressed as an ellipse. Figure 1 shows an example of a financial trade system. Among them, "Risk Analysis", "Transaction Valuation", "Trading", "Set Boundary", "Transaction", "Evaluation Trade", "Update Account", etc. are all instances of the use case. In summary, the use of examples have the following features: • Use an example to capture some user visible needs and implement a specific user objective. • Use examples are activated by the executive, and provide exact values to the executive. • The use case can be large, but it must be a complete description of a specific user objective.
(3) Executor (actor)
The executor refers to the role that the user played in the system. Its graphical representation is a small person. There are four executors in Figure 1: trade managers, marketers, salespersons and billing systems. There are many marketers in certain organizations, but they all play a same role in the system, and use an executor. A user can also play a variety of roles (performers). For example, a senior marketing personnel can be both a trade manager or an ordinary marketing personnel; a marketer can also be a salesman. When dealing with the executor, it should be considered, rather than a person or work name, this is important. In Fig. 1, the line segment without an arrow will connect the executor and the use case to the exchange information, referred to as communication links. The executor triggers the use case and exchanges information with the use case. A single executor can contact multiple use cases; in turn, a use case can contact multiple executives. For the same case, different executives have different roles: they can take values from the examples or participate in the use case. It should be noted that the executor is represented by the image in the case of the example, although executed, but the executor is not necessarily a person. For example, the executor can also be an external system that may need to obtain information from the current system and interact with the current system. In Figure 1, we can see that the billing system is an external system that requires an account. Through practice, we found that the executivers are very useful for providing the use case. In the face of a large system, it is often very difficult to list the use case. At this time, you can list the executor's list, then list it for each executor, the problem will become easier.
(4) Use and expansion (use and extend)
In addition to the connection between the executor and the use case, in Fig. 1, there are two types of connections to indicate the use and expansion relationship between use. Use and extensions are two different forms of inheritance relationships. When a use case is similar to another, it can be extended by more than one action. For example, in Figure 1, basic use cases are "transaction". Once all, everything is going well, but it may also have a factor that disturbed smooth transactions. One of them is to exceed certain boundary values. For example, the Trade Organization will regulate maximum trade for a particular customer, and the conventional actions provided by the given example cannot be performed, but to do some changes. We can make changes in "transaction" use cases. However, this will mix this use with a large pile of special judgment and logic, so that the normal process is embarrassed. In Fig. 1, the routine action is placed in the "transaction" use case, and the unconventional action is placed in the "transaction of the boundary", which is the essence of the extended relationship. When there is a large block of action exists in several cases, it can be used when the action is description, and it can be used. For example, reality risk analysis and transaction valuation requires evaluation trade, and can separately define a use case, ie "evaluation trade", and "risk analysis" and "transaction valuation" use cases will use it. Please pay attention to the similarities and different points between extensions and use. Both of them mean those common behaviors from several use cases and put them in a separate use, and this use case is used or expanded in several other use cases. But the purpose of use and expansion is different. (5) Acquisition of case model
Almost use cases in any case. Use examples to access demand, planning, and control projects. The acquisition of the use case is one of the main tasks of the demand analysis phase, and it is the first thing to do. Most uses will be generated during the demand analysis phase of the project and discovers more use as the work is discovered, and these should be added to existing use cases in time. Each use case in the use case is a potential requirement.
a. Get the executor getting the use case first to find out the executor of the system. You can identify the executor by answering the answers to some questions. The following questions are available for reference: · Who uses the main function of the system (main user). · Who needs to support their daily work. · Who will maintain, manage the system normally (auxiliary users). • Systems need to manipulate which hardware. • The system needs to interact with which other systems, including other computer systems and other applications. · People or things interested in the results of the system.
b. Once the use case obtains the executive, you can make a problem for each executor to obtain the use case. The following questions are available for reference: • What functions are required for the executor to provide the system? • What types of executives need to read, generate, delete, modify, or store. · What are the system events that must be reminded? Or what the executor must remind the system? How do these events represent the function in the use case? · In order to completely describe the use case, you need to know some of the executive some typical functions. Can you be automatically implemented by the system? There are some unimportant issues (ie, what is the problem of the entire system): Is it a major problem with some manual operations instead of a computer system?
It should be noted that the last two problems do not mean that there is no executor or useful examples, just getting the use case, I don't know what the executor is. A use case must be associated with at least one executor. It should also be noted that different designers have different degrees of utilization. For example, Ivar Jacobson said that he needs 20 use cases for a ten-year-old project. In an item of the same size, Martin Fowler uses more than 100 cases. We believe that any suitable use case can be used, and the process of determining the use case is the process of extracting and summarizing the acquired use case. For a ten-year-old project, twenty use cases seem to be too small, more than 100 cases It is too much to keep the relative balance between the two.
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 "passenger", "customer name", "address", etc. The property is selected. 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 included in the properties of the class; * The purpose of system modeling will also affect the selection of attributes. According to the level of the graph, each property can include the visibility, attribute name, type, default Value and constraint characteristics. The syntax of the attribute of the class specify the class: Temperacy name: Type = Default {constraint characteristic} In the "Customer" class, "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 features. 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 It is the basic data type, such as integer, real, Boolean, etc., or the user-defined type. Generally, it is determined by the programming language involved. The constraint characteristics are a constraint for the property nature. For example {Read-only} "Description 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
Association indicates that there is a semantic connection between 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 Fig. 1, the "insurance policy"? Quot; insurance policy "is an unidirectional association .uml stipulates that the association without arrows can mean unknown, undecided, or the association is two-way related three options, therefore, The picture should be explicitly used in the selection. Since the associated naming can be two-way, the most complex naming method gives a name in each direction, such a association has two names, which can be expressed with a small black triangle The direction of the name (see "the uppermost" belonging "in Figure 1 is" / "signing". There are several ways to associate naming. The principle is whether the naming helps to understand the model. The role is associated with two heads The role is involved in the association. For example, "Company" is associated with the "employer" role in "employer", "employers" and "employee" are called the role name. If The role name is not marked on the associated, then implied the name of the class as a role name. The role also has multiple objects, indicating how many objects can participate in the association. In Figure 2, employers (companies) can Employment (signing work contract) 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 participation objects. "*" Represents 0 ~ ∞, that is, a customer can have no insurance policy, or there can be any more insurance policy. "1" is the shorthand of 1..1, that is, any insurance policy only comes from one customer, you can use a single number, too A combination of range or scope is not continuous. Associated class is associated may record some information, which can introduce an associated class to record. Figure 3 is introduced in the basis of Figure 2. Association class passed The root dashed line is connected to the associated connection. Figure 4 is another method of achieving the above object, is to make 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 relationship
People will have a common feature of elements into categories and further classify them 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
There are two elements x, y, if the definition of modification element X may cause modifications to the definition of another element y, referring to the element Y dependence (Dependency) at 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 level and refinement of class diagrams
It should 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) constraint
In UML, the rules can be expressed in 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 diagram, object and chain
The object map in UML has the same representation as the class diagram. 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 mechanisms
The model elements and representation mechanisms used in class diagrams are relatively rich, and due to the limitations of the space, they 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 recommendations using class diagrams
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.
3. Components graphs and configuration diagrams
Component Diagram and Configuration Diam Displays some features of the system implementation, including the static structure of the source code and the implementation structure of the runtime. The component chart shows the structure of the code itself, and the configuration diagram shows the structure of the system running time.
(1) The component map member diagram shows the dependencies between the software components. In general, the software component is an actual file, which can be a source code file, binary code file, and executable. It can be used to display the dependencies between compilation, link, or execution time. (2) Configure the graph configuration diagram Describe the physical topology of the system hardware and software executed on this structure. Configuration diagram can display the topology and communication paths of the calculation node, the software components that run on the node, the logical unit (objects, classes), etc. of the software components. Configuration diagrams are often used to help understand distributed systems.
(3) Node and Joint Node (Node) represents a physical device and its software system, such as a UNIX host, a PC terminal, a printer, a sensor, and the like. As shown in Figure 1, "Client PC" and "Insurance Bed Server" are two nodes. The node is expressed as a cube, and the node name is placed in the upper left corner. The connection between the node represents an interactive communication path between the system, and is called a connection in UML. The communication type is placed between "" "", indicating the communication protocol or network type used.
(4) Components and interfaces In the configuration diagram, the component represents an executable physical code module, such as an executable program. It is logically corresponding to the package or class in the class diagram. Therefore, the distribution of each package or class in the node is displayed in the configuration diagram. As in Figure 1, the "Insurance Bed Server" node includes 3 components of "Insurance System", "Insurance Object Database" and "Insurance System Configuration". In an object-oriented method, elements such as classes and components are not all visible to all attributes and operations. They provide visible operations and properties, called the interface of the components. The interface can be expressed as a straight line of the small garden circle. In Figure 1, the "Insurance System" member provides a "configuration" interface. The dependency between the components is also shown, and the "Insurance System Configuration" component depends on this "configuration" interface.
(5) Object (Object) A many objects can run in an object-oriented software system. Since the component can be considered as a physical code module corresponding to the package or class, some running objects should be included in the component. The objects in the configuration diagram are the same as the object representation in the object map. In Figure 1, the "Insurance System Configuration" component contains two objects of "Configuration Insurance Policies" and "Configure User". Static modeling mechanism for standard modeling language UML is the basis for modeling UML. We believe that proficiency masters basic concepts, distinguishing different abstractions and flexible use in practice, is the basic principles of three most worthless.
