As I have explained in the previous section, classes as the building blocks of business objects in an object oriented business model provide the complete set of information relevant to the problem domain as well as the business object's basic behaviour.
But to comprehensively describe a business problem domain this is not sufficient. If it must be guaranteed, that specific business tasks are always performed the same way and that business results are always correct, complete, and verifiable, it is not sufficient to just model the relevant business objects. It must also be described, what must be done with these business objects and the means for that are the "business procedures".
A business procedure is the description of a defined sequence of actions performed by specific organizations which deal with a certain set of business objects in order to achieve a specific business result.
Note: According to the definition above, the "business procedure" is a "type".
Similar to the "business object" as a uniquely identifiable instance of a "business class", the "business process" is a uniquely identifiable instance of "business procedure". A model does not comprise "business processes" because only the "type" is what is important in a model.
Whereas business classes are relatively stable and do not change very much over time, business procedures are relatively volatile. This results from the need of enterprises to permanently try to improve their way to handle their business.
There are two strategies primarily used by enterprises to achieve this improvement:
The procedure diagrams in the JADE Model are designed to support these strategies.
In an enterprise that operates in a disciplined manner a business procedure is defined and documented for each important business transactionen type.
These "business transaction types" are normally "owned" by a specific organization type within the enterprise. An organization type in this context e.g. may be a division, a department, a working group, or even a single person acting in a certain role. We therefore find procedure groups called "sales procedures", "production procedures", "administration procedures" and so on.
Normally the owning organizations are also responsible for the documentation of their procedures, that is they define how they want to handle and optimize their business. Because the way an enterprise is organized is so important in a business problem domain, the JADE Model provides a special diagram type to show the defined organizations.
A business procedure for a business transaction always should be an "end to end" description starting with the triggering event generated by a requester of a process and ending with the delivery of the produced result to the requester.
To generate the envisaged results some procedures need only a few actions, but most of them need a significant number of actions and are therefore relatively complex. These complex procedures in general generate a number of intermediate results and sometimes even need to go through iteration loops. To make them easier to comprehend, they must be broken up into smaller procedure steps, where each step defines a kind of checkpoint or milestone.
In most cases organisations do not perform all the defined actions of a procedure by themselves (that is their own personnel). It is very common that several organizations or sub-organizations contribute to a business process. This is another reason, why business procedures need to be structured into organisation related steps.
To enforce the performance of the defined procedures within an enterprise, a procedure of course has to be documented in a way acceptable to and useful for the potential performers.
Proper documentation of a procedure (or procedure step) at a minimum must comprise
It may also be useful to document some processing properties like the cost incured by a procedure step, and the processing time allowed for a procedure/procedure step.
In the JADE Model business procedures are documented by JADE procedure diagrams. These are in principle hierarchical "workflow" diagrams for which (similar to the JADE class diagrams) some rules have been established. Hierarchical in this context means, that the details of procedure steps are shown in lower level procedure diagrams.
The information requested for a proper business procedure documentation is provided in the JADE Model by the following components:
name description event the description "why" a process has started. organization the description of "who" has triggered an event, "who" has to perform defined actions, and "who" has to receive process results. business class the description of "which" business objects are generated or manipulated within a business process. This comprises the information and behaviour features of the business objects. action the description of "how" business objects have to be handled. This comprises the rules, under which the actions have to be performed as well as the entry criteria which must be fulfilled to start an action and the exit criteria which must be fulfilled to confirm that an action has been completed successfully with respect to completeness and quality. sequence the description "when" a certain action has to be perforemd within the complete sequence of required actions. means
the description of "what" kind of tools, programms, systems, etc. must be used by the process.
The JADE procedure diagrams have 2 major sections,
The diagram heading section is the top level band of each procedure diagram. It provides mandatory basic information about the documented procedure. This is the:
The activity section occupies the rest of each procedure diagram below the heading section.
The activity section again is divided into several horizontal bands. The top band is called the "Input/Output Object" band, the bands below are called "Organization" bands.
The organization band is designated at the left border by the name of the organization it is assigned to. The organization band defines the area within the diagram, in which the boxes are allocated that represent the procedure steps performed by this organization (type).
Note 1: There can only be one band for a specific organization in a diagram.
Note 2: There can be one specific band for external organizations in a diagram.
There is one special band in each diagram, the "Input/Output Object" band.
The "Input/Output Object" band shows the objects (defined as classes) that come from the "Outside world" of the procedure and are the reason to start the described procedure or that are produced or modified by the procedure and are delivered to the "Outside world" of the procedure.
The reason for the start of a procedure may come from inside or from outside the problem domain modeled by the JADE Model. If it comes from outside it is called an "event" (or trigger). In both cases the reason to start a procedure is represented by the object that is associated to it.
In the JADE Model an "event" (a trigger from outside the model) is something that can happen, but when it will happen, and if it happens at all cannot be predicted from inside the model. It is something that happens in the outside world (the domains not described by this model) which is of interest within the model. The "model" contains "sensors" which react to the advent of such "events".
The location in the "Input/Output Object" band determines the kind of object.
A top level procedure does not have input or output objects, but for (lower level) procedures, there may be any number (including zero) of input or output objects.
In the activity section there can be one "external environment" organization band. This (optional) band can be used to show external procedures, that are procedures of external organizations which are the source or the target of input respectively output objects.
The "standard" organization bands really document the activities that are defined by the procedure. They show boxes which represent the procedure steps defined in the diagram. A procedure step can be seen as a cluster of related activities.
Each organisation band of a procedure contains only those steps which are performed by the organization named at the left side of the band.
The boxes representing the sub procedures can be arranged in layers within each band, but the location within the band (or relative to boxes in other bands) does not necessarily indicate when the sub procedure is performed in the sequence of actions. There is no time axis in the diagram !
Each shown sub procedure box itself can be further decomposed and by that contain additional sub procedures associated to various organisation types. That means, for each sub procedure box there might exist one but only one lower level procedure diagram.
The performance sequence of the defined sub procedures is shown by connection lines. Again, there is no time axis!
Primary starting point for a processing sequence is always a input object box representing an outside trigger, because the recognition of an outside trigger event is the only reason to initially start a business transactions. And remember: all (really all, even administrative transactions) are caused directly or indirectly by an external reason.
Connection lines start always at the right edge and end at the left edge of a box. They therefore need no arrows to indicate their direction, and therefore it is allowed to place a sub procedure box "B" to the left of another sub procedure box "A" although this sub procedure "B" is performed after sub procedure "A".
Note: Because the diagram does not imply a time line it is no problem to define procedure iteration loops.
A starting point (represented by the input object(s)) is the "entry" point of a procedure. It really defines just a milestone within the complete performance of a business transaction. The local starting point just indicate for a specific diagram, where to start within the diagram if no external starting point is present respectively the diagram is opened as the decomposition of a higher level (parent) diagram.
End point for a processing sequence is either a box representing an "external recipient" or a box representing an "output object". It leads back to a higher level (parent) procedure.
The following diagram shows an example of a JADE Procedure Diagram.
As during business transaction processing each procedure step is invoked by a preceeding procedure step in a JADE Model it is the responsibility of a procedure step to determine, which step has to be performed next.
But where does the information come from, which is needed to determine which steps have to be performed next, if there are several alternatives.
Some information needed to make flow decissions is provided through fields of business objects handeled by the procedure step. As the business objects to be manipulated must be referenced in the procedure step this information can be used inside the procedure.
Other information (e.g. the unique identification of business objects to be manipulated) must be provided to the procedure steps from outside. Information is provided from outside to a procedure by means of the input object.
To document, which information is transported from one step to the next step, connection lines are used. Each connection line therefore may contain a number of fields, which can be used as parameters for the invocation of the following procedure step.
The procedure diagrams of a model directly just show the procedure steps and the flow defined to generate the envisaged business transaction result. It does not show the business objects, the manipulated information, the established processing rules and the processing logic. This information is provided in a JADE Model by property definition dialogs which are "behind" the boxes of the diagrams.
The following pictures show the "procedure definition" and the "organization definition" dialogs as currently implemented in the JADE Application Modelling Tool.