Http://www.uml.org.cn/sjms/2004092401.htm "Analysis Mode: Reusable Object Model" - Responsibility Mode
Windy J (windy.j@163.com)
1 responsibility mode
The focus of this chapter is related, and how to build a model for an intricate relationship, and all the illustrations are from the original book ("Analysis Patterns: Reusable Object Models) and follow the UML standard. 1.1 PARTY mode
In this chapter, first we come into contact with the party mode, when systematic analysis and conceptual model design, often find that people and a variety of organizations have the same behavior, for example, the billing of the fixed phone may be For individuals, it is also possible to be a unit; when you need a variety of services, you may have to help a service company, or a specific salesman of the company. In short, because of the consistency of person (Organization), as seen below, we abstract PARTY, as the abstract parent class of Person and Organization.
1.2 Organization's internal structure
Step 2, if we transfer attention to the internal structure of Organization, we will find some interesting problems, usually one of the most common structures is a pyramid structure, so it may be established in such a structure when modeling. Model, for example:
Such models are not wrong, but there are defects, first unable to meet more complex organizational relationships, more seriously, once there is more hierarchical relationships, such as existing department directly upstairs relationships, and regional management methods will cause the entire Model changes, the impact of the system, in this case, the most common improvement measures are introduced to the hierarchical relationship, as shown below:
By adding new relationships, you can flexibly implement various relationships between organizations (Organization) and possible changes. In the above figure, {hierarchy} is a constraint to limit the relationship. 1.3 Organizational relationship abstraction
In the third step, in general, the above mode is enough to solve the problem, but when such levels and organizational relationships are many and complicated (more than two), for example, now the popular matrix management can extract the relationship itself. Independent processing, as shown in the figure below, the author takes into account the valid period of the organizational structure, so a time period property is added to record the existence time of the organizational structure.
Note that in this mode, the Organization Structure is the core of the pattern. In the system, the structure of the structure is described by the two Organization instances (respectively, served as a Parent and Subsidiary, and a Type instance). In such a structure, there may be many rules (Rule), which can be processed separately depending on the situation: if Type is much related, the rules are mainly related to Type, and allocated to TYPE; if Type is not much, but main Depending on the subtype of Organization, it can be distributed into the subtype of Organization. 1.4 Responsibility (Accountability) The fourth step, from the first step, Party is the abstract parent class of Person and Organization, so putting Party into the above mode (a bit like the usual use in our hunges), formally forming responsibility (Accountability) mode.
1.5 Knowledge Level and Operational Level
Such an idea is to consider the following: When the number of AccountAblity Type is much more than the number of Accountability, the rules that handle AccountAblity Type have also become more complicated. To solve such problems, you can introduce knowledge layers and operations. The separation of the layer. As can be seen from the figure, it is the Knowledge Level and Operational Level, which is completed by three class collaboration in this model, which is AccountAblity Type, respectively. Connection Rule, Party Type, defines legitimate Party relationship rules in Connection Rule, and the legitimacy test when AccountAblity is created via AccountAblity Type. Another advantage of it is to instantiate the knowledge layer independently, as an operational level of operation; in other words, when the rule of the knowledge is changed, the system's behavior will be changed, not Any other code is required, which is of course a more ideal situation.
As a result, the design idea of building an expert system can also be inspired from this mode, which is the feeling of the author. In the original, how to achieve such a model is relatively blurred, but the author believes that they can be implemented as a normal model, and the difference between the two levels is simplified to indicate their respective tasks and status. The knowledge layer tends to describe the various forms of the system possible, and set various rules that determine if the system is valid; the operation layer describes the actual behavior of the system under such configuration. The external behavior is changed by changing the inner configuration, the purpose of this mode. Due to the characteristics of this mode, it is not necessary to change the code of the operating layer when changing the system behavior, but does not mean that the system behavior is not necessary to do. Similarly, debugging, configuration management is also required. The author also mentioned that such modes are not easy, even in a general system, but when you find it, don't hesitate (feel like using parachutes)! 1.6 Summary from simple to complex, the previous five steps describe the various modes for solving Party and their relationships, each recommended mode has the opportunity to perform, I hope that this article can play some of the role of throwing jade, And welcome everyone to correct it, welcome to express opinions and communicate. Original reference "Analysis Patterns: Reusable Object Models", Chapter 2, Martin Fowler
