The Bottom Logic of Object Oriented Analysis and Design

Object oriented is the basic method for people to understand things

How do people know things

Before the appearance of object-oriented, there were process oriented analysis methods. Why was object-oriented proposed? The essential reason is that people find that the process oriented approach is not to analyze software in the way that people normally understand things. Then how do people know things? Yourdon mentioned in his book Object Oriented Analysis that human beings understand things according to the principles of taxonomy, which mainly includes three points: distinguishing objects and their attributes; Distinguish the whole object and its components; Formation and differentiation of different object classes.

Now we can recall whether our process of understanding things is very similar to the three points mentioned in taxonomy. When we see a thing, we will probably perceive its composition, shape and classification. Therefore, people know things from the perspective of objects, and then assign specific concepts to objects, such as apples, pears, cars and other concept names.

Two kinds of thinking of classification and stratification

The real world we are facing is very complex. An important way to deal with complex things is abstraction. Abstraction is embodied in two methods in the process of practical application: layering and classification. Classification is to classify different things into different groups. As we often hear, "birds of a feather flock together." There are two reasons for classification: one is the closeness of the relationship between things. It is not necessary to couple all things together; Another point is that people have limitations in mastering things. They can only master a few key points, such as 5-7 points, which are more than easy to forget.

Layering is to see things from different perspectives. Each layer has different concerns, which are caused by its own perspective. For example, we do not need to go deep into binary electrical signals to understand computers. Hierarchical characteristics are often encountered in software design, such as computer architecture, TCP 7-layer protocol, etc. Hierarchical characteristics have one feature: the more upward the more specific, the more downward the more abstract, and the more upward the content is more unstable, that is, easy to change.

Mapping from problem domain to solution space

We call the problem to be solved the problem domain, or problem space, and the solution space. As the things mentioned in the previous section have hierarchical characteristics, different people understand things from their own perspectives, so everyone's understanding and communication are not consistent. If we see that the problem space is superficial, the scheme designed based on shallow understanding will be unstable, and a small change may cause the scheme to be redesigned next time.

We can divide a software into three layers: scenario, function, and entity. The scenario layer often changes. For example, there are a lot of scenarios for issuing coupons, such as dropping red packets to get discounts, sharing gifts to get coupons, and registering new people to get coupons. This scenario changes very quickly with business adjustments, so the scenario layer is unstable. The function supports a certain set of scenarios. Compared with scenarios, the function is relatively stable. Like the aforementioned coupon issuing scenario, the essence is to issue coupons to users. You only need to provide the coupon issuing function. It does not matter which scenarios are called, but the function is abstracted based on the set of scenarios. If the scenario type changes, the function will change accordingly, For example, secured transactions are different from pre-sale transactions. The entity is stable. Take the guarantee transaction and the pre-sale transaction for example, its order model is roughly the same, but some new information is added.

Therefore, we hope that from the problem space to the solution space, what you see and understand is consistent, and what you see is the essence of the problem rather than the appearance. Often, the scene and function are unstable, and the process oriented is function driven. Therefore, in the changeable scene, it faces many problems. The more stable is the entity object in the problem space, so object-oriented analysis is a practical need. Process oriented and object oriented are two analysis methods from different perspectives: process oriented is an inductive analysis method, a process from outside to inside; Object oriented is a deductive analysis method, a process from inside to outside.

Three consistency

Software development will go through the main stages of analysis, outline design, detailed design, coding, testing, and online. We do not want each part to be fragmented. For example, after the analysis is completed, the design phase needs to do the analysis again. Then there are consistency issues involved, that is, the consistency between requirements and analysis, the consistency between analysis and design, and the consistency between design and coding. The benefits of this approach can ensure that there is no information distortion. Therefore, we urgently need an analysis and design method to do this, and object-oriented analysis and design can do it. Therefore, the whole process is to take objects as the goal of analysis and design, and they are also objects in the final coding.

Object oriented underlying logic

When it comes to object orientation, some people will mention encapsulation, inheritance, polymorphism and other characteristics. These are not the essential characteristics of object orientation, such as encapsulation. There is encapsulation in the process of object orientation, and polymorphism is also reflected in the process of object orientation. These characteristics are not unique to object orientation. Object oriented underlying logic is an abstract mapping based on real things: real things correspond to objects in software. We discuss that the solution space can correspond to objects in the problem space. The two are directly mapped one by one. Other analysis methods are the mapping between the problem space and the solution space.

Panorama of Object Oriented Analysis and Design

What are the problems we face

From the top level, we need to complete the work from demand to coding. However, from demand to coding, there will be many stages, such as demand analysis, scheme design, etc. From a large level, we mainly encounter three problems:

1. What to do

It seems that this is a simple question, but in a complex business scenario, the understanding of what to do is too important, because different people have different understanding of the needs. For example, in a recent project, there is a business judgment rule that only taxes cross-border orders. The initial development students' understanding is to judge whether the type of seller is cross-border seller. However, when it comes to the testing stage, It is found that the judgment and understanding of this business rule are inconsistent. Cross border orders have no relationship with the seller type. The real cross-border order tax scenario is that the shipTo and shipFrom country addresses are different. In a large project, the collaboration between multiple teams is involved, and this problem is extremely prominent. Moreover, from business demands to product requirements, to technical solutions, there have been two transformations. Each transformation has different roles, and everyone's understanding will be different.

