Analysis and Design of Business Behavior

Analysis and Design of Business Behavior

Author: Anders James
Synchronized from: http://www.blogjava.net/AndersLin/archive/2006/12/23/89648.html

Complex business behaviors are generally seen as a collection of complex rules and processes. The basic solution relies on the basic way of thinking: decomposition structure.
The first element of decomposition is object-oriented cohesion. Usually the object-oriented theory tells us that the design principle is: What is this object. This method is suitable for domain model or, but it is not suitable for objects corresponding to the service or application layer. The most typical requirement of this type of object is a process! The biggest feature of process description is to tell us how to do it. When we apply object-oriented design, what needs to be done as opposed to what to do.
1.1 split the line for the first step of all work:
The decomposition process (means) has two levels:
Level 1: break down the logic into objects of different inheritance systems;
Layer 2: break down the logic into different abstract layers of objects in the same inheritance system.
The internal theory of two levels (means) is: what is actually a Behavior Abstraction, and as we know, abstraction is layered and arranged. The first layer of decomposition is to solve the top-layer abstraction, while the second layer solves the abstraction of the lower layer. Such repetition can complete the entire logical abstraction arrangement.
However, sometimes I would rather use another more practical statement to explain this practice: using object-oriented methods, focusing on what to do to determine the abstract model, how to break it down into the derived types of the abstract model.
Whether it is what you do or how you do it, you must note that there is an implicit concept projection at the knowledge level and its projection at the operation level.
Next we will face other technical problems.
1.2 determine logical composite operation relationships
In the process of decomposing behavior, we first divided and solved different object systems. In terms of knowledge level (analysis level), the work has been completed, but at the operation level (design level) we still need to solve this problem.
Different object systems have two types of roles in the system: caller and called. Because of the derived system of the caller (how to do it differently), the caller is faced with a choice to select one or more suitable called objects.
There are two ways to choose: Design (deployment) and runtime.
The design time (deployment time) is very simple. Writing a specific derived type in the program is basically a hardcode. Generally, the leaf node of the caller's object system directly calls the leaf node of the caller. At this time, the caller is passively selected and handed over to all callers (usually leaf nodes). Each caller adopts a suitable logical operation combination.
The other is that during runtime, the caller selects an appropriate action or group of actions based on certain rules. Generally, the specification of the corresponding caller is determined by external entities such as databases, factories, and reflection.
Active selection can be simple if... Else... When there are many influencing factors, the decision table can be used.
The two are compared as follows:

	Matrix/Decision Table	Object-Oriented Approach
Advantages:	Straightforward and clear information;	As the related factors increase, the maintenance complexity curve increases slowly, lower than the matrix and decision table. It is relatively clear in comparison with, or, non-computing. hierarchical structure is helpful for learning;
Disadvantages:	As the related factors increase, the maintenance complexity curve increases rapidly. However, it is unclear about the sum, or, non-calculation;	The acquisition of relevant information is not clear;
Nature:	The plane structure of the arrangement and combination. This is the root of its advantages and disadvantages;	Hierarchical Structure of arrangement and combination;
Development:	Determine during operation, and the change-related factors have a significant impact on development;	Determined during deployment and clear runtime Structure

In terms of maintenance costs, polymorphism should be considered. The system design may not be implemented using object-oriented programming, but at least the object-oriented approach should be simulated in the process and computing design;
1.3 rules under Behaviors
The decomposed behavior includes various rules, including the specification of selection, specification of validation, specification of build, and specification of calculation.
Except for the last two actions (excluding the source of their parameters), the other two business rules themselves have three implementation methods:
A) polymorphism (Object-Oriented ).
B) simple decision table (ing table). Save the route selection with the displayed row table (and relationship) (determined at runtime ).
C) tree-like decision table (ing table). Use the displayed tree table (and/or relationship) to save the route selection (determined at runtime ).
1.4. asynchronous Behavior Decomposition
Most of the Behavior Decomposition is synchronized! However, in a complex system, asynchronous decomposition of behaviors still exists. This design looks more like data flow pattern. There are different reasons, and some are for performance reasons, some examples can be seen in the Financial System for business reasons. For example, to ensure the existence of key business data, there are usually some prices or interest rates that are requested during the day, it can be divided into two steps. The first step must be completed even if the second step is completed at night ).