previousnext


The JADE Model, a Specific Business Model Type supporting Model-Driven Development

Up to this point I have been pretty generic about the specification of a model structure because the things mentioned so far describe mainly what has to be recorded in a model and not how it has to be recorded.

To achieve a special type of structure which makes a business model easy to maintain needs also rules how things should be recorded and presented. These rules really do the trick, of course with the consequence that a model analyst now has to work in a more disciplined manner. I have defined the JADE model type as a business model type which primarily combines the information view and process view of a business domain using the principle of object orientation, but in addition it also uses a set of rules especially defined to achieve a very clear presentation of the business domains essential properties. This makes this model type extremely clear and expansible and by that superior to other model types.

The following paragraphs explain the rules established for the JADE model type with respect to classes and procedures.

Categories of Classes

In the JADE Model there exist not simply business classes like "customer" or "product". Instead business classes are split up in component classes and these components are categorized with respect to their function in a class decomposition as well as in a business object relationship. This categorization allows a specific class arrangement in the class hierarchy diagram. This is to make model changes and expansions simple.

The following categories are defined for a JADE Model:

category description
kernel class A kernel class is a class which represents a fundamental data concept. It therefore is always a top level class which has probably a lot of subclasses representing specialisations of the data concept. In real life there exist only a limited number of kernel classes. Examples are: Documents, Locations, UniqueObjects, and Parties.
subclass A subclass is a class which represents a specialisation of a parent class. Subclasses themselves may be subclassed. There is no limit for the depth of subclass levels. Example: "Book" might be a sublass of "Document" (kernel),
component class A component class is a class which represents an important part of it's parent class. A component class is something, which has to be treated as a closed set of properties which only can be attached to the parent or detatched from the parent as a whole. Examples for components are: Parent: Vehicle, Components: engine, body, ....
relationship class A relationship class is a class which represents a relationship between object types. Example: "Ownership" may be a relation between a "UniqueObject" and a "Party".
pseudo kernel class A pseudo kernel class is a class which represents a weak fundamental data concept. Weak means, that this data concept cannot exist on its own. It is a kind of special component of a kernel class. Example: DocumentItem. A document item (e.g. a paragraph) never can exist without it's document but it might have direct relationships to other classes.

How to find JADE conform class components

As explained before, a JADE model does not show complete business classes, instead it shows the business class components. Although this document's purpose is not to function as an analysis guideline for a business problem domain, I anyway want to draft how to find during the analysis process the JADE conform class components derived from the business objects observed in the real world. I do this because to find the right components is so important in order to build a good model.

Let me list the action sequence which should be followed:

  1. List the business objects you have found in the problem domain to be analysed. Derive from this list the desirable kernel classes and pseudo kernel classes to be used in the business model to be generated. Do this by trying to find a feasable high level abstraction to which the business class can be associated. Normally there are not that many. Good candidates for kernel/pseudo kernel classes are Document, DocumentItem, Party, Offering, UniqueObject, Location, and Time.


  2. Find the specialization hierarchy of the defined kernel classes. Derive it from the important properties you have observed by looking at the business classes of your problem domain. A specialization of a "document" for example can be a "contract", the "contract" again may have the specializations of "work contract" and "sales contract". Keep in mind, that according to object orientation rules, a subclass as a specialization inherits all the properties of its super classes.


  3. Find the proper components of your specializations. Good candidates for components are logically strong related property groups of a specialization which may appear even several times. A component of "car" as a specialization of a "land vehicle" which itself is a specialization of "unique object" may be the "engine", the "gear box",or the "wheel" (4 of them). Associate the components as high in the specialization hierarchy as possible. Keep in mind, that a component is an integral part of a specialization subclass, but of course a component itself may have components and specializations.


  4. Find the existing relationships between business classes and define the relationship classes. Keep in mind, that relationships may also be specialized and may also have components. To "possess" a car may be relationship between a "vehicle" and a "natural person", but recognize, that relationships always should be defined on the kernel level, because there is almost never a significant difference between a kind of relationship between various specializations of the kernel classes. An "ownership" relationship therefore can be established between "parties" and "unique objects" and there is no need to establish it between specialzations (e.g. between a car and a private person, or a ship and a company).

JADE class diagram arrangement rules

Having evaluated the proper classes it is now the question, how do we arrange the classes in a class diagram that conforms to the JADE model type so that the diagram can be easily understood by business professionals and also easily be used by IS application developers as part of their functional specification and design documentation.

All classes in the class diagram regardless of their type are shown as boxes. The relationship between classes is shown by a connection line. Before I present the arrangement rules, I first have to explain the existing connection line types and I also have to talk a little about cardinalities. Cardinalities express how many individuals of one type can be related to how many individuals of the other type.