2. How to do it

When it comes to the specific way to do things, people often don't have big problems. How to do things is more specific in the implementation stage. Programmers often have little problems with logical rigor. The problem is usually the first problem, which is equivalent to a wrong direction, and the work they do is useless.

3. Problems of method guidance

We often hope to get a universal method that can deal with all problems without effort, but at the same time, we look down on low-level methods. For example, most people scoff at the use case analysis method and want to reflect the method with high technical level. In fact, since the 1970s and 1980s, the software analysis and design method has not changed much, and we have learned it in college, but we do not think it is a lofty method.

Process from analysis to design

In this section, we deduce the process from software analysis to design, from coarse to fine, and finally implement the UML knowledge we have contacted. There are two key issues from requirements to coding implementation: one is to define the goal, that is, to define clearly what to do, which is equivalent to the direction and goal of our work; The second is how to do it, that is, how to support the realization of demand objectives through specific programs. Therefore, we need a method that can help us define goals and express specific plans, and is a universal method for mutual recognition.

Use case diagrams can help us define goals. There are three key elements in use cases: users, scenarios, and goals. For example, the transaction order is a use case. Its user is the buyer. The scenario includes two scenarios: successful and unsuccessful orders. The goal of the use case is that the buyer can buy the desired goods. When the use case goal is determined, it is equivalent to defining the goal and knowing what needs to be done. This process should be confirmed with the business side repeatedly until everyone has the same understanding of the goal, the direction is right, and the specific way to do it is easy.

How to use time sequence diagram to express the specific way? One thing to pay attention to when drawing time sequence diagram is that the object hierarchy at the top level should be consistent. Some objects cannot represent specific entity objects. Some objects represent system objects, that is, the object hierarchy is consistent. Either everyone is a system, such as the shopping guide system calls the trading system, the trading system calls the payment system, or everyone is an object, such as goods, orders, etc. Through the sequence diagram, you can see the execution steps of a complete function, which contains the details of specific execution, such as normal flow and abnormal flow.

In fact, there is a problem above. When drawing a sequence diagram, you should determine the object. How did the object come from? It is analyzed by the robustness graph. There are three key objects in it: one is the boundary object, which is easy to understand. For example, the UI interface is the boundary object; The other is the control object, that is, the object that controls the business process. The following single service can be regarded as the control object:; Entity objects are business objects in the problem space, such as orders. There are rules for drawing robustness diagrams. Generally, boundary objects call control objects, and control objects generate entity objects. For example, the user order interface is a boundary object, the order service is a control object, and the order is an entity object.

The Way to Find Objects

Where does the object come from

As mentioned in the third section of the first part of this article, the problem space is mapped to the solution space one by one. When we discuss the objects in the solution space, they are actually mapped to the objects in the problem space, while the objects in the problem space mainly come from business concepts, business rules, and key events. Most of the objects are visible. We can find that some objects are hidden by understanding the business. We need to continue to have a deeper understanding of the business to discover them. A good object model needs to be polished several times, and it is not perfect once.

Methods for discovering objects

The method of finding objects has been mentioned in the second section of the second part of this article, but it is only the key object. In this section, the method of complete object discovery is mainly described. The main method is divided into four steps:

1. Find key entity objects through robustness graph;

2. Find out more solid objects through structural analysis;

3. Constitute the object into an organic object model;

4. Finally, check whether the object model is complete through use cases.

Here is a case to illustrate the process of object discovery. The case is that the user displays the tax amount on the order when placing an order. First, draw a robustness diagram. The boundary object here is the order interface. There are two control objects, one is the order service, the other is the tax service, and there are two entity objects, one is the tax bill, and the other is the order. With the two entity objects of tax document and order, we can analyze more objects through the structural analysis method.

Objects have structures. As long as we master the structure of objects, we can basically master the general picture of objects. Therefore, we start from the structure of objects to analyze the internal structure of objects and the structure of object associations. In essence, we start from two dimensions: first, from our own perspective, we see what objects are included in our own interior, such as the main order contains sub orders; The other is to look at what objects are associated with you from an external perspective, such as tax receipts and orders. This method of finding objects is called structural analysis method, because the structure itself is an expression of the essence of things, for example, chemical molecular structure determines chemical phenomena.

In order to better express the structure of objects, my experience is to define objects from different dimensions, such as functional dimension, value dimension, purposeful dimension, structural dimension, etc. Here, we can define objects from the structural dimension. Taking the tax calculation document as an example, we can define it as follows: the tax calculation document is a document model that converts the order amount information into several target objects for tax calculation. From this definition, we can see that the tax calculation document is associated with the order. The other is that the tax calculation document contains several target objects. We can draw the object model of the tax calculation document.

