Analysis Model: Understanding and responsibility model

Analysis Model: Understanding and responsibility model

Martin Fowler's "Analysis Model" has been bought for a long time and has read it many times, failing to fully understand it. This reading experience is just a few simple points of view.

To talk about the Accountability model, you also need to start with the program implementation of the organizational structure. A project involves more or less the description of the Department's organizational structure. At present, our solution is nothing more than two: one is the method that requires recursion, and the other is the method that does not need recursion.

The so-called recursive processing method is that each department uses the following data structure for storage: depart (dept_id, parent_id ,...). This advantage is that it can represent an infinite level. The disadvantage is that the processing speed is slow, and most of them need recursion.
The so-called non-recursive processing method means that each department uses the following data structure for storage: depart (levelcode ,...). The levelcode here is a hierarchical data structure, such as the string method: company. software. development. java_team, or the zip code method 0105080905. This advantage is that the processing speed is fast and intuitive, and usually does not require recursion. The disadvantage is that the expression is limited by the storage capacity (such as the field length ).

In order to express the needs, we use recursive structures to express the following examples.

Now I have raised a question. In many cases, the Department structure is not single. Refer to the commonly used matrix project organization structure. A project team must be responsible to the company's project management organization, we also need to be responsible for the department. How can we express this structure?

In general, if the world is so simple, we can undoubtedly change the Department definition just now to project (proj_id, dept_id, proj_mgr_id ,...). In fact, the world that programmers are facing is very complex. What if the CEO of the company wants to lead the project directly? Therefore, we need to find a more effective and simple expression method to adapt to the coexistence of multiple hierarchies.

The analysis model summarizes departments, projects, companies, and even individuals as "organizations" in general )". By replacing the preceding direct id association with an intermediate object (table), multiple layers can coexist. The definition is as follows:

Class Organization
{
OrganizationStruct [] Parents;
OrganizationStruct [] Children;
 
}

Class OrganizationStruct
{
Organization Parent;
Organization Child;
OrganizationStructType StructType;
TimeLimit Limit;
}

Enum OrganizationStructType {Project2Project, Depart2Project, Company2Project ,}

Class TimeLimit
{
DateTime Begin;
DateTime End;
Bool IsFinished;
}

However, although such a structure is flexible enough, it is not binding enough. Because of the above structure, we can also describe the "project" as the "Company" superior department. So how can we increase the constraint of this structure? It's easy to define OrganizationStructType from a simple enum into an entity:

 

Class OrganizationStructTypeEntity
{
OrganizationStructType StructType;
 
Bool Check (Organization parent, Organization child); // rule
}

 

Then replace organizationstructentitype in OrganizationStruct with organizationtypetype. When adding a new relationship, we can use Check to verify that the data conforms to the normal logic. Of course, the Code provided here is not optimal, just to illustrate a concept.

The "Responsibility type" in "Analysis Mode" is not just used to solve the organizational structure and organization problems. In reality, there are common hierarchical relationships, including various organizational structures and contracts. However, the application scope of "Responsibility type" defined in "Analysis Mode" is "variable", which is why we need a TimeLimit. When describing the data structure relationship between "dad" and "son", we need to use the initial id for Direct association; however, if we describe the concepts of "guardian" and "ward", we can apply the "responsibility type" model.

When we abstract the "organizational structure" relationship to the level of "Responsibility type", we need a set of specialized rankings to replace the previous concepts, so let's modify the above Code:

Class Party
{
Accountability [] Commissioners; // delegate
Accountability [] Responsibles; // responsible party
 
}

Class Accountability
{
Party Commissioner; // The entrusting Party
Party Responsible; // Responsible Party
AccountabilityType StructType;
TimeLimit Limit;
}

Enum AccountabilityType {Project2Project, Depart2Project, Company2Project, Contract ,}

Class TimeLimit
{
DateTime Begin;
DateTime End;
Bool IsFinished;
}

The application of the responsibility type model is certainly more extensive than the simple "organizational structure. More importantly, the complexity of our programs has not increased. Here we extract two examples from the book:
John Smith works for a company. Here he can be modeled as a responsibility type, where a company is the delegate, John Smith is the responsible party, and the responsibility type is the employment relationship.
John Smith allows Dr. Mark to perform an endoscopic examination, which can be modeled as a model of responsibility for the patient license type, where Dr. Mark is responsible for John Smith.

However, the responsibility still brings complexity to the model, because the responsibility type is obviously much more than the organizational structure type. This will bring us the trouble of application: we need to develop rules for the new responsibility type-each responsibility type requires a rule! If you want to put this in the database, it will be troublesome.

Therefore, we also need to improve this mode by extracting data related to these constraints, which is independent from specific algorithms. "Analysis Mode" tells us a modeling principle: "The model is clearly divided into operation-level and Knowledge-level ". Many people refer to this "knowledge-level" as "meta-models", but Martin explains why he does not use "meta-models" to refer to "knowledge-level.

