Discussion on semantic modeling

Add a comment

A recent discussion with an architect on the semantic modeling approach gave me the opportunity to answer some key questions. It also enabled us to review a document that defines the semantic model, soon to be published on the Praxeme Institute’s web site. Extract.

Inheritance (IMHO) is not a business concept, so I would not introduce it in semantic modeling. Inheritance is used to simplify code. Only in very rare cases is inheritance seen in real life (such as the relationship between parent and child).

[DVAU] “Inheritance” certainly is a technical term but the inventors of the object-oriented (OO) approach consciously introduced it, as it corresponds to a very natural mechanism, introduced by Aristotle, known as “classification”. I agree that it is not a business concept but, classification is a tendency of the human mind that even young children master, as soon as they are able to recognize that tables and chairs are furniture…
Anyway, even if it plays a role in semantic modeling, it is not the purpose of this document to introduce these kinds of details.

How will you ensure the consistency of the model throughout the whole enterprise, taking into account that the same business concept can mean different things to different users (e.g., “customer” means somethings different in marketing, legal, claims…)

[DVAU] Good point! In fact, the methodology proposes another place for that, which I used to call “pre-modeling”. The more positive term is “scoping” (coined by Philippe Desfray); sometimes, we refer to the “political aspect”, emphasizing the values and strategic objectives. Before establishing the models, we capture the vocabulary (I should use the plural: vocabularies) and welcome diversity in the shape of dictionaries. It is at this stage that we encounter the ambiguities of language and business representation. The semantic model (or other models) then formalizes these differences, eliminating all ambiguity.
For instance, there will be many occurrences of the term “customer”, each one related to a specific context. One occurrence will be assumed by the “Party” class; another one by an association role or a class “Role”, etc. In each case, we keep the relationship between the term (terminology element) and the modeling element: that’s traceability.

Separation between object domains and functional domains is very relevant (IMHO). It will (in the more technical layers) result in the separation between:
o the data and the related methods to manipulate this data (in OO concepts: the object)
o and the way to manipulate/combine this data into useful information (the application) to achieve business goals (e.g., selling products)

[DVAU] Yes, it is this distinction in the business representation that helps to structure the IS system. The first place is the logical aspect where we distinguish a “Core Business” stratum and an “Activity” stratum. The former derives from the semantic model; the latter is populated by constituents which come from the pragmatic model (use cases…).

What is the difference between the semantic model and business domain model?

[DVAU] The semantic model is situated at the same level that the conceptual model of traditional methods was. When we refer to business models, we tend to overuse the process approach or use-case approach. Both pertain to the functional culture that describes the business in terms of activity. When identifying the semantic model, we force ourselves to produce a separate description of the essential knowledge, independently of how business actors behave.

 MDA (model driven architecture) is a very powerful way to convert diagrams into working code (to put it very simply), but besides having a very good model there are other prerequisites.

[DVAU] Totally agree. We have to clarify all these prerequisites (appropriate technical framework, “logical/technical negotiation”, good tools, skills, administration procedures… To put it in a nutshell, we need a comprehensive methodology that clarifies the responsibilities and that is embodied in a chain of tools.)

This entry is filed under methodology. And tagged with , , , , , . You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.

  1. No Comments

Please leave these two fields as-is: