. NET application Architecture design-four-color prototype mode (color modeling, domain-independent model) (concept version)

Reading folders:

• 1. Background information
• 2. Ask yourself, does UML mean anything to you? Does it help you to analyze and model your system?
• 3. In fact, we have been separated by a gap, so that we can not reach the Ooad
• 4. Four-color prototype model fill this historical gap, let us really see the hope of Ooad
• 5. Using color modeling to enhance visual impact on four-color prototypes
• 6. Modeling domain-independent models with four-color prototype mode
• 7. Conclusion: When modeling you can not consider the detailed implementation, but the modeler to understand the technical implementation

1. Background information

So far, I remember the first time I was asked by the interviewer what "modeling" technology was, it was a few years ago. At that time was confident to interview a system analysis, design. NET Advanced Software Project Engineer Post. The interviewer almost didn't ask me about it. NET aspect of whatever technology is implemented. He simply asked, "How do you grasp the correctness of the system you have analyzed?" "I was a little bit excited to think that the problem should be very easy. is a concept, let him ask directly. As a result, he said, "Do you know how to model?" , can you explain to me the role of modeling? “。 Then he gave a sample, let me model This example, to take into account the various extensibility, business stability of the key points, to the side of the modeling side to say why this modeling, to say the idea. He finally emphasized: "The model created is not agreed with whatever the detailed code, the work has the association."

As far as I'm concerned, what he means is that the UML class diagram model created is a domain-independent model (domain-wide model) that can be implemented with whatever programming technique. As modelers don't need to consider these implementation details, the more you consider, the easier it is to distribute your equivalent modeling of real business. The common fault of the easy offender (consider business with technical thinking).

I thought it was easy. is not the use of UML to make a point map to do the show, reflect the analysis, design of the high-end well, the other can have what role; in fact, I thought it was because I tried to learn, understand, and use UML, modeling, and I found this to be a show tool, very dismissive of this thing, There is even a resistance to the "modeling" field in software project.

I casually said some of my experience in learning UML modeling, thinking this is finally the answer, because it is really the role ("show"), and then I through the code-driven modeling. Backwards deduced UML class diagram, the result and I expected almost the same, basically covered the sample of a few generous side, anyway, the interviewer does not know how I came to this UML class diagram, only God knows, I was to build the code model and then reverse direction to the class diagram model, What is said in the mouth is opposite to the ideal of the heart.

When I felt very good waiting for the interviewer to ask the next question, things came up. The interviewer said I missed something and said I didn't fully consider the business scenario. Without dividing the key concepts in the business concept, or even neglecting the very small domain entity attributes, the software developed in accordance with my model diagram is not available to meet today's business requirements. I was blindfolded, what is the key concept, which concept is not the key concept Ah, and where can not be used. Psychological a bit wronged. Not understand for a moment. Think the interviewer is embarrassing me.

In fact, I can now make clear what the interviewer said at that point. He meant that I failed to articulate the responsibilities of each class, and it seemed that each class played the same role, and that it was nothing more than a property, a method, that I failed to capture the core domain concept. Not being able to think about modeling in the field, but standing on the level of the code to look at it from the low. A lot of things can't be seen clearly. Plainly. If the developer gets to the class diagram to see if they are going to face the field, the hypothesis can be clear, when the class diagram model is healthy, the hypothesis is not clear that is problematic, because the model diagram is not for itself to see. It's about sharing the whole team.

Later I adjusted the mood, even if the interview failed I have to have a summary. An interview is a process of being abused. ("Buddha said: At this time is the practice", it is good exercise.) ）

I humbly ask the interviewer what's wrong with this model diagram, he points out that there may be a blind spot in the analysis that I could never see in my life, he said. The problem is that the program ape uses technical thinking to analyze the common problems of modeling.

Why he can see these blind spots, and I can't, I really want to know the essence of this. I asked for a pay cut here to study, the interviewer is willing to let me come, he is also a technical pursuit of people.

But then I had a special thing not to go to your company to take office. Since then I have been sorry, this modeling essence I could not understand the whole life.

Now I can make it clear that, in fact, assuming that the code-level analytical thinking to assist you in modeling is bound to have a blind spot, because the code-level "design pattern", "design principle" is not modeled when the "Analysis mode", which is two different problem domains. In other words, they are used in different business areas. You can't generalize. Assuming that cross-use will mislead you at the moment of gravity, you will be in it.

