To guarantee that a business model will be really accepted by its envisaged users, it must significantly ease the job of these potential users. It is therefore very important, that the desirable structure of the model is determined. The model structure will most likely be the major acceptance criterium for model users.
In general a selected structure has to:
But there are also specific requirements depending on the future usage of the model. Mainly these are the appropriate selection of:
The asumed usage in the context of this document is the derivation and specification of IS application development projects and the creation of the fundamental development documents (objectives, specifications, ...) for these planned business applications. The primary audience for the model in our case are therefore besides the business professionals who have to maintain and carry on the model the IS application planners and designers. The following decissions are based on that fact.
Probably the most important decission about a model structure is it's orientation. Not only because it is currently modern, I recommend object orientation also for the structure.
Reasons for object orientation.
Objects provide a good model of the reality adapted to the needs of a specific system. Each IT application system has to manipulate data and has to support business functions by providing procedures and guidance through the allowed sequence of processes. In former analysis and design projects structuring of problem domains was performed data or function oriented, where one orientation was normally dominating the whole modelling effort. Object orientation takes away this dominance and an object combines the two elements (information and function) as equally important features normally called "data" and "behaviour".
There is one aspect which must be kept in mind when talking about object orientation together with modelling!"Object" is normally a concrete thing which has a unique identity. When creating a model of a business domain, we are not really interested in the unique object (e.g. a specific invoice). Instead we want to show in the model a representation of all potential objects of a specific type. Such an "object type" is normally called a "class". Referencing the term "object" in the modelling context normally means "class".
Although the model has to be object oriented we normally need for a formal development project still the information oriented view to build the database and the procedure oriented view to build the application programs and the workflows. This means, that the model should provide two major diagram types:
The next step is to decide, which model components are needed and in which diagrams they show up. The following table lists the recommended components:
name description diagram class a business object type or one of its components as indissoluble combination of information and behaviour class attribute an information field as one of the features of a class none service an elementary routine defining a specific type of behaviour of a class none relationship a link between classes expressing a specific relationship or dependency between them class actor a party (organization) which performs actions in the business domain proc. procedure a sequence of activities which determines the performance of a specific business task proc. flow a link between procedures defining the sequence of procedure performance proc. event the output of an external procedure which triggers the performance of a model procedure proc.
legend: class = class hierarchy, proc. = procedure diagram, none = not directly shown in a diagram