12.1 Overview
The UML model is used in the environment. Most people use modeling techniques to achieve a purpose, that is, for the development of excellent performance, not to use the model itself. The purpose of the model and the interpretation of the model are also affected by factors outside the environment. In a broad external environment, other tools include: Metatrios, model editing tools, programming languages, operating systems, and main system components, and commercial and engineering backgrounds that use systems. Determining the meaning and use of the model depends on all of these tools, including the UML language.
The model appears in different specific hierarchies. UML is a universal modeling language, including semantics and representations, suitable for different tools and implementations. Each level in the application needs to use different levels of UML modeling ideas.
12.2 Semantic responsibilities
The meta model is a description of the model. Modeling language description model, therefore, it can be described by the element model. The meta-model attempts to define the language accurate language, but it must be extended to adapt to the new situation. The actual form of the meta model is important for the interchange of models and models with tools, but most users don't care about it. Therefore, we did not involve it in this book. Readers who are interested in this can refer to the original standard document [UML-98] on the supporting CD [UML-98].
The metamodes and languages must be able to cover how much background information and have strong explanation. The existing system has different implementation and storage models, which is impossible to select a correct explanation. In fact, even considering such choices may generate misleading. We can explain the different interpretations of the execution model as a semantic change point. Semantic change points is a different point of semantics, but it has nothing to do with other aspects of the system. For example, an environment can choose or do not choose to support dynamic categories, that is, the object has the ability to change the class at runtime. Now, many programming languages are not allowed to do this, mainly because of the realization of programming languages, but some languages have implemented this feature. This difference cannot be identified in static semantics. Select Static Classification or Dynamic Classification You can use a semantic change point with two options (static classification or dynamic classification). When these choices exist, people often debate which is the correct explanation. Instead, if this is just a choice, it will give an option, so any one can be used.
The meta model describes the content of a good structure, just as a programming language describes a good structure. Only structural models are meaningful and properly semantically; inquiring the meaning of a poor model. However, the structure of models in most developments is imperfect. They are incomplete and likely to contradict each other. But model editing tools must support incomplete models, not only to support complete models. The UML meta model describes the correct, structure and complete model. Separated meta models describe possible model fragments. We let tool developers decide which to delineate the boundaries of supporting model fragments and how to support models that support structural imperfect models.
UML contains some built-in extended mechanisms to accommodate applications in special fields. These mechanisms include the ability to define structural and labeling values. These mechanisms can be used to scroll UML variants by defining a set of structural types and tag values. For example, a UML variant language that can be developed in different programming languages can be developed. The use of expansion mechanisms will be very effective, but it will also bring potential dangers. Because these semantics are not defined in UML, UML does not support their meaning, which depends on the modeling. Also, if you don't pay attention, certain meanings may be unsatisfactory or even contradictory. Modeling tools can automatically support constructor and tag values defined by the tool, but do not support user-defined extensions. No matter whether it supports expansion, any extended use will cause the user to define the standard definitions of the language standards and harm the interchangeability of the model and easy to understand. Of course, use special class libraries will also deviate from the most perfect interchangeability, so don't worry. Use when it is helpful, but avoids using it if the extension is unnecessaries.
12.3 Indications
The representation is not to increase the meaning of the model, but to help users understand the meaning of the model. The representation has no semantics, but it often adds some internal intents to users, such as close contact with two concepts based on similar significance in a picture. UML document [UML-98] and this book define a set of specifications of UML representations, can be called a model format. This is similar to many programming languages, printing procedures in the journal article into attractive format, including careful planning, represented by black body, and each process is illustrated in different graphics. The actual compiler has to accept more messy inputs. We expect editing tools to extend the representation into screen formats, including the ability to use different fonts and color bright entries, simply delete and filter the capabilities of the entries that do not need to be used, enlarge the image to display nested elements in the figure. The ability to transfer other models and views through hypertext hot chains, as well as animation functions. It is impossible to try all these possible projects, but also stupid, because there is no need, and this will restrict beneficial innovation. This expansion ability of this representation is the work of tool manufacturers. In the interactive tool, the danger of generating an unity is small because the user can always find a clear explanation. This may be more useful than adhering to a rough looks more useful. This point is to say: When needed, a tool must generate a standardized representation, especially in the print format, but a reasonable extension should also be adopted in the interactive tool.
We still expect tools to make users limit but effectively expand the representation. We have specified that the configuration can have its own icon. The extension of other representations is also allowed, but users should use these expansion mechanisms.
Note that the representation is not just a picture, but it also includes an ultra-linked hyperlink based on the information of the text format and an element.
12.4 Program Language Responsibilities
UML must be used in common with them without having to be clarified with different languages. We believe that UML should allow any programming language (at least most), including specification and target code generation. The problem is that there are many semantics we don't want to absorb UML, because they have a considerable change as a programming language, because they have considerable changes in the execution semantic. For example, concurrent semantics There are different processing methods in different languages (if these semantics can be processed).
The simple data type is not described in detail in UML, which is well thought out because we don't want to combine the semantics of our favorite programming language to all other languages. This is not a problem for most modeling purposes. The semantic model suitable for your target language should be used. This is an example of a semantic change point.
Detailed language implementation characteristics make it a problem that captures its information without bringing the semantics of the realization characteristics to UML. Our approach is to capture language features that transcend UML built-in capabilities through a structural type and tag value, which can be assigned to language gain and code generation options by tools or code generators. The general editor does not need to understand them. In fact, users can create a model with a tool that does not support the target language, and then convert the final model to tools suitable for the final processing. Of course, if the tool does not understand the structure and labeling value, it cannot be checked. But this is not more than the text editor and compiler. If necessary, create a tool to use a set of specific extensions in the UML language.
In a presence, code generation and reverse conversion require not only the UML model, but also requires input information of the designer. The guidance and prompt required by the code generator can be provided by the tag value and the constructor. For example, the modeling can specify which packet container class for implementing an association. Of course, the code generation setting method in this tool may be contradictory, but there is currently no standardized actual setting method. At present, different tools use code generators that have competitive advantage, but will eventually have default settings and develop as mature standards.
12.5 Modeling Using Modeling Tools
In the actual system, the model requires tool support, and the tool provides the interaction of observation and editing models. The tool provides an organization that exceeds the UML own scope to help users understand and obtain information. Tools help find information in large models by searching and filtering. 12.5.1 Tools
Physical organization and storage of tool processing models. It must support a number of workgroups of a project to work at the same time, and support reuse across multiple projects. The following issues beyond the role of the specified UML, but must be considered in the use of practical tools.
* Embiguity and unreportable information in the initial stage, many things cannot be expressed in language. Tools must be able to adjust the accuracy of the model and cannot force each value to be described in detail. You can see the following two sections.
* Represents options users don't want to see all information at any time. Tools must be able to filter and hide information that you don't need for a certain time. The tool also provides alternating visual support through the functionality of the monitor hardware. This is already in 12.3.
* Model management model unit configuration control, access control, and version exceed the UML scope, but they are very important for software engineering, and are located on the upper layer of the metamodity.
* Interface models with other tools need to be processed by code generators, specifications computers, report writing writers, execution engines, and other background tools. The information required for other tools should be included in the model, but this is not UML information. The tag value is suitable for saving this information.
12.5.2 inconsistencies generated during work progress
The final goal of modeling is to generate a system description of the level of refinement. The final model must meet different effectiveness constraints. However, as many creative processes, the results do not have to be generated in linear ways, and intermediate products do not have to meet all validity constraints. In fact, a tool not only handles a model that satisfies validity constraints in semantics, but also processes the model on syntax, which meets a certain constructor but may violate some validity constraints. A model inactive in semantics cannot be used directly. Instead, they can be seen as a work in progress to the ultimate goal.
12.5.3 Null value and unrecorded value
A complete model contains all attribute values for all of its elements. In many cases, the null value (no value) is a possible value, whether a value may be empty is part of the attribute type description. For example, there is no meaning for null value on the upper limit of the set size. Some sets have a fixed size, and some do not have a fixed upper limit. In this case, the size of the collection is unlimited, so if the null value does not actually depend on the possible value of a data type. .
On the other hand, in the early days, developers may not not pay attention to the value of special characteristics. At a specific stage, this value may have no meaning, such as establishing the visibility of the field model. Alternatively, this value has a meaning but the modeling has not detailed it, and the developer should remember that it still needs to be refined. In this case, this value is not described in detail, indicating that a value is ultimately desirable but is not described in detail. It is different from null values, and null values are legal values in the final model. In many cases, especially in the string, null value is a good way to represent a value that is not detailed, but not all. The value that is not detailed in detail is meaningless in the form of a well-structured model, and the UML definition does not process the value that does not have a detailed description. This is a tool for supporting UML
