Actions and Entities
2.8 Action vs. Entity
Download PDF The 2 primary approaches to functional analysis are through an action-oriented (also known as intentional modeling) or an ontology-oriented perspective. The action-oriented approach analyzes all the activities users will want to do with the system, and defines a functional model based only on the actions. The things that an action will use to fulfill its functionality do not need to be modeled, or at best, they need to be modeled only as abstractions. An ontology-oriented approach, on the other hand, is interested in the nature and details of things. A purely action-oriented approach is not concerned with things. Things are only treated as property values, and each action uses and modifies a set of properties. If I need to pack a thing, the action (packing) starts by obtaining the name of the thing (or some other unique identity), and uses the name to obtain all the property values it requires, such as the size and weight of the named thing. Logical operations are performed on these properties, without understanding the nature of the thing being packed. Let us consider a process for packing things into a box.
Figure 1: Using a purely action-oriented approach determine size of thing. Place the object on a flat surface. Measure the distance from the surface to the highest point of the object, and assign this to a length value. Draw a line in your mind between the 2 points where the object is at its broadest. Measure the distance between the 2 points of this line, and assign this to a length value. In your mind, rotate this line on a horizontal axis by 90 degrees, and measure the distance between the 2 points on the object along this line. Add this measurement to the width value. Assign the values for length, width, and height to a size value. determine weight of thing. Use a weighing instrument and determine the weight of the object. Assign the measurement to a weight value. determine optimal box for thing. Using the values for the weight and the size, find the optimal type of box to package the object. Each type of box has a size and a carrying capacity. Find all the boxes where the carrying capacity is 20% greater than weight of the object, and the size (length, width, height) of the box is 20% greater than the size of the object. If multiple boxes are found that meet this criteria, select the cheapest box. pack the thing into the box. Wrap the object in bubble-wrap, and place it securely in the selected box. Make sure that the object is not loose on any side, and use shredded paper to secure the object. Close the flaps of the box securely, and seal the box using clear plastic tape. If the flaps of the box do not close completely, remove the object from the box, and try and find an alternative box to pack the object. An ontology-oriented approach is interested in the nature of things. Actions are also a type of thing that use other things to fulfill functionality. Ontologies represent the nature of things as they are, and not necessarily for a single business perspective. An ontology of fruits will capture the fact that oranges have orange-coloured skin, that they can be peeled by hand, and that they have light-coloured pips.They will capture the fact that fruits are perishable and edible; that different fruits have different nutritional values; that fruits grow on plants, and that vines, trees, and shrubs are types of plants. If the fruit needs to be packed on tables, they will capture the fact that tables have legs, and usually have a flat surface. They capture the nature of actions, and define different kinds of actions based on their intent, objectives, business contexts, and results. There is a tendency for ontology-oriented functional solutions to become bloated, and offer limited value to practical business problems. The most successful ontologies are references. An encyclopedia is an ontology of information, usually arranged by subject area in alphabetical order. Dictionaries are ontologies of the definitions of words, arranged alphabetically. Ontologies can also be succint. The periodic table of elements is an elegant and succint ontology of the properties of elements. Ontologies, by principle, are developed independent of the actions that use them.Therefore, it is of limited value in building a business system on a purely ontology-oriented approach, as it is highly likely that the system will contain the characteristics of things that are never used in business scenarios. In reality, actions will always use objects, and using a combinatoin of action and ontology-oriented approaches produces the most flexible and pragmmatic results. I "pack" my "clothes". I "drive" my "car". Making an abstraction on the object-level, based on a common property, will help fulfill the objectives of the system. For instance, if I need to pack apples, oranges, bicycles, and computers into different boxes and pallets on either a steel-reinforced table, conveyor belt, or on the floor. A pragmatic solution would be do define a system that will pack things (an abstraction for apples, oranges, bicycles, and computers) into containers (an abstraction on all the different kinds of boxes and pallets) on a surface (an abstraction of tables, floors, and assembly line). The only properties that would be interesting would be the volume and weight of the things, the size and capacity of the containers, and the size and capacity of the surfaces. The only attributes that matter for the object are those that are used in the context of the action. Although a table may have legs, a bicycle may have wheels, and a computer may have semiconductor components, these properties are not of interest to the action. From the perspective of the packing action, the only interesting properties are the size and weight of the thing, the size and carrying capacity of the container, and the size, strength (total weight I can put on the surface), and the number of people that can work simultaneously on the surface. The main benefit of combining an action and ontology-oriented approach is its flexibility. The same action can be reused for different objects and different processes. If variations in the action are required because of the specific properties of the object, a few modifications to the object's properties and the action will suffice. For instance, fresh apples will start rotting in a few days if not refrigerated. Adding the property of being perishable to a thing, adding a property of being refrigerated to some containers, and modifying the action to use a refigerated containers for perishable things will satisfy the requirement. The new properties of the object are all based upon the fulfilling the requirements of the action. It could be interesting to capture the fact that apples and oranges are fruits, and all fruits are perishable, but this additional logic will not add any value to the action. Deriving an ontology based upon a fixed set of actions usually produces a satisfactory functional solution. However, actions are typically modeled from a single business perspective. In the example, perspecitve was oriented around the packing of things, and the interesting properties were those used when the thing was being packed. Things however, can also be sold, so it becomes important for things to have prices. Things can be sold on websites, so it becomes important for things to have pictures and descriptions for customers. The floor can be considered a surface if it is only used for packing things. But a floor can also used for storing things and parking vehicles. From the perspective of a business scenario that uses the floor to store things, it is not a surface, but a large storage area. Similarly, from the perspective of parked and moving vehicle, the floor is a collection of spaces and paths. Arbitrarily adding properties to the surface on the basis of new perspectives will result in an unmanageable functional model, and a rigid system. Most business systems are built from a single business perspective, and modifications are attempted later to suit other business perspectives. This results in a business system that fulfills one perspective well, and others poorly. Over time, the business system's shortcomings result in several business systems for each business perspective. Note: Some would argue that having a system for each business perspective isn't necessarily a bad thing. Each system can be specialized for a business area, and systems can work together through integration. This is certainly the view that organizations with a high quotient of legacy systems, or vendors of integration platforms, must take. However, the total cost of ownership, in terms of staffing, implementation time, service delays due to integration failures, maintenance, and support is much higher than a unified system.
Figure 2: Using a purely ontology-oriented approach The optimal scenario would be for a functional solution to consider all of the relevant business perspectives. Returning to the example, things need to be ordered, stored, packed, and moved. Each of these form a different business perspective on the same thing. From the perpective of the order, it is important to specify which size or colour of the thing is being ordered and the price of the thing. From the perspective of storage, packing, and logistics, it is important to know if the thing is sensitive to certain conditions (e.g. temperature, vibrations, etc.), the stability of the thing (e.g. fragile, flammable, hazardous, etc.), the size of the thing, and the weight of the thing. Given these perspectives, these are the only properties of "things" the system must capture. Note: Actions, within an enterprise architecture, can be translated as services, and the things can be translated into a domain model. The cummulative set of actions will form the basis of an enterprise service catalog, and the accumulated things with their properties and behaviour will form the basis of an enterprise domain model.
Figure 3: Using a combined approach
Download PDF
|
|
