Classic quotations from the log of good faith

ARTHUR: J. riel object-oriented design heuristics

This article discusses two competing ideas on object-oriented analysis and design, and explains that both ideas are not the best.
Those who hold the first point of view believe that object-oriented analysis should be a data-driven process in which developers check system requirements, find associations, find natural aggregation, and inherit. System behavior (that is, relationship usage) is not specified until the design. The idea of this method is to first create a complete object model without having to get involved in specifying behavior. The Rumbaugh method is the most popular data-driven model.
The second is basically the opposite of data-driven modeling. In this view, object-oriented analysis should focus on system behavior. Designers should find out the relationships between classes and their usage during the analysis phase. Some Usage relationships are refined into inclusion relationships during design. Booch, Jacobson, and Weiner/Wilkerson/wirfs-Brock are three well-known behavior-driven methodologies.
......
In some management information system (MIS) fields, data-driven methods can work well. This is because these MIS applications Program No meaningful behavior. These applications often divide an object model into parts and distribute them in different forms. This does not mean that the MIS application system is not important. Many projects in this field are very complex, but their behavior is ordinary. All meaningful content is static object models, and there may be user interfaces.
......
The behavior-driven method has another different but equivalent problem. There are many classes in large systems, and designers must use natural aggregation in the analysis model. If you do not consider these natural aggregates, each class in the system is located at the top of the design, this leads to a very complex collaboration diagram (the class at the top of the design and the usage relationship between them ). It turns out that it is very difficult to try to analyze this graph to find the inclusion relationship. This problem is invisible to small systems consisting of 15 to 20 classes. However, if this methodology is applied to systems with 200 classes, this disadvantage will emerge. In the end, we may organize the 200 classes into 15 contained hierarchies. This is the level I expected during design check, 15 classes instead of 200 classes. Of course, the data-driven model is affected by this fact: In the analysis stage, we can only find natural aggregation. Most systems also use inclusion relationships to paging system functions in an include hierarchy. If you do not take the system behavior as a guide, you cannot find the contained usage.
......
Since I have not only pointed out the shortcomings of the data-driven design, but also pointed out the shortcomings of the behavior-driven design, what should I do when designing the requirement specification to create a system?
I suggest combining the above two methods. At first I used data-driven modeling technology, and then gradually transitioned (epil) to the behavior-driven design method. In this way, I can use natural aggregation to simplify the design, and I can also discuss system behavior during the analysis phase. I believe that using data-driven modeling at the beginning will certainly not bring harm, as long as the design can realize that, without discussion of behavior, it is impossible for many systems to create a complete object model.