Thinking in UML notes-2. Modeling Basics

Modeling Basics

Modeling

Modeling(Modeling)It refers to the establishment of an abstract method of objective things to characterize things and gain an understanding of the things themselves. At the same time, this understanding is conceptual and these logical concepts are organized, an easy-to-understand expression of the internal structure and working principle.

 

Note: It is actually to test the image extraction capability.

 

Modeling Method

 

Case-driven

Case-driven is an important concept of a unified process, or the entire software production process is case-driven. It makes sense to use cases to drive the software production process. Let's review the modeling formula and draw an inference easily. To solve the problem, we need to summarize all necessary abstract angles.(Use Cases)Describes possible specific scenarios for these cases, and finds the things, rules, and actions that implement these scenarios..In another way, if the things, rules, and actions we find implement all the necessary use cases, the problem field will be resolved. In short, the implementation of use cases is necessary. Once the use cases are implemented, the problem field is resolved. This is the principle of the case-driven method.

 

In actual software projects, the functions to be implemented by a software are captured through use cases. All subsequent analyses, designs, implementations, and tests are driven by use cases, that is, to achieve the use case as the goal. In a unified process, a use case is an analysis unit, Design Unit, Development Unit, test unit, or even deployment unit. In the Unified Process, the use case can drive not only the analysis and design, but also the use case driving view. It comes from the Unified Process.

 

· Logical view: the system has only one logical view. This view graphically describes key Use Case implementations, subsystems, packages, and classes. They contain significant behavior in the architecture, that is, " Person " , " Things " , " Things " , " Rules " And how the organization is classified.

· Process view: to facilitate understanding of the process organization of the system " Analysis Design " A workflow uses a framework view named process view. The system has only one process view. It graphically describes the detailed organizational structure of processes in the system, including the ing between classes and subsystems to processes and threads, that is, those in the modeling Formula " Person " , " Things " , " Things " , " Rules " How they interact and their relationships. This view is what we often call an analysis design view.

· Deployment view: the system has only one deployment view. It graphically describes the distribution of processing activities among nodes in the system, including the physical distribution of processes and threads, that is, " Person " , " Things " , " Things " , " Rules " Is how to deploy on a physical node ( Host and Network Environment ) .

·Implementation view: the Implementation view is used to obtain the architectural decisions for implementation. The implementation view usually includes the following content::

·Lists All subsystems in the implementation model.

·A component diagram that describes how subsystems are organized into hierarchies and hierarchies.

·Describes the import dependencies between subsystems.

The implementation view is used:

·Assign implementation work to individuals, teams, or subcontractors.

·Estimate the objects to be developed, modified, or deletedCodeQuantity.

·Clarify the reasons for large-scale reuse.

·Consider release policies.

 

Abstraction Level

Abstract layers are very important but difficult to master in object-oriented methods. Learning to stand at different abstract levels and consider the problem as the basis for building a good model. Therefore, I cannot help but say something that has nothing to do with technology."Nonsense".

 

First, the higher the abstraction level, the less specific information, but the stronger the generalization ability;On the contrary, the richer the information, the more definite the result, but the weaker the generalization ability. In terms of information expression ability, the higher the abstract level, the richer the expression ability, and the easier to understand. Some people may question this question, because in people's impressions, the more abstract things are, the more difficult it is to understand. The more specific things are, the easier it is to understand. Isn't it??

 

View

View for OrganizationUMLElement to express the meaning of a model. Accurate application of views is an important part of building a good model. The view application does not seem to be too complex, but in actual work, many people do not know where to apply the view, which view is applied, and which views are required by the Department.

 

Object Analysis Method

To useUML, Object-oriented ideas and methods are unavoidable. Good useUMLThe prerequisite is to master the object-oriented ideas and methods.

 

Everything is an object

In the eyes of object-oriented, all things with names are objects, and they should be viewed and analyzed from the perspective of objects. Even if this is a business process named XX, it should still be regarded as an object rather than a process. This means that things should be viewed and analyzed with some ideas and methods described later at any time.

 

Objects are independent.

Independence is a major feature of object-oriented, and this point of view is accepted when the object is recognized. Objects are naturally independent from each other. In a specific scenario, a specific instance of an object is associated with each other.

 

We often analyze a scenario to obtain and analyze objects, but we need to know that objects are discrete, and they do not exist because of this scenario. Objects in scenarios are only objects."Ing"In this scenario, we call it an object instance. In other words, through a scenario, we can only obtain one side of the object ,.

 

All objects are atomic.

At any time, the object should be regarded as an inseparable atom in the analysis process, even if the object is large. For example, when analyzing a business process(Granularity)As big as a bank, a factory, or a mall, no matter how huge it is, as long as we think it is an object, it is a whole and cannot be separated when interacting with other objects.

 

In the analysis process, an object always has a boundary and should never break the boundary to snoop into the object. In terms of image, objects look like eggs, and eggshells are the boundaries of objects. In the process of analyzing objects, all our understanding of it comes from the eggshell. If we were too curious to try to understand the world inside the shell and break the boundary impulsively, well, we did see that our curiosity was satisfied, but we soon regretted it. Because the eggs are damaged, it is difficult to clean up the sticky egg. A bad design is like a pile of broken eggs.

 

We should attach all the understandings of objects obtained in the analysis process to the object boundary, and ignore the internal details before implementing this object. This is called interface-oriented programming.

 

Objects are abstract.

Objects have many different aspects. Generally, when an object participates in a scenario, a certain aspect is displayed. A certain aspect of an object can always be abstracted and used as a representative of the object to participate in scenario interaction. This abstraction is usually named by an interface. In the analysis process, any specific object can be abstracted. Because the object is always obtained from the scenario analysis, it certainly shows an aspect in the scene.

 

The more aspects the object has, or the more scenarios the object participates in, the more abstract the object has, and the less abstract the object has. Therefore, in the analysis process, we should focus on the objects involved in many scenarios. They are often the key points in the analysis design and the key to success or failure.

 

Objects are hierarchical.

Objects have abstract layers. The higher the level, the more rough the description, but the wider the adaptability. The lower the level, the more accurate the description, but the lower the adaptability. In the analysis process, multiple abstract layers should be set based on the complexity of the problem field, and appropriate abstract level object descriptions should be used at each level..This will help significantly reduce the difficulty and workload of analysis.

 

Both the requirements, analysis, and design processes should have abstract perspectives. The process from requirement to design is already at several different abstraction layers. I would like to say that at one stage, such as the demand stage, we can still explain it by several abstraction layers. The specific number of abstraction layers depends on the complexity of the problem field.

 

Object analysis method summary

Independence, atomicity, abstraction, and hierarchy are some principles and methods that should be followed in Object-Oriented Analysis. In actual work, you need to consider several aspects. If this object is a key object, you should try to describe the content shown in the figure.