Shulou(Shulou.com)06/03 Report--

Read the catalogue:

1. Background introduction

two。 Ask yourself, does UML mean anything to you? Does it help you analyze and model the system?

3. In fact, we have been separated by a gap all the time, which makes us out of reach of OOAD.

4. The four-color prototype model fills this gap in history and makes us really see the hope of OOAD.

5. Using color modeling to enhance visual impact on four-color prototype

6. Modeling a domain-independent model through a four-color prototype model

7. Conclusion: you may not consider the specific implementation when modeling, but the modeler should understand the technical implementation.

1. Background introduction

To this day, I clearly remember the first time I was asked by the interviewer about "modeling" technology, which was several years ago. I was ready to interview for a position as a senior software engineer in .NET related to system analysis and design. The interviewer hardly asked me about any technical implementation in .NET, so he simply asked, "how do you grasp the correctness of the system you analyzed?" At that time, I was a little excited. I thought the question should be very simple. It was all just a concept. I asked him to ask it directly, and as a result, he said, "do you know anything about modeling? can you explain to me the role of modeling?" Then he gave a small example and asked me to model this example, taking into account the key points of scalability and business stability. Finally, he emphasized that "the model created is not allowed to be associated with any specific code or tools."

In my opinion, what he means is that the UML class diagram model created is a domain-independent model (domain general model), which can be realized with any programming technology, as a modeler does not need to consider these implementation details, the more you consider, the easier it is to disperse your equivalent modeling of the real business, and it is easy to commit the common fault of technicians (to consider the business with technical thinking).

I thought at that time that it was easy, ah, that is, to use UML to make some pictures to do a show, reflecting the high end of analysis and design, and what other functions could have; in fact, the reason why I thought so at that time was because I had tried to learn, understand and use UML and modeling. As a result, I found that this was just a tool for show. I was very disdainful of this thing, and even had a kind of resistance to the field of "modeling" in software engineering.

I casually talked about what I learned when I was learning UML modeling, and I thought this is the final answer, because that's exactly what it does ("show"), and then I use code-driven modeling to derive the UML class diagram backwards, and the result is similar to what I expected. Basically covered several major aspects of this small example, anyway, the interviewer does not know how I came up with this UML class diagram, only God knows, I first build the code model and then push the opposite direction to the class diagram model, the mouth is completely the opposite of the ideal.

When I felt very good and waited for the interviewer to ask the next question, the situation happened. The interviewer said I missed something, said that I did not fully consider the business scenario, did not clearly divide the key concepts in the business concept, and even neglected the very small domain entity attributes. The software developed according to my model diagram can not meet the current business requirements. I was confused at that time, what is the key concept, which concept is not the key concept, and where can not be used, psychological grievances, temporarily do not understand, feel that the interviewer is embarrassing me.

In fact, I can now understand what the interviewer meant at that time. He meant that I could not clearly express the responsibilities of each class. It seems that each class plays the same role, nothing more than attributes and methods. I failed to capture the core domain concept, failed to consider modeling from the domain, but looked at it from the bottom up from the level of code. Many things are not clear. Developers get whether the class diagram can understand the field they are going to face, and if they can understand, the class diagram model is healthy, and if they do not understand, it is problematic, because the model diagram is not for themselves, but for the whole team to communicate and share.

Later, I adjusted my mood. I had to sum up even if I failed in the interview. The interview is a process of being abused. The Buddha said, "this is the time for spiritual practice." take it as exercise. )

I humbly asked the interviewer what was wrong with this model diagram. He pointed out the analysis blind spot that I might never see in my life. He said that this problem is a common problem for programmers to analyze modeling with technical thinking. Why can he see these blind spots, but I can't? I really want to know the essence of them. I asked for a pay cut to study here at that time. The interviewer was willing to let me come here if I didn't get a pay cut. He is also a person who pursues technology. But then I was unable to work in your company for something special, and since then I have always regretted that I may not understand the essence of this modeling for the rest of my life.

Now I can understand that, in fact, if you use code-level analytical thinking to assist you in modeling, there must be a blind spot, because code-level "design patterns" and "design principles" are not "analysis patterns" when modeling. These are two different problem domains, that is to say, if they are used in different business areas, they cannot be generalized. If cross-use will mislead your current focus, you will add fuel to it.

