The origin of Microsoft Dynamics AX glossary entries

When I ask stakeholders to contribute entries to the Microsoft Dynamics AX glossary, they usually ask me this question: Which concepts and terms should I choose for the glossary?

The most straightforward answer I offer to this question is: The concepts and terms that appear in your conceptual object models.

In this blog entry I thought I would spend some time exploring my answer in more depth.

Our terminology process supports the practice of identifying concepts by using the fundamental tool in our development toolbox—the conceptual object model.

The conceptual object model is the first place where we start applying domain concepts and terms in context of the development of functional specifications. We use the conceptual object model to define and describe object structure and behavior in the real world. The conceptual object model describes the domain, not the Microsoft Dynamics AX product, and it presents the problem statement without any ties to the Microsoft Dynamics AX product by using precise domain-specific terminology—that is nouns and verbs. The conceptual object model is elaborated by using the Unified Modeling Language (UML).

The same terms that are used in the conceptual object model are subsequently used in the logical data model, which is a refinement of the conceptual object model. The logical data model model does not use verbs. It represents data only, and it adheres to data redundancy and integrity design guidelines. The logical data model is elaborated by using the Entity-Relationship (ER) modeling language.

The same terms that are used in the logical data model are subsequently used in the physical data model and physical object model. These models are the realizations of the logical data model and the conceptual object model. The verbs that are used in the conceptual object model are realized as class methods in the physical object model. The physical data model is elaborated by using the ER modeling language, and the physical object model is elaborated by using the UML modeling language.

Our practice is to iterate on the conceptual object model until the concepts are accurate and precise with respect to the real world and domain and until the terms (nouns and verbs) that are used are accurate and precise with respect to the domain.

After the conceptual object model is finalized, the glossary entries are ready to be authored. Because we used nouns and verbs in the conceptual object model and these elements, combined with the UML modeling language, form sentences, we can author the glossary entries by reading the conceptual object model.

It is the conceptual object model that is the origin of the two elements—the concept definition and the term—that comprise the entry that will appear in the Microsoft Dynamics AX glossary.

Show-and-tell: Aligning the conceptual object model, concept definitions, and terms

In this section I offer an example of an elaborated conceptual object model and the concept definitions that we authored by reading this model.

The following example is a conceptual object model that we diagrammed and elaborated for the concepts of measurement.

 

Using this conceptual object model, we defined and validated the following named concepts:

• dimension –  A classifier that characterizes the magnitude or extent of a
  quantifiable property of an object.
• magnitude – The numeric component of a measurement.
• measure – A property of an object that can be quantified numerically.
• unit of measure – A division of quantity established in calibrated or normative systems of
  measurement.

Just for fun . . .

If defining concepts in context of conceptual object models is a new practice to you, perhaps you might want to give our practice a try.

If you have a few spare minutes and are interested in applying our practice, you could select another concept from the preceding conceptual object model and define it in context of the model and its domain.

If you have any questions, please ask. I would be glad to address them.