Object-Oriented Analysis and Design-four-color prototype (color modeling, domain-independent model) (concept Edition)

Labels: UML, modeling, four-color prototype, color Modeling

Reading directory:

• 1. Background

• 2. Ask yourself, does UML make sense to you? Does it help you analyze and model the system?

• 3. We have been separated by a gap for a long time, making OOAD inaccessible.

• 4. The four-color prototype fills this gap in history, so that we can see the hope of OOAD.

• 5. Use color Modeling on four-color prototype to enhance visual impact

• 6. Create a domain-independent model using four-color prototype

• 7. Conclusion: you can skip the specific implementation during modeling, but the modeler must understand the technical implementation.

1. Background

So far, I have clearly remembered the first time I was asked by the interviewer about "modeling" technology. It was a few years ago, at that time, I went to the interview with an expert about system analysis and design. net Senior Software Engineer position. The interviewer asked me almost no technical implementation about. net. He simply asked: "How do you grasp the correctness of the system you have analyzed ?", I was a little excited at the time. I thought this question should be very simple. It was just a concept. I asked him to directly ask, and then he said, "Do you understand modeling ?, Can you explain the role of modeling to me? ", Then he came up with a small example. Let me model this example. To consider the key points of various scalability and business stability, we need to build a model while explaining why we need to build this model, you need to give your thoughts. He stressed: "The created model cannot be associated with any specific code or tool ".

In my opinion, what he means is that the created UML class diagram model is a domain-independent model (domain-specific model), which can be implemented using any programming technology, as a modeler, you don't need to consider these implementation details. The more you think about it, the more likely it will be to scatter the equivalent modeling of your real business. It is easy to make common mistakes for technicians (think about your business with technical thinking ).

At that time, I thought it was easy. I didn't just use UML to make a dot chart to make a show. It reflected the high-end Analysis and Design. What else can I do; in fact, the reason why I thought this was because I tried to learn, understand, and use UML and modeling. As a result, I found that this is a brilliant tool, and I did not care about it, there is even resistance to the field of "modeling" in software engineering.

At that time, I casually talked about some of my experiences when I was learning UML modeling. I thought this was the final answer, because it is indeed the role (""). then I used code-driven modeling to export the class diagrams of UML. The results were similar to what I expected. Basically, they covered several major aspects of this small example, anyway, the interviewer did not know how I got this UML class diagram. Only God knows that I first constructed the code model and then pushed it back to the class diagram model, what we say is totally different from the ideal.

I felt very good when I waited for the interviewer to ask the next question. The interviewer said that I missed something, saying that I did not fully consider the business scenario, did not clearly divide the key concepts in the business concept, or even neglected the entity attributes of very small fields, the software developed according to my model diagram cannot meet the current business requirements. I was blind at the time. What is a key concept? Which one is not a key concept? Where can I use it? I feel a little wronged and cannot understand it at the moment. I feel that the interviewer is bothering me.

In fact, I can now understand what the interviewer said at that time. He means that I cannot clearly express the responsibilities of each class. It seems that the roles played by each class are the same, it is nothing more than the attributes and methods. I failed to capture the concept of the core domain, did not stand in the domain to consider modeling, but stood in the code level from the bottom up, A lot of things cannot be clearly understood. To put it bluntly, can developers understand the fields they are going to face when they get this class chart? If they can understand it, the class graph model is healthy at this time, if you don't understand it, there is a problem, because the model diagram is not for yourself, but for the whole team to communicate and share.

Later, I adjusted my mood. Even if the interview failed, I had to make a summary. The interview was an abusive process. ("Buddha said: this is the time of practice." It is a good exercise .)

I humbly asked the interviewer where I had a problem with this model diagram. He pointed out that there may be blind analysis spots that I could not see in my life, he said that this problem is a common problem for programmers to use technical thinking to analyze modeling. Why can't he see these blind spots, but I can't? I really want to know the essence of this. I asked me to come here to study with a lower salary. The interviewer would like me to come over without a lower salary, he is also a person pursuing technology. However, after that, I failed to take office in your company due to special issues. I have been sorry for the fact that I may never understand the essence of modeling.

Now I can understand that if you use code-level analytical thinking to assist your modeling, there will be blind spots, because the code-level "design pattern ", the "design principle" is not the "Analysis Mode" in modeling. It is two different problem domains, that is, they are used in different business domains and cannot be generalized, cross-use will mislead your current focus, and you will add vinegar to it.

"Modeling" is a very abstract and sacred word. It seems that it has reached the highest level of software engineering. It has been worship and inferiority for several years, I don't even know how to build a model. That night I was completely insomnia. Since then, I have been technically helpless. Why? Because I already know that if I want to make some achievements in the software field, I must learn to model the real world. From that point on, the word "modeling" has little to do with UML in my mind.

After that, I struggled in the sea of software analysis and design to find the "Modeling Golden Key" that was crossed in front of me like a meteor. With it, I could go to a holy world. A few years later, I finally learned what the golden key for modeling is. This kind of thing is rare on the Internet and rarely written. Let's take a look at it in detail.

