Chapter 1 nature and objectives of the Model This chapter explains what a model is, how it is used, and how to use it. This chapter also explains the different layers of the model: Ideal, partial, and tool-based.
2.1 What is Model
A model is an expression of similar or other tools using a certain tool. Models start from a modeling point of view and grasp the most important aspects of things to simplify or ignore other aspects. Models are used in engineering, construction, and many other fields that require creativity.
Tools that express models require ease of use. A building model can be a building drawing drawn from a drawing, a three-dimensional model made of thick cart, or a finite element equation stored in a computer. The structure model of a building not only shows the appearance of the building, but also can be used for engineering design and cost accounting.
Models of software systems are expressed in modeling languages, such as UML. The model contains semantic information and representation, which can take different forms, such as graphics and text. The purpose of creating a model is to make it easier and more convenient to use a model than to manipulate a physical object.
2.2 usage of the Model
The model has multiple functions.
1. capture precise and expressive project requirements and knowledge in the application field so that stakeholders can understand and reach an agreement
Various models of a building can accurately express the building's appearance, transportation, service facilities, wind resistance and seismic performance, consumption and other requirements. Stakeholders include architects, construction engineers, contractors, contractors, owners, tenants and municipal authorities.
Different models of the software system can capture information about the application fields, usage methods, test methods, and construction modes of the software. Stakeholders include software architects, system analysts, programmers, project managers, customers, investors, end users, and operators who use software. Various models should be used in UML.
2. design the system
Architects can use model diagrams drawn on drawings, models stored in computers, or actual 3D models to visualize their design results and use these models for design experiments. Building and modifying a small model is relatively simple, which allows designers to create and innovate without any cost.
Before writing program code, software system models can help software developers conveniently study various architectures and design schemes of software. Prior to detailed design, a good modeling language allows designers to have a comprehensive understanding of the software architecture.
3. Separate specific design details from requirements
A model of a building can show the appearance that meets the customer's requirements. Another type of model can describe the setting of electrical lines, pipelines and ventilation pipes inside a building. There are multiple solutions to implement these settings. The final building model must be the best design solution that architects think. Customers can check and verify the solution, but customers usually do not care about the specific design details, as long as they can meet their needs.
A type of software system model can indicate the external behavior of the system and the information related to the real world in the system, another type of model can display the classes in the system and the internal operations required to implement the system's external behavior characteristics. There are multiple methods to implement these actions. The model corresponding to the final design result must be the best one the designers think.
4. generate useful products
The building model can have a variety of related products, including the list of building materials, the Building Slope at various wind speeds, and the stress levels at each point in the building structure.
The software system model can be used to obtain the declaration, process body, user interface, database, legal use instructions, draft configuration, and comparison of competition with other organizations in technology.
5. Organize, search, filter, re-obtain, check, and edit information about large systems
Building models use service facilities to organize information: construction structures, electrical appliances, pipelines, ventilation facilities, decoration, and so on. Unless stored on a computer, it is not easy to find and modify the information. On the contrary, if the entire model and related information are stored in a computer, this work is very easy and can be easily studied for a variety of design schemes that share some public information.
The software system uses views to organize information: static structure view, state machine view, InterAction view, and view that reflects requirements. Each view maps a part of the information selected from the model for a specific purpose. Without the support of model management tools, you cannot make the model more precise. An interactive view editing tool can present information in different formats. It can hide and display unnecessary information for a specific purpose in the future, you can group operations, modify model elements, and modify a group of Model Elements with only one command.
6. Economically research solutions in various design processes
The advantages and disadvantages of different design schemes for the same building may be unclear at the beginning. For example, different sub-structures that can be used in a building may have complex mutual influences, and construction engineers may not be able to correctly evaluate these sub-structures. Before building a building, the model can be used to study multiple design schemes and estimate the costs and risks at the same time.
By studying the model of a large software system, multiple practical solutions can be proposed and compared. Of course, the model cannot be fine enough, but even a rough model can illustrate many problems to be solved in the final design. The model can be used to study multiple design schemes. The cost is only the cost of implementing one of them.
7. Use models to fully grasp Complex Systems
A tornado in an engineering model of a tornado attacking a building cannot be a tornado in the real world. It is just a model. A real Tornado is impossible to call, and it will destroy the measurement tool. Many fast and intense physical processes can now be studied and understood using this physical model.
A large software system may not be directly researched due to its complexity, but the model makes it possible. Without losing details, the model can be abstracted to a certain level for people to understand. You can use a computer to perform complex analysis on the model to identify possible "problem points", such as time errors and resource competition. Before making changes to the physical objects, we can use the model to study the dependencies between the components of the system to find out the possible impacts of such changes.
2.3 Model Hierarchy
For different purposes, the model can take various forms and different abstract layers. The amount of information contained in the model must correspond to the following purposes:
1. guiding design ideas
The high-level model established in the early stage of the project is used to focus on stakeholder ideas and emphasize some important options. These models describe the requirements of the system and represent the starting point of the system design. Early models help project initiators study possible project selection schemes before focusing on system details. As design progresses, early models are replaced by more precise models. There is no need to detail the various options and rework situations in the early research process. Early models aim to help you get ideas. However, the final "Train of Thought Model" should be recorded before detailed design. Early models do not need to be accurate in the implementation phase, and do not need to involve a set of concepts related to system implementation. This model only uses a subset of the components defined by UML, which is much less than the components used by the model in later stages of design.
When an early model develops to a complete view model with a certain degree of accuracy-for example, a model that analyzes system requirements-it should be saved when the development process enters the next stage. Incremental development that constantly adds information to the model (in this case, the development reasoning process should also be saved and recorded) there is an important difference between it and general loose development that studies "Dead ends" until the right solution is obtained. In the latter case, people do not know how to proceed, and there is no need to record the entire development process unless the development process needs to be traced back in special circumstances.
2. abstract description of the basic structure of the system
Models established in the analysis and preliminary design phases are centered on key concepts and various final system mechanisms. These models match the final system in some way. However, the detailed information is lost in the model and must be explicitly supplemented during the design process. Abstract models are used to correct common high-level system problems before handling local details. Through a careful development process, these models can be developed into the final model, which ensures that the final model can correctly implement the design intent of the initial model. You must have the tracking capability to track the process from the basic model to the complete model. Otherwise, it cannot be ensured that the final system correctly contains the key features to be expressed by the basic model. The basic model emphasizes semantics and does not need to involve system implementation details. Sometimes it is true that the difference in the lower-layer implementation will obscure the logical semantics. The path from the basic model to the final implementation model must be clear and concise, regardless of whether the process is automatically implemented by the code generator or manually implemented by the designer.
3. detailed specifications of the final system
The system implementation model contains sufficient information that can be used to build the system. It should not only include the logical meanings and syntaxes, algorithms, data structures of the system, but also ensure that the system functions can be correctly completed, it also includes the decisions made by the organization of system products, which are essential for individuals to collaborate with each other and to use auxiliary tools. This model must include components that package model elements for easy understanding and automatic processing by computers. This is not a feature of the target application system, but a feature of the system construction process.
4. Typical or possible system examples
Well-selected instances can improve people's observation capabilities and make the system description and actual results available. However, even if there are a lot of examples, there is no detailed definition of the effect. In the end, we hope that the model can be used to illustrate the general situation, which is also what the program code needs to do. However, examples of typical data structures, InterAction sequences, or object lifecycles are helpful for understanding complex systems. Be careful when using the example. Logically speaking, it is impossible to sum up the most common situations from a large number of special cases, however, most people always consider some carefully selected examples of a problem. The sample model only describes the model without a general description. Therefore, people may think there is a difference between the two models. The sample model generally only uses a subset of the components defined by UML. Both the descriptive model and the sample model are useful in modeling.
5. A comprehensive or partial description of the system
A model can completely describe an independent system without reference to external information. More often, models are organized by different and discontinuous descriptive units. Each unit can be stored and manipulated separately as part of the overall description. This model carries a part that must be associated with other models of the system. Because of their relevance and meaning, they can be combined with other parts to construct different systems. Obtaining reuse is an important goal of a good modeling method.
The model needs to develop and change over time. In-depth and refined models are derived from abstract models, and specific models are derived from logical models. For example, the model created in the initial stage is a high-level view of the entire system. As time went on, the model added some details and introduced some changes. As time goes on, the core focus of the model changes from a user-centric front-end logic view to an implementation-centric back-end physical view. With the development process and in-depth understanding of the system, we must repeatedly describe the model at various levels for a better understanding, it is impossible to understand a large system from a single perspective or linear process. There is no difference between "correct" and "wrong" for the model form.
2.4 model content
1. Semantics and representation
The model includes two main aspects: semantic information (semantics) and Visualized Expression (Representation ).
In terms of semantics, a set of logical components are used to express the meaning of an application system, such as classes, associations, States, use cases, and messages. Semantic model elements carry the meaning of the model, that is, they express the semantics. Semantic Modeling elements are used for code generation, validity verification, and complexity measurement. Their visual appearance is irrelevant to most tools that process models. Semantic information is usually called a model. A semantic model has a lexical structure, a set of highly formal rules, and a dynamic execution structure. These aspects are often described separately (that is, the document defining UML), but they are closely related and are part of the same model.
Visualized expressions display semantic information in the form of observation, browsing, and editing. The representation element carries the visual expression of the model, that is, the semantics is expressed in a way that can be directly understood by people. They do not add new semantics, but organize expressions in a useful way to emphasize the model examples. Therefore, they play a guiding role in understanding the model. The semantics of expression elements comes from semantic model elements. However, because a model graph is drawn by a person, the expression element is not entirely from the logical element of the model. The arrangement of expression elements may express another meaning of the semantic relationship. These semantic relations are not obvious or ambiguous, so that they cannot be formally expressed in the model, but can be enlightening.
2. Context
The model itself is a computer system product and is applied in a large context that gives the meaning of the model. This includes the internal organization of the model, comments to each model throughout the development process, a set of default values, assumptions for creating and manipulating the model, and the relationship between the model and its environment.
The model requires an internal organization that allows multiple working groups to use a model at the same time without too much mutual involvement. This decomposition of the model is not required in terms of semantics-compared with a model that is decomposed into multiple coherent packets, the information expressed by a model with a large single block structure may be equally accurate, because the determination of the boundary of the organizational unit may complicate the work of accurately defining semantics, therefore, the information displayed in a single block model may be more accurate than the packet structure model. However, it is impossible for multiple working groups on a large single block model to work effectively without mutual interference. Second, a single block model does not have reusable units suitable for other situations. Finally, some modifications to the big model often lead to unexpected consequences. If the model is properly decomposed into small subsystems with good interfaces, the consequences of modifications to a small and independent unit can be tracked and determined. In any case, decomposing a large system into a hierarchical organizational structure composed of carefully selected units is the most reliable method for designing a large system that has been invented for thousands of years.
The model captures the semantic information of an application system, but it also needs to record various information in the model development process, for example, the designers of a class, the debugging status of the process, and the usage permissions of various personnel. This information is at most the peripheral information of the system semantics, but it is very important for the development process. Therefore, the establishment of a system model must take two aspects into account. The easiest way to do this is to add project management information to the semantic model as a comment, which allows you to describe model elements in any way using non-modeling languages. In UML, text strings are used to represent comments.
The commands used by the text editor or browser are not part of the programming language. Similarly, the commands used to create and modify models are not part of the semantics of the modeling language. The attributes of model elements have no default values. In a specific model, they all have values. However, for the actual development process, it is required that you do not need to detail all relevant details when creating and modifying the model. The default value exists at the boundary of the modeling language and the modeling tool that supports this language. In the model creation commands used by modeling tools, they are the true default values, although they may surpass a single modeling tool and become the common language used by the modeling tool as the user expects.
Models are not built and used in isolation. They are part of the big environment where models are located, including modeling tools, modeling languages and language compilers, operating systems, computer network environments, and restrictions on specific system implementations. System information should include information about all aspects of the environment. Part of the system information should be stored in the model, even if the information is not semantic information, such as the Project Management comment (discussed above), code generation prompt, model packaging, editing tool default command settings. Other information should be stored separately, such as program source code and operating system configuration commands. Even the information in the model can be interpreted in different places, including the modeling language, modeling tool, code generator, compiler or command language. This book uses UML to explain the model itself. However, when implementing the physical implementation of the system, other resources used for interpretation are required. These resources are invisible to UML.
What does the model mean?
A model is a generator of potential system configurations. A system is its range or value. Configuring the system according to the model is an idealized situation. However, sometimes the conditions required by the model cannot be implemented in reality. The model also provides a general description of the meaning and structure of the system. This description is the scope or meaning of the model. A model always has a certain level of abstraction. It contains the most basic components in the system and ignores other content. For models, consider the following:
Abstract and specific.The model contains the basic components of the system and ignores other content. Which are the basic content and which are not the basic content need to be determined based on the purpose of modeling. This does not mean that the accuracy of the information contained in the model should be divided into two types: accuracy and inaccuracy. There may be a series of models with different expressions but gradually improved. The modeling language is not a programming language. The content expressed in the modeling language may be inaccurate because the redundant details are irrelevant to the modeling purpose. Models with different precision levels can be applied to each stage of the same project. The model requirements for programming coding must be related to the programming language. A typical scenario is to use a high-level, low-precision model in the early stages of analysis. With the deepening of the development process, the models used are becoming more and more detailed. The final model contains a lot of details and has high accuracy.
Description and implementation.A model can tell us "what to do" (description), or "how to implement a function-that is, how to do it ). Pay attention to distinguishing these two aspects during modeling. Before you spend a lot of time studying how to do this, it is important to analyze what the system is going to do correctly. An important aspect of modeling is the abstraction of specific implementation details. There may be a series of relationships between the description and implementation. The description at a level is the implementation at the previous level.
Description and example. The model is descriptive. The model describes instances. These instances are only used as examples in the model. Most instances only exist for a portion of the running time. Sometimes the running instance itself describes other things. We call these hybrid objects metamodel ). At a deeper level, we think that nothing is descriptive or instance-based. This view is not in line with the actual situation. Whether a thing is an instance or a description is not isolated. It is related to the observation angle. Most things can be viewed from multiple angles.
The change to be interpreted.There may be multiple interpretations of the model in a modeling language. You can define the semantic change point (semantic variation point)-Where there may be multiple interpretations-give each explanation a semantic change name to identify which interpretation is used. For example, users of the Smalltalk language should avoid multiple inheritance relationships in the system implementation model, because the Smalltalk language does not support multiple inheritance. Users of other programming languages may use multiple inheritance in the model. Semantic change points support various implementation processes |