In the JADE model type there exist 3 different types of class connectors:

  1. Specialization connectors, in information engineering also called "is a" relationship. A specialization connection in a JADE model type exists between a superclass and its direct subclasses. A specialization connection is always a one to zero connection, which means that an individual object of a supertype not necessarily must be a member of one of the defined subtypes but that an individual object of a subtype always is a member of its supertype. In other words: a vehicle can be a ship or a car or it can be nothing of both (because it is an aeroplane), but a car is always a vehicle.


  2. Component connectors, in information engineering also called "has" relationship. A component connection in a JADE model type exists between a class and those components, which are split of in order to show a specific property of the parent class. A component connection is always a one to many connection, that means an individual parent object may have many (more precise: any number including zero) components of a specific type whereas an individual component object always belongs to one individual parent object, e.g. a vehicle has 0, 1, 2, 3, 4.... wheels but a specific wheel always belongs to one specific vehicle.


  3. Relationship connectors, in information engineering also called "many to many" relationships. In the JADE model type a relationship connector always exists between a class expressing a relationship type (e.g. ownership) and the two (sometimes more) types between the relationship exists. In the model there are shown only relationship types and not individual relationships. But nevertheless a relationship connector is a one to one connector. That means a specific relationship of a certain type always exists between individual objects of a specific type. For example: the car with the registration number "xyz" belongs the party with the name "uvw".

Now as the kind of existing connectors between boxes representing classes are explained, I can carry on to the arrangement rules:

Rule 1

All kernel classes are arranged in a single horizontal row in the middle of the class diagram. If desirable the kernel classes can be arranged from left to right in ascending alphabetical order.

The kernel classes are the really important classes which form the backbone of the whole class diagram. The horizontal line on which the kernel classes are located divide the diagram into two parts. We will soon see, that these parts significantly contribute to the maintainability of the diagram. Kernel classes are not connected. Only pseudo kernel classes (as a kind of special components) are connected by a component connector to their parent class. The component connector starts at the right edge of the parent kernel class, goes to the right and ends at the top edge of the pseudo kernel class.

To rule 1: Arrangement of kernel classes.
rule 1

Rule 2

All component classes of a parent class are located to the right and one grid level below their parent class. If desired, component classes can be arranged from left to right in ascending alphabetical order.

Component classes are used to disclose specific properties of their parent class. They are connected to their parent classes by component connectors. A component connector starts at the right edge of the parent class. It goes to the right and ends at the top edge of the component class.

To rule 2: Arrangement of component classes.
rule 2

Rule 3

All specialization classes of a parent class are located below the parent class with an offset of one grid box to the right. If desired, specialization classes can be arranged from top to bottom in ascending alphabetical order.

Specialization classes are used to distinguish between specific types of the parent class. They are connected to their parent classes by specialization connectors. A specialization connector starts at the bottom edge of the parent class. It goes down and ends at the left edge of the specialization class.

To rule 3: Arrangement of specialisation classes.

rule 3

Rule 4

Relationship classes are located in the upper part (the relationship part) of the class diagram. The relationship classes are connected a) to the kernel/pseudo kernel classes which are the top level of the specialization hierarchy to which the classes belong, between which a business relationship has to be established, or b) to another relationship class.

Relationship classes are used to show existing business relationships between business objects. They are not directly connected to the specialization class representing the business object. Instead they are connected to the kernel (or pseudo kernel or in rare cases to another relationship) class which is the top level of the specialization hierarchy, a business object belongs to. This is to reduce the number of relationships by avoiding redundant relationships (see also: About relationship abstraction and its consequences for model maintainability). A relationship connector starts at the left or right edge of the relationship class. It goes to the left or right and ends at the top edge of the kernel/pseudo kernel/relationship class. It is allowed, that both end points of a relationship are the same class (e.g. a "party" of specialication "man" is "maried" to a "party" of specialization "women").

To rule 4: Arrangement of relationship classes.
rule 4

As stated above, the arrangement rules guarantee, that a JADE class diagram becomes very clear and well structured. To give an impression about the look of a really big JADE class diagram, the diagram of a project with 6 kernel classes, 1 pseudo kernel class, more than 25 relationship types and more than 200 specializations and components is shown in the picture below. This diagram has been generated (and automatically drawn) with the JADE Designer (see Downloads).

a big class diagram

What is behind the diagram boxes

The class diagrams of a model directly just show the class components and their relationships. It does not show the class features (information and basic object behaviour). 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 "class definition", the "variable definition", and the "method definition" dialogs as currently implemented in the JADE Designer.

