Business modeling
Lin Xing (IAMLINX@21cn.com) December 2003
Business modeling is an important part of OOAD. It is simple to say that business modeling is structurally described on business domain issues. This description will directly guide the final generated software, whether the business model has scalable, whether the business model can reflect the demand, will affect the quality of the final software.
1. Business modeling 1.1 Why do you want to model it? We put this concept of business modeling in the final part because object-oriented is the basis of business modeling. Object-oriented is a technology that simulates real life with a computer language. The traditional language is timing, the language of computer viewpoint, and the familiar social views are different. This is not a big problem in the early stations of software development, but when the size is getting bigger and bigger, the speed of change is getting faster and faster. People found two concepts conflict. For example, the order is an universal business noun in the human society, which is quite stable. Different only the processing rules are different, but in the traditional language, the nouns of orders are not the focus of concern, and the focus of concern is in turn in the order of the order. The processing of the partial part is unstable, so it has triggered a problem. Object-oriented adoption of the real world system thinking, focusing on the type of order, and constructs the architecture of the order type, then establish a rule. Therefore, the frequency of change in the real world is basically consistent, and it is easier to change. We have previously discussed the object-oriented abstraction. We know that object-oriented is used to describe the real world, and his abstract level is too low. Therefore, there is a component technology. Component technology promotes loosely coupled and coarse particle size, but he is in essence and object-oriented and there is not much difference. The key to business modeling is how to use object-oriented technology to describe the real world. 1. 2 Business modeling and database modeling Many people have experienced data-based applications. After the demand analysis is completed, the data model is immediately established, based on data model construction applications. This is a typical approach to this application. With advanced tools, it can achieve high development speed, so this method is used in a large number of software in CS mode. The basic idea of this method is to use a database to represent a business model. But what we need to think about this problem, is it a database that can be completely competent? We discuss our most widely used relational databases. We know that the basic principles of relational databases are collective. The design is completed by defining the relationship between the two-dimensional table and the use of Cartesian product definition. This has a certain similar thing with our real life. This is a natural thing, because mathematics itself comes from life, and the basic theory of software is mathematics. For data, it doesn't make much sense, you can explain the meaning of the string below?
"Hong Kong XX Trading Co., Ltd."
The answer is not, but the definition of the table name and table field through the database, we can roughly calculate his application range:
Table Name:
Client column name:
Chinese name "Hong Kong XX Trading Co., Ltd."
We know that this string represents the Chinese name of the customer. But unfortunately, this definition is still not accurate enough, it should be admitted, it is useful, but it is not a lot, but it is no help to the business. The description that is really helpful to the business should be:
"Hong Kong XX Trading Co., Ltd. is one of the top 10 customers of the company, we need to give it a better discount.
The payables of "Hong Kong XX Trading Co., Ltd. have expired, and the customer's credit rating must be reduced.
These things are not available in the database. Of course, now the development of database technology has a thousand miles, many databases use different technologies to help customers handle business rules on their databases. But the database is not good at handling things, and it is not necessary to force it to implement on the database. These things should be processed by object-oriented. Because object-oriented is the perfect combination of data and operations, there is a defect for object orientation, which is very low, so the database is still an object-oriented best partner. Therefore, we have Oromapping technology, and later have JDO technology. These are designed to enhance communication between object-oriented and relational databases, because the design theory of them is different, so they are born in a large partner, and they are not helpful with the help of the intermediate level. In the agile methodology, there is also a technical technology to study the database, which shows the importance of database technology. 1.3 During common and differential business modeling, finding, distinguishing between commonality and differences between different things are critical. Two business entities, there is impossible to have only commonality. If so, there will be only one business entity; in turn, there is impossible to differ between them, all things in the world are related. Ten thousand steps to say that at least one organization's business entity is a business entity, which is their commonality. The correct analysis is performed in the business model, and it is possible to lay a solid foundation for the subsequent object-oriented modeling. If this is not good, you will find that you are using the object-oriented technology to write the code-oriented process. 1. 4 Do not mix the table and business entity as a talk about business modeling, business entity is very important. Almost all business models are manifestative as a collaborative relationship between different business entities. JILL Nicola plays four collaborative types in his business object modeling and collaborative mode, and 12 collaborative models are evolved. It should be said that his intentions are classified by business models, and their goals and GOF design patterns are similar. But the business model is facing, and it is a variety of phenomena in the world. It is easy to classify them. Therefore, Jill Nicola is only only able to make a thinking, but this is very valuable to business modeling. Many developers are easily mixed with tables and business entities, but there is no connection between them. As the relationship between business modeling and database modeling is as discussed above, the database is just a means of implementing business model persistence characteristics. The one-on-one map of the business entity is mapped, sometimes it is right, sometimes it is wrong. The design of the business entity must begin with demand, to the domain model, and the table design is based on the principle of processing of the database. A order entity, there may be two tables in the database, one is an order, one chapter is the order. Many times, the granularity of the business entity is greater than the table, but it is not necessarily, for example in ORMApping, a inherited tree often maps into a single table. So there is no necessarily link between them. In the business modeling, simply consider the design of business entities. When modeling, simply consider the design, do not confuse both. 1. 5 Warning of the design of CRUD types This problem is the essence of the database is the conflict of database design and business model design. From the point of view of the database, no business is not more than new record, modify the record, delete record, and query records. So tools like Powerbuilder, can be able to stand up with excellent data form. But this point is that it is very taboo in business modeling, why? For any business, the processing of records is not the foundation of the problem. Added records must be accompanied by an occurrence of a business, such as selling a product, a newly registered a user.
This kind of means is meaningful, and users don't care about the records, they only care about business problems. So, if your business model is full of crud designs, this shows that you look at the business model, you still stay at the level from the relational database to see the business. This problem needs to be noticed during the software development process. Simple crUD method often means that the demand is not properly understood, and the model may miss the demand. We imagine an AddORDER method for adding an order record, which elements do you need to fill in? Do you need to check if a customer's credit record is needed? Do you need to check the inventory of the product? Business rules in real life are complicated, and it is impossible to be so simple. So, now you can check to see your system, do you have a lot of CRUD design? 1. 6 Make the design close to the real world this is not absolute, for example, theoretical human birthday is unable to adjust, but in the world's world, it is necessary to provide a way of modifying birthdays to correct entry errors. This problem can be understood. For software systems, there is no business model such as creating people. This is the secret of life, not the software system to simulate. Truely meaningful business model should be a business model such as new employees, so modifying files and modifying employee materials is allowed. 1. 7 Explicit Interface and Implicit Interface Imagine a User Management Model to provide a specific customer's interface, different search criteria use different parameters: Customer getCustomer (int CustomerID)
Customer getCustomer (String Customername)
Object-oriented can support overload characteristics, so this way is quite elegant interface. For users, the interface is unified, the compiler can prompt you to use the appropriate overload method and help you check the type. The problem is that there are some conditions with the same parameter type, which is departed from the overloaded requirements, for example:
Customer getCustomer (String Customername)
Customer getCustomer (String CustOMeraDDR)
At this time, we need to change your ideas and turn the interface to explicitly definition:
Customer getCustomerbyName (String Customername)
Customer getCustomerbyaddr (String CustomeraDdr)
When the number is small, this explicit interface is also very advantageous, because the method name is clearly intended, and the user does not need much way to use the appropriate method. So we see the design of the method here is very important, and the consistent style of the team inside the team is equally important. If you get a dozen filter conditions, we find that the method of displaying the interface is problematic, the method list is too much, the user is difficult to use, and the selection logic has begun to disperse, not easy to expand. If a business method is complex to this extent, we believe that it is much more improving to improve the method. Our idea is to convert explicitly to implicit interfaces and abstract the concept of filters. Please note that the purpose of this is the same, it is to obtain customers, but their filtration conditions are different, so in order to improve abstraction, we will express the commonality of filtration conditions, this is the filtering condition itself. This is the object-oriented power, whether anything can be abstract to some extent. So we introduced a new filter object, Customerfilter. Note that I don't name it, because I think filtering is a common feature, many objects have this feature, so I hope that when the conditions are mature, I can draw a base class from Customerfilter, can Use it for the design of the OrderFilter. So my name is there in the future, but I don't implement it now, because reconstruction and automatic test technology can help me soon realize Filter, I am not worried about this. Luo Rio said so much, let's take a look at what is the last method: CustomerFilter Customerfilter
The display interface and implicit interface exists in a large number, you can't disclose which method is better, and any way has its value. What we do is analyzed according to the situation to determine which method is used. So, how does the filter implement it? The most important thing in the filter implementation is to implement the filter rules. Similarly, the design here is also a trade-off. The most standard approach is to use regular expressions, such as "Name Like M *", so that the filter itself only provides a narrative of expressions, and performs a grammatical check, the class receiving the filter needs to implement filtering. Similar operations are provided in many systems, so it can be fully utilized when designing. In Martin Folwer's analysis mode, another filter design idea is mentioned, encapsulated filtering rules in the filter, because the filtering rule is encapsulated in the filter, so the filter must provide a query method:
Isincluded (Customer ACUSTOMER)
Every time, the class that provides Customer needs to ask the filter, is this customer in the filter? The filter answers. The advantage of this approach is to provide greater flexibility and can achieve very complex filtering rules. But this filtering rule generates a complex filter class, which is not a good news. You can use a simple case statement, or subclass, etc. to implement filtering strategies. 2. Regulating business modeling does not have a norm, different people, different problems, and final design results must be different. At present, the way to receive it is to record through the form of the pattern, discuss a business model. For example, we consider the bank's operators to handle a business. This process activity can use the classic participant-transaction mode to describe: a role handles a transaction, and this transaction and related personnel need to record This situation is suitable for use in Participant-Transaction mode to solve. The model is ideal for a particular environment to make it very suitable for use in business modeling, and it can also give implementation under specific technical platforms to achieve the purpose of the specification code. 3. Organizational business modeling organization and reuse organization issues are extremely similar. 4. The initial model of the process maintains a stable state is not realistic. Therefore, it is not a good practice to spend a lot of time in a perfect business model. At the beginning of the project, the parties of the participating projects are low, and they cannot understand each other's work. The developer can't understand the problem to be dealt with, and the demand side does not understand the final appearance of the software. The water source has been dirty, and the downstream is also clear and limited. In this case, how much stability do you think of the domain model? However, if the business model is not able to determine quickly, it will affect subsequent activities. Therefore, during the development process, it is very important to the reconstruction capabilities of the original design and code. Specifically, in the case of demand or more clear, it is necessary to modify the original error or insufficient design and code, but can ensure that the original function and quality can be guaranteed while adding or modifying the original software. Therefore, why iterative ideas is not easy, is because subsequent changes are prone to previous architectures. In an application, business models are often the core of the entire software, so the ability of software reconstruction directly represents the ability of business model reconstruction. For us, the business model should be as stable, less changes as possible, and on the other hand, we ask the business model to make quick changes to adapt. Therefore, the design of the business model has made several requirements: 4.1 Building an automated test network for business models We have said that the business model is the core of software design. Any bottom problem will feed back to the business model, while business models and demand are very close, so the design difficulty of test cases is relatively low. We know that the most difficult test work is how to weigh the test workload and software quality, focus on the power of the test in the business model, can have good results (this is not said that other parts do not need testing, unit test The main idea is to test what you can test. However, this test also needs to pay an additional price. The most typical is the establishment of the test environment. Because it is a business model test, it is impossible to be easy as the unit test, so there is a comprehensive test data and test plan. This work should be placed in the class design of the business model, becoming a part of the progress. If the business model is very related, it is also considered as whole. 4.2 Holding a unified business model is often strong, and this trend will become more and more obvious. Why ERP will be so complicated because the business association is very complicated. Therefore, we will put less and fine power in business modeling activities, maintain a unified design style.
This is very important. If the design idea is not unified, it will have a big impact on the business model. 4.3 Audit Due to the importance of business model, it is recommended to strengthen the review of business models at each iteration. In particular, the impact of assessing business model changes on software design. 4.4 Progress estimation, progress estimation can also be performed based on business model. Because the granularity of the business model is moderate, the distribution of progress is relatively easy to perform. Reference Design Patterns: Elements of Reusable Object-Oriented Software. Gamma, E. Helm, R. Johnson and J. Vlissides Addison-Wesley 1995. 中文E: "Design mode: can be used for object-oriented software foundation", Li Yingjun, etc. Translation, Machinery Press September 2000. J2EE core mode Deepak alur, john crupi, dan malks Niu Zico, etc., Machinery Industry Press. Effective Java Programming Language Guide. Joshua Bloch 2002 Chinese version: "Effective Java" Pan Ai Principles, Machinery Industry Press, January 2003. [Kel 96b] Wolfgang Keller, Jens Coldewey: Relational Database Access Layers: A Pattern Language, Proceedings PLoP '96, Allerton Park 1996. [BMR 96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal: Pattern -Oriented Software Architecture - A System of Patterns; John Wiley & Sons Ltd., Chichester, England, 1996; ISBN 0-471-95869-7 [Fow97] Martin Fowler: Analysis Patterns- Reusable Object Models; Addison-Wesley Publishing Company, Reading, Massachusetts, 1997; ISBN 0-201-89542-0 [Fowler, Roles] Fowler, Martin. Dealing with Roles, http://www.awl.com/cseng/titles/0-201-89542-0 /awweb .htm [fer00b] EB fernandez and x. yuan. "Analysis pattern for the order and shipment of a product", procs. of plop 2000. http://jerry.cs.uiuc.edu/~plop/plop2k [fer00c] EB Fernandez. "Stock Manager: An Analysis Pattern for Inventories, Procs. Of Plop 2000. http://jerry.cs.uiuc.edu/~plop2k refactoring to patterns Joshua Kerievsky 2002 About the author Lin Xing, Chen Yun Software Studio Project Management Group Senior Project Manager, has many years of project implementation experience. Chen Xun Software Studio is committed to the application of advanced software ideas, software technology applications, main research directions lies in software process ideas, Linux cluster technology, OO technology and software plant models. You can contact him by email IAMLINX@21cn.com.