2. Ask yourself, does UML make sense to you? Does it help you analyze and model the system?

I want to learn more or less about UML. In short, UML is a language used for modeling. You can simply understand it as a drawing tool, some elements are defined to express different concepts. Here we are concerned with UML class diagrams, which are used for object-oriented structure modeling. Different figures are used to express abstract object structures.

Figure 1: Simple Order class diagram

650) This. length = 650; "src =" http://s3.51cto.com/wyfs02/M01/45/B8/wKioL1PqAfug54ChAAH7wCxo6NQ002.jpg "Title =" 1.png" width = "600" Height = "305" border = "1" hspace = "0" vspace = "0" style = "width: 600px; Height: 305px; "alt =" wkiol1pqafug54chaah7wcxo6nq002.jpg "/>

It is a very simple class diagram related to "order" and "product". We can all understand the meaning here, because we know the business of this product very well and know where there should be something, for example, the algorithm used to calculate the total price of a product in order. People with business background know that there will be great logical changes here. Therefore, we need to isolate this logic through interfaces.

The reason why we can draw this class chart is actually irrelevant to the UML language. What's important is that you have a good understanding of the relevant business. In your mind, you can use UML for modeling, you can use any sketch for modeling. That is to say, UML is not equal to modeling. So how can we use UML? It does not help us to analyze the system. Right, UML does not directly help us to analyze and model the system from a certain point of view. It helps us analyze and model the business knowledge, business users can use a graphical representation to describe business concepts without UML modeling. In fact, UML is just a common model expression language. It is used to help us communicate with models, not the idea and method of modeling.

Since UML cannot help us analyze systems, how can we accurately model fields that we are not very familiar? We must acknowledge that if a domain expert understands the technology, it must be the most suitable candidate for modeling, but this is not the case. Our technicians need to familiarize themselves with the domain and then create a model, however, important business concepts will inevitably be missing in the middle, because after all, there is a process from the real business to the final model, what makes us helpless most is that there is no practical guiding ideology in this process for reference, and we can only grasp the final quality through experience.

Modeling through experience does not conform to the development methods of the software industry. Obviously, this modeling technology cannot be passed on? The answer is yes, indicating that the technology that can be passed is the purpose of this Article. Let's continue.

3. We have been separated by a gap for a long time, making OOAD inaccessible.

In the previous section, the core issue domain of modeling has been thrown out, but it is not obvious. We use this section to highlight the problem domain that has long plagued our modelers, in order to attract our attention to it, because it is also an important field of research in software engineering.

As mentioned in the title of this section, we are actually separated by a gap generated during modeling. This gap has not been noticed for a long time and has not attracted any attention, therefore, it is difficult to improve our modeling technology.

Modeling is a process. This process is probably like this. We need to accurately express the real business scenario in a certain modeling language. In other words, it is easy to express it in any modeling language, the focus is on how to get this model, and the process of getting this model is what we call the modeling gap here.

Figure 2:

650) This. length = 650; "src =" http://s3.51cto.com/wyfs02/M02/45/B8/wKioL1PqAiuSj63EAAF1B-bF3-g288.jpg "Title =" 2.png" width = "600" Height = "251" border = "1" hspace = "0" vspace = "0" style = "width: 600px; Height: 251px; "alt =" wKioL1PqAiuSj63EAAF1B-bF3-g288.jpg "/>

From the "business concept" to "class model", there is a "modeling process" in place, which is actually the gap between analysis and modeling, there is no mature experience to learn from this blank area. When we are not very familiar with the current analysis business, how can we build the corresponding class model correctly? The Field concept on the surface can be found based on our own experience, however, this is beyond the reach of knowledge. Many OOAD books and even many classic books in software engineering do not provide the answer here. If you use an accurate technical term to describe this process, in fact, there is a lack of modeling and analysis models, and there is a lack of guidance that will allow us to analyze any business. I think this problem must be a common problem for our modelers. We need to solve it. Only in this way will we not be able to get stuck in business areas we are not familiar with. Of course you can say that you can also do OOA, but you will miss something. This is a blind spot in analysis, is the inevitable result of no correct guiding ideology. Just as the Domain Models of the "place order" and "return" core cannot be modeled in the "class model" on the right, most developers cannot identify potential domain concepts as a common problem, the domain concept of "surface layer" is the "entity" in the class model. In fact, we finally went back to the table-driven development process, because you can only find this plane structure by thinking through the E-R model, but this is contrary to the correct software development access theory.

4. The four-color prototype fills this gap in history, so that we can see the hope of OOAD.

In this section, we will discuss an analysis model. It has been around for a while. We are glad that it is dedicated to solving the "analysis" gap described in the above section, through this model, we can analyze almost any business field, and no longer have to worry about missing important domain models because we are not familiar with this field, the biggest problem that leads to code confusion and difficulty in restructuring is the loss of important domain concepts, so that the responsibilities of each object are not in their own space correctly.

This analysis mode is the "four-color prototype" mode. Based on the name, we can probably guess that it is based on four concepts to analyze our business concepts. Which of the following concepts can we take a look:

1. entity: it can also be called an item, indicating a participant, such as a customer or commodity.

2. role: the role of the entity and time period, such as the order delivery type and the user's level role.

3. Description: it is used to describe the public attributes of objects and time periods. For example, the address description of customer entities. This part of information can be generic.

4. Time period: the event of entity participation in a certain period of time, such as an order. A customer purchases a product within a certain period of time. This concept is used to track all events that need to be tracked by an object.

When we use the four-color prototype mode to analyze business concepts, it is difficult to lose the concept of the domain. Below we still use the above business fields as an example to use the four-color prototype mode for analysis.

Figure 3:

650) This. length = 650; "src =" http://s3.51cto.com/wyfs02/M02/45/B7/wKiom1PqAS7w08qIAAILRqbZ7M4960.jpg "Title =" 3.png" width = "600" Height = "390" border = "1" hspace = "0" vspace = "0" style = "width: 600px; Height: 390px; "alt =" wkiom1pqas7w08qiaailrqbz7m4960.jpg "/>

Basically, we can use the four-color prototype to directly set a business domain. we can infer whether the domain model needs one of the four colors based on the idea of the model. In this way, we will not miss important business concepts. The "four-color prototype" model can be used with the "Business Vocabulary" and "Supplemental Specification Description" set in the "RUP" product to complete the wonderful OOAD agile process. The four-color prototype is used to check and accept the business vocabulary in the product of the RUP process, and you can determine whether you have missed important business branches.

It can be said that the four-color prototype is the golden key to the door to OOAD. With it, I believe that our current analysis system is oo.

The model is easy to read and understand. It is difficult to see which is "entity", "role", "Time period", and "Description". the masters used color ideas from other fields to create software models, so that we could see the specific meaning of the models at a glance and bring a strong visual impact, next, let's take a look at color Modeling in detail.

5. Use color Modeling on four-color prototype to enhance visual impact

In order to highlight the visual effect of the model, different colors are used on the four-color prototype to increase the visual impact of the model. The use of color models can stimulate human's inherent visual sensitivity and give people a clear picture of the structure of the overall model.

Figure 4:

650) This. length = 650; "src =" http://s3.51cto.com/wyfs02/M00/45/B7/wKiom1PqAUmz8lsGAAIBb5CG2Cg392.jpg "Title =" 4.png" width = "600" Height = "382" border = "1" hspace = "0" vspace = "0" style = "width: 600px; Height: 382px; "alt =" wkiom1pqaumz8lsgaaibb5cg2cg392.jpg "/>

Use green to represent entities (participants), use ** to represent roles, use Gray to represent descriptions, and use peach red to represent time periods. Of course, the color here is not very accurate, because I am not very clear about the color, so the most suitable color cannot be called, but it is almost OK.

In this way, when we face a large UML class graph model, we can identify the concept represented by each model at a Glance. Its responsibilities are clear.

6. Create a domain-independent model using four-color prototype

During modeling, we do not need to consider what technology the model will be implemented. That is to say, the model is irrelevant to the field (technology, tool, platform) and can be implemented using any technology. The model map built through the four-color prototype model is more plasticity and the concept is very clear. All models are clearly defined and there is no human design in it, this is a very valuable Modeling Technology for any Modeler. Without the background of the four-color prototype model, each modeler assumes many subjective models based on his own experience. In fact, this model is difficult for others to understand, because each person has a different understanding angle, the model obtained is naturally quite different. Therefore, the four-color prototype is a common model for modeling, the final model obtained is also common and team communication is also common.

Technology independence is a field independence model, and it has another meaning. When we have a four-color prototype model, do you find that you have the secret to conquer all business fields, just like a E-R model, a model that can be abstracted without borders is composed of four-color prototypes, which are also domain-independent models.

7. Conclusion: you can skip the specific implementation during modeling, but the modeler must understand the technical implementation.

Although the modeling experts will tell us not to consider the specific technology used to implement the modeling, the people who talk to you are either masters proficient in a certain technology, either it is a theoretical analyst who only knows drawing and does not know how to implement the domain model. The former is actually well known. Why, people who do not understand the technical implementation cannot create usable models when modeling, because the concept is a concept after all. Once implemented to the Code, everything has changed in the architecture, it is not that simple and straightforward to implement. read/write, business flow, and responsibilities need to be taken into account. There are strong technical problems in it.

Now the article is over. I hope this article will serve as a reference to those who are interested in OOAD, UML, and modeling, for more information about the content of this article, see the book color modeling. This book is written by OOAD master [Peter Coad]. Thank you.

Wang qingpei

Source:Http://wangqingpei557.blog.51cto.com/

The copyright of this article is shared by the author and 51cto. You are welcome to repost it. However, you must retain this statement without the author's consent and provide the original article connection clearly on the article page. Otherwise, you will be entitled to pursue legal liability.

This article is from the pattern driven the world blog, please be sure to keep this source http://wangqingpei557.blog.51cto.com/1009349/1539117