Shao Weizhong meihong
Recently, the Unified Modeling Language (UML) initiated by Rational Company of the United States and jointly launched by more than a dozen other companies has attracted wide attention in the OO field. This paper first introduces the background and main contents of UML, and then comments on its positive influence on object-oriented modeling technology and possible problems. UML is a powerful modeling language with rich expressive power. But at present, it can't be concluded that it will replace the existing object-oriented analysis and design methods, because it is only a modeling language, not a method; Its complexity may become an obstacle for it to win a large number of users.
Object-oriented, modeling method, modeling language
China Library Classification Number TP3 1 1
Overview of Unified Modeling Language
Shao Wei Zhonghe Hong Mei
Department of Computer Science and Engineering; Technology, Peking University, Beijing 10087 1)
Unified Modeling Language (UML) issued by Rational Software Company and other UML partners has attracted wide attention in the field of object technology. This paper introduces the historical background and main contents of UML, and discusses its significance, positive influence and possible problems. UML is a modeling language with strong expressive ability and powerful function. However, it cannot be concluded that it will replace all existing object-oriented analysis and design methods. The reason is that UML is only a modeling Gu Lan era, not a method, and its excessive complexity may become an obstacle to win a large number of users.
Keywords object-oriented, modeling method, modeling language
Background of 1 UML
Due to the increasingly prominent importance of OOA/OOD method, people's enthusiasm for its research, development and application is also growing. In 1989, there were nearly 10 OOA methods or OO modeling languages in the form of monographs, papers or technical reports. By 194, the number of OOA methods had increased to more than 50. The emergence of various methods has made new contributions to the research and development of OOA/OOD technology. This booming situation shows that object-oriented methods and technologies have been widely recognized and become the mainstream at present. However, the popularity of various methods at the same time has also brought some problems: there are many similarities and differences in the concepts adopted by various OOA and OOD methods (for example, many methods are in the same part), and the differences in representation symbols, OOA models and document organization are more obvious, which often makes it difficult for some new users to make decisions when choosing modeling methods and tools, and is not conducive to technical communication between them.
In view of this situation, G.Booch and J.Rumbaugh, who worked in Rational Software Company in the United States in 1994, thought that their respective methods (Booch method [1] and OMT [2]) should be combined to form a unified method. They started the work in June that year. And in 1995, 10 publicly released the first version, that is, unified method 0.8. 1995 autumn OOSE initiator I Jacobson [3] joined Rational Software Company, and therefore joined the ranks. G.Booch, J.Rumbaugh and I.Jacobson. There are three reasons for putting forward a unified modeling language:No. 1, and their respective methods have been combined in evolution; Second, moving towards unification will bring market benefits; Third, it helps to improve their respective methods, so as to gain more learners and solve some problems that their respective methods could not solve well in the past.
In order to determine a set of symbols for analysis and design, they encountered some problems that need to be weighed. First, the definition of the scope of the problem. For example; Should the requirement specification be included? (The answer is yes, it should be partially included); Should a visual programming language be included? (the answer is "no"). Second, there is a need to compromise between expressive ability and conciseness. Too simple representation will limit the ability to solve problems, and too complicated will make ordinary developers at a loss. Thirdly, they must combine their original three methods, which also makes them worry about the size of the change to the original method. Too big a change will confuse old users. If you keep the original things, you will lose the opportunity to make improvements and win more new users. According to these problems mentioned in UML literature, the proposal of UML is not simply to find the most reasonable solution from the academic and technical standpoint, but must consider some practical backgrounds related to the company, old users and original methods.
In any case, they made what they thought was the best trade-off under this background, and released UML versions 0.9 and 0.9 1 in June and June respectively. Since then, "unified method" has been renamed as "unified modeling language" because it is not entirely an object-oriented modeling method. This is an object-oriented modeling language. It just gives a set of elements and symbols for modeling and defines their semantics, instead of telling how to model the system. As M.Fowler pointed out in his book on UML [4], "UML is called a modeling language, not a method. At least in principle, most methods are composed of a modeling language and a process. Modeling language is one of them. This process is a suggestion on what steps should be taken in the design. " M.Fowler's book is written in the background of UML 1.0, and G.Booch, I.Jacobson and J.Rumbaugh personally preface the book. This can at least be said that the overall evaluation of UML in the specification is recognized by its founder.
1996, Rational is going to apply to the Object Management Group (OMG) to use UML as the standard modeling language. So a partner organization of UML was established, including Rational itself and 12 companies. They launched the UML 1.0 version. In 1997, the application was submitted to OMG as a preliminary proposal. 1997, several other companies submitted their own applications for modeling language proposals to OMG. Therefore, UML partner organizations have absorbed these companies into their ranks. In order to reflect the opinions of these new members, UML 1.0 was revised. Uml 1. 1 was produced in 1 September 9971and submitted to OMG, which adopted it in the same year. At present, UML 1. 1 is the latest version, but it is not the final version. Because it's still being revised. Up to the publication of UML 1. 1, the following 17 companies have participated in the joint action of UML: Rational Software, Microsoft, Hewlett-Packard, Oracle, Sterling Software, MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjectTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam.
2 UML content overview
According to the UML document, "Unified Modeling Language (UML) is a visual construction and documentation language for product specifications of software systems, and can also be used for business modeling and other non-software systems." UML 1. 1 provided six documents, all of which were jointly published in the name of 17 company, a UML partner organization. These documents are briefly introduced in this section, and then in the next section.
(1) UML Summary: It is a general introduction to UML, including its motivation, objectives, scope, history and present situation.
(2) UML semantics: It defines the semantics of UML. The definition adopts formal technology, but it is not a completely formal specification. Grammatical structure is accurately described, and its dynamic semantics are described in natural language. The syntax of UML is an abstract syntax independent of symbols, which can be mapped to different symbol systems. Although it is not completely formal, its definition is quite complicated: it adopts a four-level meta-model architecture, and the text length reaches more than 160 pages. In Section 2.2 of this document, four levels of the model are introduced, namely:
Meta-model: the basic framework of meta-model, which defines the language for describing meta-model.
Meta-model: An example of meta-meta model, which defines a language to describe the model.
Model: An example of a meta-model, which defines a language to describe the information domain.
④ User object: an instance of the model, which defines a specific information domain.
The definition of model elements at all levels is as follows: first, the abstract syntax is given (using UML class diagram to describe the relationship between elements), then the formal rules are given (using text and object constraint language), and finally the semantics are described (using accurate text). In this way, 1 18 elements are defined, which are divided into 3 parts and 9 packages.
(3) UML Symbol Guide: This document gives the visual representation of UML, and gives the graphical representation symbols of model elements through examples. See the next section for details.
(4) Object Constraint Language specification: This document defines and introduces an object constraint language (OCL), which is used to explain some modeling information that cannot be fully expressed in the graphics system model. It is a formal language, but it is easy to write and read. As a modeling language, it does not mean implementation problems. In other words, it is used to explain the model in detail, not to compile it.
(5) UML extension of software engineering objective process: According to the requirements of software engineering, some UML extension concepts are defined. For example, models are divided into four types: use case model, analysis model, design model and implementation model. The definition of each extended model concept is given. It does not introduce the object-oriented development process, nor does it talk about how to use UML in the process. The content of the document is short, only 5 pages.
(6) UML extension of business modeling: some UML extension concepts of business modeling are defined, which are similar to the previous documents, except that their extension is aimed at general business processing modeling, not software engineering. The file is also very short.
3 UML symbol guide
This document gives the visual representation of UML, and gives the graphical representation symbols of model elements through examples. From the level of system model, UML representation consists of nine kinds of diagrams, which are:
Static structure diagram, including class diagram and object diagram;
Use case diagram;
Sequence diagram;
Collaboration diagram;
State diagram chart;
Activity diagram;
Implementation diagram, including component diagram and deployment diagram.
Although the UML document says that "UML symbol guide defines symbols and provides examples", the exact statement should be: the document gives a general description of modeling element symbols, and its graphics are represented by examples, but no general diagrams are given. Most of the illustrations in this paper are given in a general sense with reference to M.Fowler's book [4].
UML defines some common elements in various diagrams, such as strings (names), labels (labels), keywords (keywords), expressions (expressions), comments (comment columns) and so on. And their symbols are given. For example, keywords are represented by strings contained in the title of a book. The comment bar is represented by text in a rectangle with a corner folded. In various diagrams, the elements used to encapsulate a set of model elements are called "packages". This group of elements is surrounded by a big box, and the name of the package is given by a small box in the corner.
In addition, UML defines some elements called "extension mechanism". These elements can be attached to other model elements to specialize the original model elements into new variants with special semantics or express some details of them. These elements can expand or refine the representation. They are:
Constraint: Constraint is the semantic relationship between model elements, which explains some conditions and some propositions that must be kept true. Its representation is to write a text string between braces in a language that tools (such as OCL provided by UML) can recognize.
Comment: A comment is a text string written in a symbol (a rectangle with folded corners) in the comment bar. The language used should be easy for people to understand, whether it is understood by tools or not.
Element attributes: used to display some incidental characteristics of model elements, such as attributes, associations, target values, etc. Its manifestation is to write the text string in the form of keywords = values with braces, and separate multiple strings with commas.
Prototype: used to attach to other model elements and specialize the original model elements into new variants with special semantics. Model elements with layout can be regarded as a subclass of the original model elements, which have the same form as the original elements in attributes and relationships, but are more specific in use. The type of plate is indicated by the keywords contained in the book name. The representation of the above concepts is shown in figure 1.
Graph 1 graph elements, packages and extension mechanisms
The following describes the various diagrams and the modeling elements and representations used in the diagrams.
(1) static structure diagram
Static structure diagram includes class diagram and object diagram. "A class diagram is a graphical representation of a static structural model." "A class diagram is a collection of (static) declared model elements." Regarding an object diagram, the document says: "An object diagram is an instance diagram, including the values of objects and data, and a static object diagram is an example of a class diagram. It shows a snapshot of the detailed state of the system at a certain point in time. " The document also points out that "the usefulness of object graphs is very limited" and "tools do not need to support independent object graphs". A class diagram can contain objects, and a class diagram with objects but no classes is an "object diagram". However, this term is still helpful to describe the special usage that may be realized in various ways. " The representations of various modeling elements used in the static structure diagram are shown in the following figure.
Figure 2 Representation of modeling elements in static structure diagram
Class: A class is a description of a group of objects with similar structures, behaviors and relationships. UML provides three graphical representations for a class. 1 is a way to hide details, and only the class name is given in a box. The second method is the analytical level detailed method, which gives the class name, attribute name, type and operation name in the upper, middle and lower columns respectively. The third method is the implementation level detail method, which gives more details.
Name interval: defines the writing specification of class symbol name column.
List area: defines the writing specifications of attribute columns and operation columns of class symbols.
Attribute: specifies the writing method of attribute and the following three visibility symbols: "+"means public, "#" means protected, and "-"means private.
Operation: specifies the writing method of the operation, and adopts three visibility symbols which are the same as the attributes.
Type and implementation class: these are two special class elements, which are obtained by attaching the layout keyword "type" or "implementation class" to the class symbol, and giving the definition details of attributes and operations in the attribute column and the operation column. Among them, "type" describes the variable rules that an object may adopt and then discard; "Implementation class" defines the physical data structure and process when an object is implemented in a language. The following seven symbols are all obtained in this way.
Interface: An interface is a description of an externally visible operation of a class or other entity (such as a package). It does not describe the structure of the entity. Its representation is similar to a class symbol, but there is no attribute column. Add the keyword "interface" in the name column and fill in the interface definition in the operation column.
Parameterized class: It is a class with one or more unbound formal parameters, so it defines a class family and binds the form to an actual value to explain one of the classes. The representation of parameterized classes is to add a dotted box in the upper right corner of the class symbol, in which the different implementation types of each parameter are explained.
Binding element: its function is to associate (bind) the parameters of the template with the actual values. Its performance is to explain the parameter value table of the template in words.
Utility: A set of global variables and procedures declared in the form of classes. It is not a basic structure, but a programming tool. Its representation is marked with the keyword "utility" in the class name column of the class symbol.
Metaclass: A class of a class, whose example is a class. Its performance is to add the keyword "metaclass" to the class name list.
Class pathname: used to indicate a reference to a class. Symbol refers to the referenced class name (in other packages) with the symbol "∷" where this class is referenced.
Import package: indicates that classes in another package can be referenced in one package. This is a special dependency. It is manifested by adding the keyword "import" to the dependency symbol (dotted arrow).
Object: An object is a special instance of a class. The object representation given by UML is a box with only two columns. The Name column is filled with the name of the object (instance) and indicates the class name to which it belongs. The value of each attribute is given in the attribute column.
Composite object: a high-level object composed of some closely related parts, which is an example of a composite class. It is represented by a box with two columns. Fill in the name of the composite object in the upper column and indicate its class name, and draw its parts and objects in the lower column.
Correlation: It is divided into binary correlation and multivariate correlation, and the following items are introduced respectively.
Binary association: it is an association between two classes (including a special case of association between a class and itself). Its manifestation is to connect two class symbols with a solid line. This line can be drawn as a straight line, diagonal line or curve according to the convenience of drawing, or it can be composed of several segments. The place where the endpoint of the line intersects with the class symbol is called the associated endpoint, and some useful information can be marked near the endpoint. Point out the different situations of association (described later). The whole association can also carry some additional information, including: the name of the association, indicating the role of the association; Association class symbols are the same as ordinary class symbols, but they must be attached to an association to indicate the attributes and operations of the association. These things are optional, not mandatory.
AssociationEnd: The association end is not an independent element, but a part of the association, which is used to show some details of the association. Some details are expressed by attaching some characters or graphics next to Lenovo. Include diversity, ordering, qualifiers, role names, variability and visibility. Other details are represented by different shapes of the end points of the association line, including: hollow arrows indicate navigability, indicating that an object instance at one end of the association can be found. The hollow diamond arrow indicates aggregation, indicating that the object instance at one end of the association is a component of the object instance at the other end; The solid diamond arrow indicates a strong aggregation form, which is called combination.
Multiplicity: mark a number (representing a specific number) or an * sign (representing multiple) on the associated endpoint to indicate how many object instances are associated with the object instances at the other end.
Qualifier, draw a rectangular box where one end of the association interfaces with the class symbol, and give some attribute values in the box to indicate what conditions the object at the other end of the association meets before it can be associated with the object at this end. It is part of the association, not part of the class.
Association class is used to indicate that an association has the characteristics of class (including attributes and operations), which is represented by ordinary class symbols and attached to the association line.
N-ary association, the association between more than three classes, is represented by drawing a line from the diamond to each related class symbol.
According to UML, combination is one of the forms of aggregation, which means that the whole has a strong relationship with parts and has the same survival time. Its performance is to add a solid diamond arrow at the end of the association line.
A Link is an instance of association, which represents the connection between two objects. Its performance is to draw a straight line between two object instances.
Generalization: "It is a taxonomic relationship between a more general element and a more specific element that is completely consistent with it, adding more information." This concept is basically the same as the "inheritance relationship" or "general special relationship" mentioned in most OO technical documents. However, the generalization of UML is not only used to express the relationship between classes, but also used for elements such as packages and use cases. There are two ways to express it. One is the * * * enjoyment method, in which a triangle is drawn next to the symbol of a general element and a connecting line is drawn from the bottom of the triangle. This connecting line has several branches, which are connected to each special element respectively; The other is decentralized, drawing multiple triangles next to the symbols of general elements, and drawing a line at the bottom of each triangle leads to a special element. You can add a text label named discriminator next to the line to indicate what is confidential.
Dependency: UML defines dependency semantically as follows: "Point out the semantic relationship between two (or more) model elements. Its meaning only involves these elements themselves, not their instances. It indicates that changes to the target element in the dependency may require changes to the source element. There are the following dependencies:
Trace-trace: the historical connection between two elements representing the same concept at different ideographic levels.
Refinement-Refinement: A historical or derived connection between two elements with a mapping (not necessarily complete) relationship.
Usage-Usage: The correct realization or functional expression of one element needs another element.
Bind-Binding: Bind template parameters to actual values to create nonparametric elements.
The representation of dependency is to draw a dotted line with arrows between two model elements, next to the dependency, or add a name. The UML Symbol Guide does not talk about the relationship and difference between dependency and message concept when introducing it. UML concepts such as "message" and "message flow" are used for sequence diagram and collaborative drawing respectively (see later). However, M.Fowler explained in reference [4]: "For a class, the existence of dependency may be due to the following reasons: one class sends messages to other classes; One class takes other classes as part of its data; One class refers to other classes as parameters of the operation.
Derived elements: Derived elements are elements that can be calculated from other elements. Although semantic information is not added, it can be clearer or more conducive to design. It is represented by adding a slash "/"before the name of the derived element.
(2) Use case diagram
"Use-case diagrams are used to express the relationship between participants and use cases." "Use-case models express the functions of a system or class to those outside the system." UML defines the following elements that make up a use-case diagram (as shown in Figure 3).
Figure 3 Use case diagram
Use case: A use case is a compact functional unit provided by a system or class, which is embodied by the message sequence exchanged between the system and one or more external interactors (i.e. activists) and the activities performed by the system.
Participant: A participant is a role played by an external object that directly interacts with the system.
The use case relationship includes the following three relationships: communication is the only relationship between the actor and the use case, and it is the actor's participation in the use case; Extension, the extended relationship from use case A to use case B indicates that the instance of B (under the special conditions of extended description) may contain the behavior described in A; Usage: The usage relationship from A to B shows that the example of A also includes the behavior described in B. 。
(3) Sequence diagram
UML gives two forms of interaction diagrams, one is called sequence diagram, and the other is called collaboration diagram. They are based on the same basic information, but emphasize different aspects. The sequence diagram shows the interactions in chronological order. In particular, it shows the interactions that objects participate in on their lifelines and the messages they exchange in chronological order. It does not show the relationships between objects. The interaction represented by sequence diagram is a set of messages exchanged when objects cooperate to produce the required operation or result. There are two ways to draw sequence diagrams: simple form and detailed form. The latter drawing method is basically consistent with the interaction diagram introduced by OOSE [3] and other works-horizontally and vertically showing the objects participating in the interaction. The whole plane shows the spatio-temporal relationship between objects, and the sequence diagram is shown in Figure 4. The modeling elements used for sequence diagrams are:
Fig. 4 sequence diagram
Object Lifeline: A vertical dotted line that shows the role an object plays in the time range from creation to revocation.
Activation: displays the time period during which the object performs activities directly or through its subordinate processes.
Message: A message is a communication between objects, which is used to convey information and expect some activity. The receipt of a message is an event.
Transmission time: the time required to send or receive a message. They can be the same or different.
(4) Collaboration diagram
Collaboration diagram is another kind of interaction diagram mentioned by UML, which represents the operations organized between some objects and the links between them. Different from sequence diagram, collaboration diagram represents the relationship between object roles, not the time sequence. A collaboration diagram describes the collaboration between a group of related objects in a specific context. And a set of messages exchanged when the set of objects cooperate to produce the required operation or result. The graphic representation of collaboration diagram takes objects as nodes, including arrow lines representing messages and connecting lines representing the association between nodes. There are three kinds of message lines, which represent three different messages, namely call, control flow and asynchrony, but there are still some situations that cannot be expressed, such as balking and time out. Some further extended symbols are needed. Related symbols used in collaboration diagrams also include many different endpoint situations, such as qualifiers and combinations. The collaboration diagram is shown in Figure 5.
Fig. 5 Collaboration diagram
The concepts or modeling elements defined by UML symbol guide for collaboration diagrams include collaboration, collaboration content, interaction, schema structure, collaboration roles, multi-objects, active objects, message flow and create/destroy tags, which are not introduced here.
(5) State diagram
State diagram is also called state machine in UML. It represents the state sequence of an object or an interaction when it is stimulated throughout its life, as well as its reactions and activities. It is attached to a class or method. The modeling elements used to build the state diagram include: state, compound state, Substate, Event, Simple Transition, Complex Transition, Nested State, Sending Message, internal transition, etc. The representation of state diagram and its related elements is similar to most existing OOA/OOD methods, so I will not repeat them here.
(6) Activity diagram
Activity diagram is a variant of state diagram. Its state indicates the activity of operation execution, and its transition is triggered by the completion of operation. It represents the state machine of the process itself. A process is the implementation of an operation in a class. The elements that make up the activity diagram are: action state, decision, swimming lane (swimming lane is drawn in the diagram like a swimming pool, and each activity group is placed in a different swimming lane to make it clearer), action-object flow relationship (activity-object flow relationship, indicating the message and input/output relationship between an activity and related objects), control icon (indicating the sending and receiving of signals) and so on. The activity diagram is shown in Figure 6.
Figure 6 Activity diagram
(7) Implementation diagram
The implementation diagram shows the implementation problems, including source code structure and runtime implementation structure. There are two kinds of implementation diagrams, one is the component diagram showing the code structure, and the other is the extended diagram showing the runtime system structure.
Component diagram shows the dependencies among software components such as source code, binary code and executable code. /ca & gt；