After the object model is drawn, we will discuss business issues around this object model in the future. For example, what amount of the subject matter of the commodity should be involved in tax calculation and what is the calculation criteria of the tax amount. Here, we will experience the sentence "problem space directly maps to solution space one by one". The business demands are nothing more than what order expense items should be taxed, and what is the logic of tax calculation, It is possible to deduct the gold standard discount in this scenario. In another scenario, the gold standard discount does not need to be deducted. Based on the object model, we discuss the problem with the product and test students. Everyone looks at the problem from the same perspective, and the cost of communication and understanding will be much less.

Object model is a kind of visual expression. Most of our communication problems are caused by the lack of explicit expression. This sentence can be understood in this way or that way, leading to misunderstanding. Now we communicate problems in the form of model, and many deviations and ambiguities will be eliminated.

Organization Object Structure

After we analyze a bunch of objects, we need to go through a certain organization. As mentioned earlier, people have limited understanding of things, and can't accept too many things at once. Therefore, we can divide them into small domains, such as commodity domain, order domain, tax domain, etc. When we aggregate a problem, we can only look at the object model in a certain sub domain.

How to assign responsibilities

How did the responsibility come about

There are two most difficult points of object-oriented: one is to find objects; The other is to assign responsibilities. UML defines responsibilities as "contracts or obligations of class elements", so the division of responsibilities is essentially determined by the class elements themselves, such as orders, which provide the obligations of order rendering, order creation, order modification, and order query.

Responsibilities are divided into two categories: cognitive responsibilities; The other is behavioral responsibility.

• Cognitive responsibilities include:
• Knowledge of private data encapsulation.
• Cognition of relevant objects.
• Knowledge of things that can be derived or calculated.

• Behavior responsibilities include:
• Self executing behavior, including creating objects or calculations.
• The action of initializing other objects.
• Control or coordinate activities of other objects.

Logic of assigning responsibilities

There are two types of duties mentioned in the previous section. Cognitive duties refer to the cognitive scope of the object itself, that is, it can only complete the corresponding duties based on its own attributes. For example, if an order with one master and multiple children needs to calculate the total order amount, how to allocate duties? First of all, a commodity can only find its own price information. Its understanding is based on the commodity price attribute. A sub order can have multiple commodities, so it can only calculate the amount information of the sub order. Its understanding is based on the item and quantity attributes. The main order contains the information of all sub orders, so the total order amount can be calculated.

From the above examples, we can see that cognitive responsibility is based on object attributes. As the saying goes, "not in its place, not in its politics", cognitive responsibility must not exceed its cognitive scope.

Behavioral duties are domain specific services. Sometimes a duty does not belong to a certain object, such as transfer, which is an act. It is inappropriate for other duties to be undertaken. Such behavioral duties are often a significant business activity, such as order rendering and order creation, which are behavioral duties rather than cognitive duties.

The assignment of duties must follow the "information expert" model, which means that the duties are assigned to those with the information needed to complete the duties, that is, the above mentioned knowledge generated duties.

Verify the rationality of responsibility allocation

We expect the assigned responsibilities to meet the requirements of "high cohesion and low coupling". How to test? Let's go back and think about the definition of responsibility: the contract or obligation of a class element. In other words, responsibility is called by other objects, which is consistent with the purpose of drawing a sequence diagram. Every call means that other objects need to provide a responsibility. Therefore, we can see the call frequency between objects in the sequence diagram. If an object is called very frequently, It is possible that this object has undertaken too many responsibilities. Can we split it and assign some of the responsibilities. Therefore, the assignment of object responsibilities is not achieved overnight, and needs to be constantly reviewed and tested.

The assignment of responsibilities should follow certain principles, such as the creator model, the information expert model, and the pure fiction model. These principles will be discussed separately in the next article.

case

Case background

Here is an example to illustrate the differences between process oriented and object oriented analysis and code writing. To calculate taxes, you need to judge whether the tax rules are met, such as virtual goods are not taxed (mobile phone recharge, etc.), some tax-free addresses are not taxed, and small B buyers are not taxed. Therefore, you need to provide a tax filtering judgment logic.

General process oriented implementation

The process oriented idea is very simple. A filtering method is provided to process the following logic in turn: filtering the tax calculation request of virtual goods, filtering the tax calculation request of tax-free addresses, and filtering the tax calculation request of small B buyers.

Object oriented implementation

Process oriented is to analyze problems from the perspective of process or function, while object oriented is to analyze problems from the perspective of object. Filtering tax requests is a tax filter that judges whether tax requests meet tax rules. There are two objects: tax filters and tax rules. The responsibility of judging whether tax requirements are met should be in the specific tax rule processor, such as whether it is a small B buyer, So we can draw the object model.

summary

It is mentioned in the article that the underlying logic of object-oriented is an abstract mapping based on real things. What is important is not the use of specific object-oriented technologies, but the thinking of analyzing problems. This is the most difficult. Its biggest advantage is that the problem space is mapped to the solution space continuously. Please note that it is a direct mapping one by one, which means that we can map to the problem space completely when discussing solutions, If it is an indirect mapping, it means that the design scheme will face the possibility of redesign later, because it is an inductive design based on the scene or function, and it is a surface design. I have really mastered the methods of object-oriented analysis and design, and realized the benefits, which are beneficial to understanding business, scheme design, and coding development.