How domineering the very abstract and sacred word "modeling" is, it seems that it has reached the highest state of software engineering; worship, inferiority complex; I have been engaged in software development for several years, but I don't even understand modeling; I had complete insomnia that night. I have been full of technical helplessness since then. Why? Because I already know that if I want to be successful in software, I have to learn to model the real world, and from then on, the word "modeling" has little to do with UML in my head.

After that, I struggled in the ocean of software analysis and design to find the "golden key" that had been delineated like a meteor in front of me. With it, I could go to a sacred world. After several years of tossing and turning, I finally know what the "golden key to modeling" is. This kind of thing is rare and rarely written on the Internet. Let's learn more about it.

two。 Ask yourself, does UML mean anything to you? Does it help you analyze and model the system?

I think people who have studied software development know more or less about UML. To put it simply, it is a language for modeling. You can simply understand it as a drawing tool that defines elements to express different concepts. What we are concerned with here is the UML class diagram, which is used for modeling object-oriented structures, expressing abstract object structures through a variety of different graphics.

Figure 1: simple order class diagram

The figure above is a very simple class diagram of "order" and "product". We can all understand the meaning, because we know a lot about the business in this area; we know what should be there, such as the algorithm for calculating the total price of goods in Order. People with relevant business background know that this is a place of great logic change, so we need to isolate this logic through the interface.

The reason why we are able to draw this class diagram has nothing to do with the UML language itself, the important thing is that you know the relevant business very well, you can model without using UML in your mind, you can use any sketch to model, that is to say, UML is not equal to modeling, this should be clearly understood. So what's the use of using UML? It does not help us to analyze the system; yes, UML from a certain point of view, it does not directly help us to analyze and model the system, it is the business knowledge that helps us analyze and model, people who understand the business can model without using UML, and just use a graphical representation to illustrate the business concept. In fact, UML is just a general model expression language, which is used to help us communicate models, not the ideas and methods of modeling.

Since UML can't help us analyze the system, how can we accurately model areas that we are not familiar with? We must admit that domain experts are certainly the most suitable candidates for modeling if they understand technology, but this is not the case. We technicians are required to familiarize ourselves with the domain and create models, but important business concepts will inevitably be left out, because after all, there is a process from the real business to the final model, and what makes us most helpless is that there is no feasible guiding ideology to learn from in this process. Only through experience to grasp the final quality.

Always modeling through experience is not in line with the development method of the software industry, obviously not, this modeling technology can not be passed on? The answer is transmissible, indicating that this transmissible technology is the purpose of this article. Let's move on.

3. In fact, we have been separated by a gap all the time, which makes us out of reach of OOAD.

In the previous section, we have actually thrown out the core problem domain of modeling, but it is not very obvious; we use this section to highlight this problem domain that has been troubling us modelers for a long time, so as to draw our attention to it. because it is also an important research field in software engineering.

As mentioned in the title of this section, in fact, we are separated by a gap created by modeling, and this gap has not been paid attention to for a long time, so it is difficult to improve our modeling technology.

Modeling is a process, which is something like this, which requires us to accurately express the real business scene in some modeling language, in other words, it is easy to express it in what modeling language. The focus is on how to get this model, and the process of getting this model is what we call a modeling gap here.

Figure 2:

There is a "modeling process" between "business concepts" and "class models". In fact, this place has always been a gap in analytical modeling, and there is no mature experience to learn from this blank place. When we do not know much about the current analysis of the business, how to correctly build the corresponding class model, the surface domain concept we can find it according to our own experience, but this is, after all, untransferable knowledge. Many OOAD books and even many classic books in software engineering do not give the answer here. If you use an accurate technical term to describe this process, it is actually the lack of a set of modeling and analysis patterns, the lack of a guidance model that allows us to analyze no matter what kind of business. I think this problem must be a common problem for us modelers, and we need to solve it. Only in this way will we not meet the business areas that we are not familiar with and sometimes be at a loss. Of course, you can also say that you can also carry out OOA, but you are bound to miss something, which is the blind spot of analysis and the inevitable result of not having the correct guiding ideology. Just as the two core domain models of "placing orders" and "returns" in the above figure are not modeled in the "class model" on the right, the common problem of most developers is that they cannot identify potential domain concepts and think that the "surface" domain concept is the "entity" in the class model. In fact, in the end, we go back to the table-driven development process. Because you can only find this flat structure when you think through the Emurr model, but this runs counter to the correct software development access theory.

4. The four-color prototype model fills this gap in history and makes us really see the hope of OOAD.

