Examples of business modeling

In the last article, we discussed a lot about use cases, but when we implement them in enterprises, we often find it difficult to grasp the use cases of enterprises, which we also mentioned in the misunderstanding of use cases. In the actual situation, you may have no idea about the classification of roles, the division of use cases and the grasp of granularity, but these practical things have a great impact on your project.

In RUP, there are many concepts to support the realization of use cases: business participants, business entities, business use cases, business workers and business use case instances. In order to show business modeling clearly, we adopt RUP, the representative of UP method. But in practice, it depends on everyone's specific situation. The concepts mentioned here are to help you understand the modeling process, not to copy them mechanically.

Business use cases and business use case instances are defined in RUP as follows:

A business use case example is a series of operations performed in a business, which produce visible results for the protagonists of the business. A business use case defines a set of business use case instances. Business use cases have names.

First, you may have questions about business use cases and business use case examples. In fact, they can be regarded as the relationship between base classes and subclasses. In an enterprise, there may be many specific workflows. For example, when you go to McDonald's, the workflow of ordering hamburgers and French fries is different. Numerous processes make it difficult to investigate requirements. Even the oldest philosophy tells us that the superficial phenomenon is complex and the essence is simple. In order to simplify the demand work, we will order hamburgers and French fries as a meal. In this way, ordering food is a business use case, and ordering hamburgers and French fries is the corresponding business use case example.

The concepts of business roles and business protagonists are also easily confused. In fact, it is easier to understand their differences by their English will: business workers and business actors. Workers refer to workers and actors refer to participants. So the difference between them is that one is inside and the other is outside. The business role is the person who realizes the business use case, and the business protagonist is the person related to the business. For example, in the bill business of a bank, the customer is the protagonist of the business, and he is related to the business. The negotiable instrument personnel are business roles, because they are the people who realize business use cases. In RUP, they are defined as follows:

A business role represents a role or a set of roles in the business. When participating in the implementation of business use cases, business roles interact with other roles and manipulate business entities.

A business protagonist represents a business-related role, played by someone or something in the business environment.

The distinction between business roles and business protagonists depends on the environment. When you develop an enterprise's ERP system, all employees in the department belong to the business role, while when you develop a departmental application, employees in other departments may belong to the business protagonist.

In some articles, business entities are called BusinessObject. Whatever you call it, it means the same thing. Taking bank credit as an example, we involve many business entities: contracts, single loans, customers and so on. Therefore, business entities are very basic elements in enterprises. If you think the example of bank negotiation is not easy to understand. As you can imagine, the menus, hamburgers and so on in restaurants are all business entities. In RUP, a business entity is defined as:

Something that a business entity processes or uses on behalf of a business role.

A long time ago, we discussed demand variability. Compared with the ever-changing requirements, business entity objects have existed for a long time. The airline has a discount today and won't call tomorrow. There are also public discounts and secret discounts. But the ticket has never changed much, only a few attributes: price, flight, origin and destination. Therefore, the operating entity is relatively stable. This means a lot to us:

A business entity usually represents something valuable to multiple business use cases or use case instances, so the life cycle of business entity objects is quite long. Generally speaking, a good business entity does not contain information about its users and usage methods. (RUP)

Business users composed of business entities will be much more stable. The previous development method was based on modules, and when the requirements changed, the modules had to be rewritten. If stable business entities are used to realize business use cases, then the change of business use cases only needs to recombine business entities. Of course, there are still many technologies to achieve it, and it is not that simple. You know, the four modernizations cannot be realized in one day.

There is another important reason for using business entities: the characteristics of business entities determine that they are reusable in nature. Just like McDonald's sales system, production system and supply chain system all have Hamburg entities. God, what a beautiful world!

One of the biggest puzzles in using business entities is whether they should be regarded as classes or properties. It depends on how much the business environment attaches to this entity. Customer is a very important category in the bank credit department, but it is only an attribute of the letter of credit instance in the bill department. This question is very important. Design mistakes may lead to great pain in future system improvement. For example, business entities that should have been designed as classes are designed as attributes. When adding attributes in the future, they will face database adjustment and system modification.