The things that analyze models: job-driven design

Before we talk about why we use analytic models, we now look at the basic principles of the design analysis model.

Assign responsibilities and responsibilities to drive design

When we begin to analyze the model, we must first understand a very important principle, that is, the responsibility of the center. One of the core principles of OO analysis design, is that all elements of a software system must have a highly relevant responsibility, that is, all modules, packages, object classes in the software system should have a clear responsibility and all the elements associated with it (that is, all the packages in the module, all the object classes in the package, All properties and behaviors in an object class must be highly correlated with this responsibility. Therefore, the primary design principle of the analysis model is the responsibility-driven design (responsibility-drive). According to the principle of responsibility-driven design, when we analyze the system, we must define a clear responsibility for each module, package, object class, especially object class. Under this principle, our core problem is that we define each object class by defining its responsibilities, which should be highly relevant to its responsibilities when defining its behavior and attributes.

How does the responsibility-driven design work? Master Craig Larman in his classic "UML and Pattern Application", proposed the GRASP software design pattern. GRASP (general responsibility Assignment Software Patterns), translated is the universal responsibility Assignment design pattern, which includes the creator (Creator), the controller (Controller), Information Specialists (information Expert), low coupling (lower coupling), high cohesion (high cohesion), polymorphic (polymorphism), pure fiction (Pure fabrication), Indirect (indirection) and prevention of mutation (Protected variations) nine parts. Grasp these nine parts, rather than the model, rather than the principle of more accurate. Now let's explore the four principles of low coupling, high cohesion, information specialists and founders.

1. Low coupling and high cohesion

These two words may be you already familiar with it, we are looking at Spring books, MVC data, design patterns of books, nowhere to mention "low coupling, cohesion well-structured classes poly", it has become a software design quality of one of the important standards. So, what is low coupling and what is high cohesion?

Coupling is a measure of the connection, perception, and dependence of an element with other elements. The elements described here can be functions, object classes, or systems, subsystems, and modules. If an element x is to connect element y, or you can perceive y by your own method, or when Y does not exist, then the element x is coupled to the element Y. So, what is coupling?

1. Element y is the attribute of element x, or element x references an instance of element Y (this includes a method called by element x with element y in its argument).

2. Element x invokes the method of element Y.

3. Element x is a subclass of element y, either directly or indirectly.

4. element x is the implementation of interface Y.

The problem with coupling is that when element y changes or does not exist, it will affect the normal work of element x, affecting the maintainability and ease of the system. At the same time, element X can only work in an environment where element y exists, which also reduces the reusability of element X. Because of the disadvantages of coupling, we strive to pursue "low coupling" in software design. Low coupling is the requirement that in our software system, an element should not be overly dependent on other elements. Please note the word "excessive" here. The low coupling in the system can not be excessive, for example, we design a class may not be coupled with the JDK, is this possible? Unless you're not designing a Java program. Again, for example, I've designed a class that doesn't have to be coupled to any class in my system. If there is such a class, then it is necessarily low cohesion. Coupling and cohesion is often a contradiction of the two aspects, the cohesion requirements of the class and the coupling between the class, too low coupling is bound to cause too low cohesion. The best solution is to find a suitable middle point. So, what is cohesion?

Cohesion, a more professional term called functional cohesion, is a software system element responsibility and concentration of the measurement of relevance. If the element has a highly related responsibility, in addition to the task within the scope of responsibility, there is no more work, then the element has high cohesion, and vice versa for low cohesion. High cohesion requires that the various elements in the software system have a high degree of collaboration, because it's possible to do all sorts of things when we're doing a function in software requirements, but with a high cohesion element that only completes what is within its purview, and asks others to do something that is not within its purview. It's like, if I were a project manager, my job was to monitor and coordinate my work at all stages of my project. When my project goes into the requirements analysis phase, I will ask the requirements analyst to complete it, and when my project is in the development phase, I will ask the software developer to complete ... If I did the development work during the development phase, I would not be a high cohesive element because the development work was not my responsibility.

High cohesion has essentially improved the readability, reusability and maintainability of software, so high cohesion has become a basic quality in software design. However, high cohesion requires that all elements of the software be fully collaborative, thus creating a sense of mutual interaction between elements. High cohesion and low coupling become a pair of contradictions, it requires us in the design process must look for the best middle point, not only to meet the high cohesion, but also a good low coupling.

2. Information experts

As we said earlier, the basic principle of our analysis and design system is responsibility-driven design, so what is the principle of responsibility distribution? The information expert model answers us. The information expert model, also known as the expert model, tells us that in OO analysis, responsibilities should be assigned to an object class in a software system that has the information necessary to implement this responsibility. We call this object class "information expert".

There are many functions in a software system, and each function is performed by a myriad of behaviors. And responsibility is a set of highly correlated behaviors. We aggregate the highly correlated behavior of a group of software systems into a single responsibility, and assign each responsibility to an information specialist who is responsible for this responsibility, both to achieve high cohesion and to achieve low coupling. Why do you say that? Assigning a highly correlated set of behaviors to an object class is itself a high cohesion. In order to accomplish a certain function, you must access the information that is required to achieve this responsibility. If this responsibility is not assigned to an information specialist, it is bound to result in a coupling of access to the information, and conversely, if the responsibility is assigned to an information specialist, the coupling of such access information disappears, thus reducing the coupling of the system.

The information experts express a simple truth, but in our project, the failure to follow the information experts model of the poor design can be seen everywhere, take a example I have experienced. I have been involved in the development of a company's internal review system. This system is divided into three use cases: the development of the review plan, the implementation of the review (the performance of the review in the software is to fill in the Review form), Production review report. In the formulation of the review plan, we need to fill in the contents of the review, the participation of the judges. At the time of performing the review, each judge needs to fill in the review form for all the contents of the review. According to the above requirements, in order to achieve the "implementation review" This use case, we will have to do "read the review content" and "read all the judges" these two behaviors. The question now is, who should these two acts be assigned to? With a little analysis we can find that the review content and the judges are part of the review program, so "read the review content" and "read all the judges" are the areas of responsibility for the read review program. As required by the information experts model, the review plan class has all the information about the review plan, so you should assign the Read review program responsibility to the review plan class, which reads review content and reads all judges as the review plan class behavior. However, the reality is not so.

The preparation of the review plan, the execution of the review and the Manufacturing review report were assigned to three programmers. To complete the "Execute review" task of the programmer A, in order to complete his function must perform "read review content" and "Read all judges" behavior, he should be completed "Review Program" Programmer B to implement these two actions, and for programmer a call. But, programmer B thinks oneself already very busy, why want to promise programmer a request? Because of this, programmer B does not implement the "read review content" and "Read all judges" behavior in the "Review plan" class, while programmer a can only implement these two behaviors in the "Review Table", which is to read the database directly according to the prior agreed logic. When programmer B modifies the business logic or table structure of the "review plan" because of a business change, the immediate result is that the "perform review" function cannot be performed. The underlying reason is that the "review table" class performs the work of the relevant information in the read review plan that is unrelated to its responsibilities, resulting in a business coupling with the review plan. Such problems are common in software development projects, and the solution should be that before programmers start programming, there should be an analyst to plan the entire system. With the analyst's plan, it is natural to assign "read review content" and "Read all judges" behavior to the "Review plan".

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

3. Who will create me

When we analyze the customer requirements and design the use case model, when we analyze the customer's business environment and create a domain model, when we synthesize the use case model, the domain model, and our ingenuity to design one class after another and their respective methods, when everything is ready for the wind, the key moment, An object sends a piercing roar-who will create me?!!! An object, no matter how powerful the function, no matter how ingenious the design, if can not be created, just as Han Xin can not be a general, bin can not be a military strategist, Gou can not return to the country, Liu Bei can not get Jingzhou, all the laureates Vullo are like waste paper. Now that "create" is so important to the object, let's take a good look at the problem with object creation in grasp.

Creating objects is one of the common activities in object-oriented systems, but creation is often accompanied by coupling. We should pursue low coupling, but we have to create objects. What do we do? The best way to do this is to get the classes that must be coupled to the created object to do the work. The creator model gives us the following recommendations:

If you want to assign responsibility for creating a to B, the following conditions should be met (the more the better):

L B contains or aggregates a

L B Record a

L B Call a

L B owns the initialization data for a, and is passed to a, i.e. B is an expert in the creation of a.

If more than one class satisfies the above criteria, a class that satisfies the condition 1 or 2 is preferred. As can be seen from the above conditions, even if B is not created a,b has been coupled with a, so B creates a, and does not improve the system's coupling, so is the best choice.

However, there are many exceptions in the software system that do not create objects in the creator mode. When creating an object, or the entire aggregation associated with it, its business logic becomes very complex, in order to not expose its internal structure too much to ensure the encapsulation of the system, it is possible to select the factory pattern to create objects. In this case, the complex assembly process of creating objects may be involved (the issue will continue to be discussed later). In another case, the service class object in the system, in order to improve the efficiency of the system to use a single example, to provide services to other objects. Object classes like these, we tend to use, are created by the system when the system starts, or when an object accesses them for the first time, for example, those beans in the spring framework.