In this section, we will discuss an analysis model that has been around for some time, and we are glad that it is designed to address the "analysis" gap described in the above sections. through this model, we can analyze almost any business domain, and we no longer have to be afraid of missing important domain models because we are not familiar with the domain. The biggest problem that leads to code confusion and difficult refactoring is the loss of important domain concepts, so that the responsibilities of each object can not be correctly in its own space.

This analysis model is the "four-color prototype" model. From the name, we can roughly guess that it is based on four concepts to analyze our business concepts. Let's take a look at which four concepts:

1. Entity: it can also be called an item, which represents a participant, such as a customer, a commodity.

two。 Role: the role of the entity and time period, such as the delivery type of the order and the hierarchical role of the user.

3. Description: used to describe the common attributes of the entity and time period, such as the address description of the customer entity, this part of the information can be universal.

4. Time period: an event in which an entity participates in an event, such as an order, in which a customer buys an item within a certain period of time. This concept is used to track all events that need to be tracked by the entity.

When we use the four-color prototype pattern to analyze the business concept, it is difficult to lose the domain concept. We still use the four-color prototype pattern to analyze the above business domain.

Figure 3:

Basically, we can use the four-color prototype pattern to directly cover a business domain, and we can infer whether the domain model needs one of the four colors according to the idea of the pattern. In this way, we basically don't miss important business concepts. The wonderful OOAD agile process can be accomplished by combining the "four-color prototype" pattern with the "business glossary" and "supplementary specification" in the "RUP" artifact. By using the four-color prototype pattern to accept the business vocabulary in RUP process products, you can determine whether you have omitted important business branches.

It can be said that the four-color prototype pattern is the golden key to the door of OOAD, with which I believe that the system we are analyzing is OO.

The model is for people to read and understand, in the above picture, it is difficult to see which is the "entity", which is the "role" and which is the "time period" and "description", so the masters draw lessons from the color ideas of other fields to create software models. In this way, we can see the specific meaning of the model at a glance and bring a strong visual impact. In the next section, we will look at color modeling in detail.

5. Using color modeling to enhance visual impact on four-color prototype

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 natural visual sensitivity and let people know at a glance what the overall model is.

Figure 4:

Use green to represent entities (participants), * * to represent roles, gray to describe, and pink to represent time periods. Of course, the color here is not very accurate, because I am not very clear about the color separation, so I can not adjust the most suitable color, but almost on the line.

In this way, when we are faced with a large UML class diagram model, we can recognize at a glance the concepts that each model represents and its responsibilities are clear.

6. Modeling a domain-independent model through a four-color prototype model

When modeling, we do not need to consider what technology the model will be implemented, that is to say, the model is domain (technology, tool, platform) independent, and any technology can be used to implement it. The model diagram constructed by the four-color prototype pattern is more malleable, the concept is very clear, all the models are clear, there is no artificial design in it, this is a very valuable modeling technology for any modeler. If there is no background of the four-color prototype pattern, each modeler assumes a lot of subjective models based on his own experience, in fact, this part of the model is very difficult for others to understand, because everyone's understanding angle is different, the resulting model is naturally very different, so the use of four-color prototype pattern is a more general pattern. The final model is also universal and team communication is also universal.

Technology independence is one aspect of domain independent model, and domain independence also has another meaning. When we have a four-color prototype pattern, do you find that you have the secret to conquer all business domains, just like the Emurr model? a pattern that can be abstracted without boundaries, this pattern consists of four-color basic prototypes, and these four prototypes are also domain-independent models.

7. Conclusion: you may not consider the specific implementation when modeling, but the modeler should understand the technical implementation.

Although the master of modeling will tell us not to think about what technology will be used to implement it in the end, the person who says this to you is either a master of a certain technology or a theorist. an analyst who only knows how to draw but does not know how to land a domain model, the former actually has a clear idea, why do you say so? Because people who do not understand the technical implementation can not create a useful model when modeling, because the concept is a concept after all, once everything has changed in the code and architecture, it is not so simple and direct landing. Need to consider reading and writing, business flow, responsibilities and other issues, there are strong technical problems in it.

All right, this is the end of the article. I hope this article can play a valuable role for those who are interested in OOAD, UML and modeling. For those who want to learn more about this article, you can refer to the book Color Modeling, which is written by Master OOAD [Peter coad]. Thank you.

Author: Wang Qingpei

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

The copyright of this article belongs to both the author and 51CTO. You are welcome to reprint it, but you must retain this statement without the author's consent, and give a link to the original text in a prominent position on the article page, otherwise you reserve the right to pursue legal liability.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.