"Modeling" this very abstract and sacred word is how domineering. It seems to have hit the top of software project. Worship, inferiority. Software development also has a few years, even modeling do not understand, that night I completely insomnia, since then I was full of helplessness in technology, why? Because I already know that I want to have some results in the field of software. Must learn to model the real world. Starting with the word "modeling" in my mind has little to do with UML.

Then I was in the software analysis, design of the sea to find this before me as a meteor like the "Modeling Golden Key". With it I can go to a sacred world. The reverse side of the years passed. Not long ago I finally knew what the "golden Key to Modeling" was, and this kind of stuff was very rare on the web. Write very little, below we come to understand it specifically.

2. Ask yourself. Does UML mean anything to you? Does it help you to analyze and model your system?

I want to learn more about UML than anyone who has ever studied software development. Simply speaking it is a language for modeling, and you can simply interpret it as a drawing tool that defines some elements. Used to express different concepts. Here we are concerned with UML class diagrams. It is used for object-oriented structure modeling, and the abstract object structure is expressed through a variety of different graphs.

Figure 1: Simple Order class diagram

is a very easy "order" and "product" related to the class diagram, we can understand the meaning of this, because we have a good understanding of the business, and know where there should be, for example, the order of the calculation of the total price of the algorithm. People with relevant business backgrounds know that this is where there is a great deal of logical change. So we need to isolate this logic through an interface.

The reason why we can draw this kind of diagram is that it doesn't really matter what the UML itself is, but what matters is that you know the business very well and you can model it without using UML in your mind. You can model whatever a sketch is, meaning that UML is not equal to modeling. This is a clear understanding.

So what do we use UML for? It does not help us to analyze the system. Yes, UML does not directly help us to model the system from a point of view. What helps us to analyze and model is those business knowledge. People who know the business can use UML to model, and use a graphical notation to illustrate business concepts.

In fact, UML is just a generic model expression language, is used to help us communicate the model, not the idea and method of modeling.

Since UML does not help us analyze the system, how can we accurately model the areas that we are not very familiar with? We must confess. Domain experts assume that knowing technology is certainly the most suitable candidate for modeling. But the reality is not so. It takes our technicians to get to know the field and create the model, but it inevitably misses out on important business concepts. Since after all, from the real business to finally the model is a process, and the most let us helpless is in the process of no matter what the guiding ideology can be borrowed, only through experience to grasp the quality of the last.

Is it always through experience to model the development method that does not conform to the software industry, obviously not, such modeling technology can not pass it? The answer is to be able to pass, stating that the technology that can be passed is the purpose of this article. Let's keep looking down.

3. In fact, we have been separated by a gap, so that we can not reach the Ooad

In fact, the core problem domain of modeling has been thrown out in the previous section, just not very obvious; We use this section to highlight the problem domain that has long plagued our modeler, to give us a lot of attention to it, because it is also an important area of research in software project.

As the title of this section says, in fact we are separated by a gap created by a modeling process, and this gap has not been noticed for a long time, and has not attracted much attention, so it is very difficult to improve our modeling techniques.

Modeling is a process. This process is probably the case, and we need to accurately express the real business scenario in some kind of modeling language. In other words, what modeling language is very easy to express, the focus is how to draw this model, and the process of drawing this model is what we call the modeling gap.

Figure 2:

a "modeling process" is sandwiched between "business concept" and "Class model". This place has been, in fact, an analysis of the modeling gap. This blank place has been without mature experience to learn. In our current analysis of the business is not very understanding of how to correctly build the corresponding class model, the surface of the domain concept we can rely on their own experience to find it, but this is not a transfer of knowledge. A lot of ooad books even contain a lot of software. The classic books in Project are not given here, assuming that the process is described in an accurate technical term, in fact a lack of a set of modeling analysis patterns. The absence of an approach that allows us to analyze whatever business we are doing is a constant set of guidance patterns. I think this question is certainly a common problem for our modelers, and we need to solve it. Only in this way we will not be able to meet our unfamiliar business areas sometimes helpless, of course, you can say that you can also be OOA, but you will miss something. This is the analysis of blind spots, is not the correct guiding ideology of the inevitable result. As in the "Place order" and "return" two core domain models fail to model in the "class model" on the right, most of the developers are not able to identify the potential domain concept, think "surface" domain concept is the "entity" in the class model, In fact, we went back to the table-driven development process in the end. Because you only have the ability to think through the E-R model to find the structure of such a plane, but this and the correct software development access to the theory of the contrary.

4. Four-color prototype model fill this historical gap, let us really see the hope of Ooad