Class properties dialog window:
Note: The dialog allows to incorporate any number of variable and method definitions.

class properties

Variables properties dialog window:

variable dialog

Method properties dialog window:
Note: The dialog allows to incorporate any number of parameter definitions via a parameter definition dialog.

method dialog

About relationship abstraction and its consequences for model maintainability

Under rule 4 I have stated, that relationships should be established only between kernels in order to reduce the number of relationships. This has to be explained in more details.

Let me take an "ownership" relation as example to make clear what I want to say.

In a business domain model you may have a lot of specialisations of "Party" (e.g. private person, company, legal entity, group, ...) as well as many specialisations of "UniqueObject" (e.g. building, car, tool, boat, aeroplane, ...). There definitely exist "ownerships" between most of that parties and objects. "Private persons" may own e.g. "buildings", "cars", and "boats" and of course also "companies" will own e.g. "buildings", "aeroplanes", and "tools". To establish an "ownership relation" for all these ownerships would generate a lot of different classes. No doubt about that.

But are these "ownership" relations really different. If you look more close at them, you will definitely find out, that they are all pretty similar and easily could be summarized under a single "ownership" relation "Party owns UniqueObject". This is so because a diagram shows relationship types and never individual relationships! That means, the diagram never shows that party "xyz" owns the car with registration number "uvw", it only shows, that in the business domain described "parties" are allowed to "own" certain "things".

In the JADE model type all relations are consequently pushed up to the top level of the specialization hierarchy - and there is no lack of clearness or loss of information. On the contrary, the diagram becomes very clear and it covers by that already facts which not explicitely have been modeled by the analysts. If there is really the need to show differences in a relationship, it easily can be specialized.

Look at the diagram to rule 1. It shows a relationship part and a specialization part. Due to rule 4 all relationship types are shown only in the upper part of the diagram, and if we are only interested in the relationships we can easily cut off the lower part, because it is really not important, what specializations are recorded. We know, any relationship established is valid for all specializations that may exist in the lower part. In addition, we easily can establish a new relationship, and it automatically covers all specializations that are already defined in the model and also all potentially upcoming specialisations. The establishment of the new relationship therefore does not affect at all the structure of the specialization part of the diagram, and that is a big contribution to the stability of the diagram itself.

But that is not all. We also can work independently with the lower part of the class diagram without jeopardizing the structure of the relationship part. That means, we easily can expand the specialization hierarchy of a certain kernel class and oh wonder, all relationships already established immediately become valid for this new specialization. We may add e.g. the new specialization "furniture" to our kernel "UniqueObject" and there is nothing wrong with the already existing "ownership" relationship, because all types of parties definitely may own "furniture".

No doubt, the arrangement rules make the JADE class diagram very clear because the number of required connections is minimized and due to the seperation into two relatively independent parts the diagram is realy easy to maintain.

Business object composition and unique identifiers

A JADE class diagram shows only classes which are business object type components as already mentioned several times. Nevertheless we must keep the individual business objects in mind, because that is what the business professionals see.

It must therefore be understood how a business object is described using the model constructs.

Primarily a business object type is represented by the specialisation class recorded in the model. If we want to describe an individual car, there should exist a class "car" as a (direct or indirect) specialization of a kernel class (e.g. "UniqueObject"). But the class "car" does not contain all properties which have to be recorded in order to describe a car sufficiently (not to say completely). There are properties which are recorded in the levels above "car" in the specialisation hierarchy. These properties definitely also belong to "car". And there are components of "car" itself and probably higher specialization levels up to the top level (the kernel). These classes also belong to the "complete" description of "car". A "car" really is a whole bunch of classes (kernel-, specialization-, and component-classes.)

If we have to describe a unique car, we have to generate an instance of all these various components and we have to record the unique properties in the fields of these instances. But whereto goes the unique identification of our car (whatever has been choosen to be the unique identifier of the business object), because only this unique identification makes the business object existing and distinguishable from other unique business objects.

There is only one logical place for this unique identifier and that is within the kernel class. Because all instances of all specializations of the kernel must be uniquely identifiable the identifier must be a property of the kernel. The kernel - as the top of the specialization hierarchy - is the only component which is always a part of a business object description. Only by that it is always guaranteed, that there exist no business object in the whole hierarchy with the same unique identification.

There is one final but important thing to mention:
There might be components which exist several times in a business object (e.g. the 4 wheels of our car). These components need to expand the unique identifier (e.g. by using a sequence number) in order to make them distinguishable.


Top of page
Table of Content

previousnext