The knowledge-level code is described as follows:

 

Class AccountabilityType
{
PartyType Commissioner; // delegate
PartyType Responsible; // Responsible party
}

Class PartyType
{
AccountabilityType [] Commissioners; // delegate
AccountabilityType [] Responsibles; // responsible party
}

The operation-level code is described as follows:

Class Accountability
{
AccountabilityType Type;
Party Commissioner; // The entrusting Party
Party Responsible; // Responsible Party
TimeLimit Limit;
SomeAction [] Actions;
}

Class Party
{
PartyType Type;
Accountability [] Commissioners; // delegate
Accountability [] Responsibles; // responsible party
}

Once we have a knowledge-level description, we can easily use external code to verify the constraints:
All Party. Comissioners must belong to PartyType. Comissioners.
All Party. Responsibles must belong to PartyType. Responsibles.

With the concept of "knowledge level", our "Responsibility type" can be saved to the database. Of course, this division is not just intended to be put into the database.

We continue to improve the "responsibility model" because we encountered a new problem: Mr. Smith is a project manager and serves as a system analyst for the project for common reasons. Using the above model, we can regard Mr. Wang as a project manager or a system analyst, but not both. Of course, we have a lot of trade-offs to deal with this situation. We can also use the "Analysis Model" to solve this problem: to allow the group types to inherit from each other. In this way, we can create a group type of "Project Manager and analyst. The modified code is as follows:

 

Class PartyType
{
PartyType [] BaseTypes;
AccountabilityType [] Commissioners; // delegate
AccountabilityType [] Responsibles; // responsible party
}

 

Let's look back and evaluate whether the sequence "Head Office, regional branch, branch, and sales office" can be described in "responsibility model. This is because the "responsibility mode" is more relaxed than the direct id association method. Now we have used the above steps to greatly enhance the constraint capability. In this evaluation, it is to check whether our model is well compatible with the "old method", which is also a common verification method in the system design process.

We need to define the "Regional Branch responsibility type" to have the "Regional Management" Responsibility for the "headquarters, define "branch responsibility type" to have "Management Branch" Responsibility for "regional branch", define "branch responsibility Type 2" to have "Management Branch" Responsibility for "headquarters, define the "Sales Office responsibility type" to have the "Management of sales office" Responsibility for the "branch", define the "Sales Office responsibility Type 2 "..., define "Sales Office responsibility Type 3 ".... However, this definition is indeed too clumsy. Is there any better way to improve it?

Of course! We can expand a new "classified responsibility type", which can be used to define a "company hierarchy" Responsibility type, then, each level of the responsibility type is associated with the corresponding type in the sequence of "Corporation, regional branch, branch, and sales office" of a group type. In the analysis model, this type of responsibility is called "hierarchical responsibility type". In contrast, the type of responsibility we discussed earlier is called "hierarchical responsibility type ". In the analysis model, the difference between the two lies in: "The responsibility relationship of stratified responsibility types throws fire groups and forms a hierarchical model ", that is to say, "a group can have only one type of responsibility", while "Classification of responsibility type" is used to capture the Team Responsibility relationship with a fixed order ". The improved code is as follows:

 

Class AbstractAccountabilityType
{
PartyType Commissioner; // delegate
PartyType Responsible; // Responsible party
}

Class PartyType
{
PartyType [] BaseTypes;
AccountabilityType [] Commissioners; // delegate
AccountabilityType [] Responsibles; // responsible party
}

Class Accountability
{
AccountabilityType Type;
Party Commissioner; // The entrusting Party
Party Responsible; // Responsible Party
TimeLimit Limit;
SomeAction [] Actions;
}

Class Party
{
PartyType Type;
Accountability [] Commissioners; // delegate
Accountability [] Responsibles; // responsible party
}

Class LevelAccountabilityType // layered responsibility type
{
PartyType Commissioner; // delegate
PartyType Responsible; // Responsible party
}

Class HierarchicalAccountabilityType
{
String Level; // For example, 01020304 or aa. bb. cc. dd. ee indicates the Level position. However, here we only need to use the singular numbers 1, 2, 3, and 4, which is simpler.
PartyType [] Lists; // group type sequence

PartyType Commissioner; // delegate
PartyType Responsible; // Responsible party
}

The following section does not describe section 2.13 of the book "weigh the subtypes of responsibility types repeatedly", because the book does not seem to find a description of "oriented responsibility types, we can't find any available English version of the document to download. Thank you very much.

Finally, in the definition of the operation scope of the responsibility model, the concept that the responsibility model can introduce "positions" is proposed, and all responsibilities can be associated with positions, then I create an "Employment" responsibility model with my position. However, it is recommended that you do not introduce too much unless the position changes quickly.