In this section we will discuss an analysis pattern that has existed for some time. What is worth our pleasure is that it is specifically designed to address the "analysis" gap described in the above-mentioned sections, and through this model we can almost analyze any business area, and no longer be afraid of missing out on important domain models because of our unfamiliar domain, which leads to code confusion, The biggest problem with hard refactoring is the loss of important domain concepts. Let the responsibilities of individual objects not be properly in their own space.

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

1. Entity: can also be called an item, indicating a participant, for example: Customer, commodity.

2. Role: The entity, the role of the time period, such as: the delivery type of the order, the user's rank role.

3. Descriptive narrative: Used to describe the public properties of entities and time periods. For example: The description of the address of the client entity, this part of the information can be universal.

4. Time period: The entity's participation and events within a certain time period. such as: Orders. A customer buys an item in a certain period of time.

This concept is used to track all the events that are required to be tracked by an entity.

When we use the four-color prototype model to analyze business concepts, it is very difficult to lose domain concepts. Here we still use the four-color prototype model for the above business areas as an example.

Figure 3:

Basically, we can use the four-color prototype model to directly set a business area, we can judge the domain model according to the idea of the need for one of four colors.

This way we basically don't miss out on important business concepts. By using the "four-color prototype" model and the "Business Glossary" and "Supplemental Specification" collections in the RUP artifacts, you can complete the wonderful ooad agile process.

Use the four-color prototyping model to check the business glossary in RUP process artifacts to determine if you missed out on important business branches.

To say that the four-color prototype model is the Golden key to the door of Ooad, I believe that we are now analyzing the system is OO.

The model is for people to read and understand, we are very ugly about which is "entity" which is "role" which is "time period" and "descriptive narrative." So the Masters draw on other fields of color thinking to create a software model, so that we can see the concrete meaning of the model at a glance, and bring powerful visual impact. In the next section, we look at color modelling in detail.

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

To highlight the visual effects of the model, use different colors on the four-color prototypes to add visual impact to the model.

The use of color models can inspire human innate visual sensitivity, and let people know at a glance what the overall model is.

Figure 4:

Use green to represent the entity (participant), use yellow to denote the character, use Gray to describe the narrative, and use pink to indicate the time period.

Of course, the color here is not very accurate. Because I was not very clear about the color, so I did not pull out the most suitable color, but almost the same can be.

So when we face a large UML class diagram model, we can recognize the concept that each model represents and its responsibilities are clear.

6. Modeling domain-independent models with four-color prototype mode

When modeling, we don't have to consider what technology the model will be landed on, which means that the model is irrelevant to the domain (technology, tools, platform). Be able to use whatever technology to implement it.

The model diagram constructed by the four-color prototype model is more malleable. The concept is very clear, all the models are conceptually clear, there is no artificial design in the inside, for no matter what a modeler this is very valuable modeling technology.

Without the background of the four-color prototype model, each modeler is based on his own experience if a very subjective model comes out, in fact this part of the model is very difficult for others to understand. Because each person's understanding angle is different, the resulting model is naturally very large, so the use of four-color prototype model when modeling is a relatively common mode. The final model is also a common and team communication is common.

Technology-Independent is a facet of the domain-independent model, field-Independent has another layer of meaning, and when we have a four-color prototype pattern, do you find that you have the secret to conquer all business areas, like the E-R model, a pattern that can be used without marginal abstraction, which is made up of four major prototypes, And this four prototype is also a domain-independent model.

7. Conclusion: When modeling you can not consider the detailed implementation, but the modeler to understand the technical implementation

While modeling gurus will tell us not to consider the last detail of what technology to implement when modeling. In fact the person you are talking to is either a master of a skill or a theoretical one. An analyst who knows only how to plot a field without knowing how to do it in detail, the former is actually aware of it, and why that is, it is not possible to create a model that can be used because people who do not understand the technical implementation of the model. Since the concept is after all a concept. Once landed on the code, everything changed in the architecture. It's not that simple and straightforward. Need to take into account reading and writing, business flow, responsibility and so on. There is a very strong technical problem inside.

Okay, here's the end of the article. I hope this article can play a role for those friends who are interested in Ooad, UML and modeling. To further study the content of this article can be a reference to "color Modeling" book, this book is Ooad master [Peter Coad]. Thank you.

King Qingyue Culture

Source:http://blog.csdn.net/wangqingpei557

This article is copyright to the author and Csdn co-owned, Welcome to reprint, but without the author's permission must retain this paragraph, and in the article page obvious location to the original link, otherwise retain the law rights and obligations.

Copyright notice: This article blog original article. Blogs, without consent, may not be reproduced.

. NET application Architecture design-four-color prototype mode (color modeling, domain-independent model) (concept version)