Alistair cockburn (February 1996), Yuan Feng translation introduction first, I want to explain why this open letter will be written. This seems to have become a habit, but this step is still needed. In the past six years, I have once spent a pleasant and long night in a variety of places such as restaurants, bars, and hotel lobby: and partners who are also pursuing truth, bright and wisdom. Now, I can answer a lot of problems I have encountered when I was. These same questions are also plaguing my new colleagues, in a hotel, I spent a whole evening and discussed these issues. As a result, his colleague came to ask these questions and suggested that our conversation content is recorded so that he can take a colleague to him. Considering that there are still many people who ask these same questions like his colleagues, I decided to write down this article. The main problem is: Z why only one thing is not a strict or pure-oriented object, how is OO experts? Use case is not object-oriented, why is it so popular? Moreover, OO modeling seems to be very similar to data modeling? The model of the z data modeling (Data model) and the structure of the object model will not be very similar? Process Model and Object Model Behavior? Z Business Structure Construction Modes Why use USE Case and Scenario)? OO's novices to ask these questions, but in fact, only in the daily work, adhere to the object-oriented thinking, accumulating certain experiences can Get a satisfactory answer. Why is it just a little more important or purely-oriented, and OO experts is very surprised? Use case is not object-oriented, why is it so popular? Moreover, OO modeling seems to be very similar to data modeling? I think three steps to answer this question. First of all, I will work with Bob (famous OO expert), when we discuss OO, there is a consensus, knowing that the other party has a rich experience in object-oriented work and is the firm supporter of this technology. Moreover, it is hand to come to other objects, instances, data, and behaviors, such as object identification, data, and behavior. So when I said: "Tomorrow's data modeling is made", Bob does not generate me to abandon the misunderstanding of the object because of the relationship table, he knows that I refer to the structured structure in the object model. Features modeling. He knows what I will say, so I use or misuse these terms not to cause any misunderstanding. But as an object of an object technology, if Bob finds that you complete the data and behavior completely, it is not used (or ignored) object identification or polymorphism, this time, if you say "data modeling" Bob will approach you like a wall until you understand how to change. Working for a few months, you will find that your model (and modeling) has gradually had object identification, polymorphism, data and behavior of the object, this time is not so dangerous to use "data modeling". But Bob may also worry that you go back to the old way. In other words, he is not trusted enough for you, so you have to use these terms carefully. Even if an object model can be divided into "structure" and "behavior" features, we will not use "object modeling" and "process modeling" terms to avoid confusion.
In fact, modeling of the "structure" characteristic of the object model can be regarded as a special form of data modeling, but only the object modeling is no longer a table, but the structure of the information that needs to capture. We call it "concept data model" instead of logical data models or physical data models. In the second step, let us consider the cases discussed together in two OO users. If one of the guys said the word "process modeling" will definitely make his partner for a long time: Is this guy to model the standard data flow map? If this is, isn't it true when the OO is achieved? Does he refer to the behavioral characteristics of the model? Is it to model the process within an object? (If this is the case, it will be very interesting because few people do this.) Through this example we can see that this conversation uses "flow modeling" this intention of the meaning is too dangerous, very It is easy to communicate very difficult. Finally, the problem of USE Case and scenes is the main means of obtaining demand, and has nothing to do with implementation technology. It is the benefit of providing content and scope for discussions when designing. They are not "object-oriented", this is the fact that they are similar to functional decomposition, which is also the fact, and this is frightened by many people, but these don't matter. Important is that they provide content for design, which represents the behavior of the system when used to describe internal design. Flow Chart, interaction, Petri network, data flow map, USE case can be used to describe the behavioral characteristics of the system, but each use is different, each has excellent. The key is to know: The object not only has data, but also has behavior, recognizing this, you can boldly consider how you can better capture, describe the internal and objects of the object. The model of data modeling and the structure of the object model will be very similar? Process Model and Object Model Behavior? According to my experience, the data modeling personnel can be divided into two - one is to model the stored data, and the other is to model the information in the system or organization. These are different. The concepts used by the former discussions and thinking are usually very specific, such as data sheets. Their models and OO models have a large phase of the model, and they are not willing to see the similarities between these technologies. In the data modeling community, only the logical data model or the physical data model will not be received by the latter, the concept data model. Based on my experience, the model they get is very similar to the models that have experienced OO modeling. Their work is more similar to business people, rather than logical data modeling people, which may help understand the difference between concept data model and logical data model. It seems that there is a set of learning to help people get results more quickly than OO modeling people. I have discovered such a fact that OO modeling staff spent three or four iterative models, actually and (concept) data modeling the model a looped model is the same. This finding made me full of data modeling people. In fact, when the object is designed, I sometimes go directly to copy the product of the product modeling personnel to see, from the perspective, what is the final model will probably? I have held a meeting between data modeling staff and object modeling personnel. The method taken is "CRC Sessions for An Audience. Four experienced OO designers sit in one end of the long table, business experts sit down along the long table, they are responsible for answering questions and correcting business Misunderstanding. Then the data modeling personnel, the other of the long table is other related personnel. In general, the house is probably more than a dozen people, but the conversation is mainly between the four OO designers.
After discussing about an hour, the OO designer can get part of the object design. At this time, consult the data modeling personnel, this model and the model they have gone are essentially the same. They said, "Yes", repeat this process twice, each time you ask the same problem, in addition to the symbolic technology used, for example, they don't use inheritance, but in the same place The placeholder, in essence, this model is different from their model. Next, we divided into several groups, each group included a business expert, a data modeling expert and an OO expert, soon, the remaining design is agreed, identify some small differences in technology, and sort . The general situation is like this: either data modeling staff considers more reasonable, or OO modeling staff considers more reasonable, and the group is to coordinate between their designs. From the above experience, it can be seen that the results obtained by using CRCs to model the model and conceptual data modeling are very similar. In addition, depending on the experience, the relationship modeling and OO modeling based on logic (stored information) is different. In most cases, the difference is due to the difference in technology, for example, in the OO model, inheritance and multi-to-many relationships can be freely used. Due to technical differences, the two modeling people cannot communicate well, which is the greatest difficulty. The problem of data modeling is so much. The situation is not the same as the process modeling. In the early 1990s, various methods, plans, conferences, and projects emerged, trying to convert the model of the data flow map to the object model. There have been several projects claimed to have succeeded, but they all have no sound, the industry consistent conclusion is that this shift is too difficult. Most modeling people using data flow charts eventually abandoned this technology and put into the embrace of object design (Martin-Odell and PTECH teams were famous). For process modeling, at this stage my answer is: The model cannot be compared to the OO model. But this is not the final answer. OO modeler is beginning to model the process modeling. What will be the next development, I am not clear, the process will become the process (process programming is resurrected?), Or Does it become a data flow map or similar to the encapsulated object? Why use USE Case and Scene (Scenario)? USE Case and Scene ... ... for discussion, ... When did it stop, ... Provide parameters for the design pressure test. I have seen some groups that don't use "scene". When they model, it is actually a random adventure in the problem domain. The person in charge does not know what the next question is? It is often intuitive. Generally speaking, they don't know if the information currently captured is finally really needed, even if you know, you know the intuition or shame. In a silent late night, several truly expert OO designers said to me: there is no effective rule to guide the beautiful object design. One of them said, "We are really actually discussing without a destination", and the other is quite agreeable. "Sometimes we are like a flies like the heads, until some good objects have hit some good objects Come out. "Use scenes that cannot prevent blind discussions and hit the wall everywhere, just provide content and boundaries for discussion. The group I have seen is not in the scene, and I have a big model in a large modeling range for a long time.
