Tagging the Model Zoo – Symbols for Model Conformance and Care

Modelling Object

What is modelled?

Obviously, we should know what it is we’re talking about. This question might sound a little silly, but consider that even the most simple object-oriented class diagram already raises the question whether it’s a description of the business domain or of the inner fabrics of some technical solution, or both a business system and an IT component at the same time balancing the forces from both sides (OO in a nutshell).

Here are three main categories that can serve as a start. Many more categories are imaginable.

In typical IT application scenarios usually used to illustrate the economical context of business or IT systems, more open and less (or not) controllable easily, the area of conventions, standards, laws or other regulations.

Business here denotes a company or an organisation, but generally any kind of a system with a well defined boundary within which coordinated, goal oriented activities take place and which in tis entirety is controllable by some defined group of stakeholders. A Business System or Component then is an entity on that level ob abstraction.

To represent IT parts as real-world entities which play a role in a business or maybe economical context. Note that the primary purpose and relation is not abstraction, but containment: an IT component can be used as a tangible part of a Business System.

Modelling View

From which perspective modelled, for whom?

The category of an object and the perspective of the model can differ, it is e.g. possible to describe an IT system from a business perspective as well as from an IT perspective, or from multiple, aligned perspectives at the same time.

Relevant aspects might comprise financial or product properties, demands, various flows of goods, cash or data, large scale social interactions.

Concerns like strategic and tactical management, organisation, operations, interactions, landscapes, and installations.

From the perspective of application production and deployment, application systems, os & web services, computing, hardware and alike.

Modelling Aspect

Which properties of the Modelling Object are modelled?

The function of the modelled object within its surrounding system, the reason why it exists or shall exist, goals that shall be accomplished with its operation.

The interface between the modelled object and its surrounding system, comprising other components; i.e. the outside view of its boundary.

The inner structural breakdown of the modelled object; in case of a business system that might correspond to its organisation, in case of an IT component to its architecture.

What happens inside the modelled object, which processes exist, which activities take place, how they are coordinated.

Detailed description of it’s inner workings, comprising implementation, functioning, data structure/schema, aggregate boundaries; rules, logic; aggregation; states, transitions, events; conditions, constraints, privileges; computations, algorithms; data transformations, modifications, transfer and retrieval; transaction boundaries; design, layout, styling.

Note: this describes only the intent, nature and possible amount of the modelled information, it does not imply that the information is described in e.g. a programming language, or that all these informations are necessary. Still, the long list might indicate that more thoughts need to be spend on this topic.

Bindings to commodity services, like user interface and database; a very abstract description of properties that enable such commodity services to provide the desired functionality; like ‘physical properties’.

Represents the infrastructure of the modelled object; for an IT component this comprises e.g. it’s  production, deployment or operations system (software development process, unit, artefacts etc.), the description of it as an artefact, it’s installation environment, analytics and alike.

Deals with the location of system components within landscapes, like physical placement or network addresses.

Modelling Genericity

How generalised is the model?

As mentioned in the first post, this might seem like a matter of more scientific interest, but misinterpretations arise from not clarifying that.

Describes an actual instance of something, e.g. a concrete and specific business system of the company one is dealing with, or a specific project, but not a workflow.

Describes some group of instances with similarities, the relation to the class is kept after instantiation. The canonical example surely is the (domain or programming) Class, also a workflow is likely a class (of workflow instances)

Describes some group of instances with similarities, no relation is kept after instantiation. A typical example is a modelling template that is to be filled out by the modeller.

Is an example that serves as an illustration or prototypical exemplification. E.g., a Use Case often serves as a mere sample.

Modelling Language

In which terms is it modelled?

The characteristics of the model and the language used for modelling, with regard to domains and abstraction levels. On the one end, there are DSLs which describe properties in terms specific to the problem at hand, in the mids are neutral languages with universal concepts, and on the other end are technical descriptions using concepts of the IT solution domain.

Specificities can comprise a range, either because the model does not separate concerns well enough, or intentionally, as desribed for the “good object oriented model” below.

The name of the modelling language.

The specificity of the modelling language (business, neutral, technical), i.e. the area to which the conceptions and terms of the language belong; a typically DSL might use business terms, UML is more or less neutral with a technical bias, and Java essentially technical.

The specificity of the modelled content (business, neutral, technical); e.g. a workflow might be business oriented, while a data transfer protocol rather technical – both could be described with one and the same language. Usually, this will be a subset of the language specificity, and derivations from this rule deserve a second look.

The specificity of modelled concepts (business, neutral, technical), which is the concepts we have in mind when describing our content; admittedly, this category is a bit nitpicking, nevertheless let’s include it: concepts and content might differ, e.g. a model described with architectural concepts can still be a good object oriented model that reflects a domain system and a technical system simultaneously, so that the modelled content is domain oriented as well as architecture oriented; also, concepts and language can differ, e.g. we might want to use Java as our single source for modelling and consider the modelled classes as describing our domain model.

Modelling Quality

How well is the aspect modelled?

The second part of the blurb provides the quality of our modelling effort. Of course, since presently it might be hard to find quantitative measures, a specification of these properties requires a good deal of honesty, with regard to others but also with regard to oneself. Within a healthy team, the classification can help to gain valuable insights.

How horizontally complete a certain aspect is, i.e. whether all parts of the modelled aspect are covered, leaving no open white spaces. E.g., a navigation model for a user interface can be considered complete if all pages are represented, since the aspect is just these pages and their relations.

(requirement 8, Modelling Coverage – how horizontally complete a certain aspect is)

To which degree all aspects of the described target are covered. E.g., a contemporary MDx model describing an IT system might comprise the business data and logic, but lack the user interface. A low system coverage is not necessarily a shortcoming, it might be intended and indeed be a sign of good separation of concerns, if the various aspects are covered in well separated models.

(requirement 9, System Coverage – whether all aspects of the target are covered)

How vertically complete the aspect is modelled, i.e. whether the details are described in the required precision. Even within full coverage the description can be vague, and sometimes this openness might be intended and justified, e.g. a workflow defining only a goal, but not the precise procedure of achieving it. In this case the indicator can be used to clarify if the openness is intended or whether not.

(requirement 10, Modelling Precision – how vertically complete it is)

A completeness of all aspects of 100%, of the system of 100%, and implementability of 100% imply that the corresponding component is fully specified and it should e.g. be possible to automatically create it.

(requirement 13, Modelling Quality – DRYness and SoCness)

Whily everybody would agree that DRY-ness is a natural goal, it is not just that most systems are far from truely DRY, but rather that the impact of DRY-ness is not questioned consequently enough. For starters, here’s a suggestion for a finer classification beyond just “DRY/not so DRY”.

For a given information artefact and with respect to a certain given concern (one of many), we can distinguish degrees of DRY-ness:

• DRY-3 – wildly distributed multiple times and therefore unmaintainable
• DRY-2 – mutiple occurrences
• DRY-1 – exactly one occurrence
• DRY-0 – no occurrence at all

For a given set of models covering some system and a given concern we would like to have exactly one model DRY-1 and all the others DRY-0.

The overall “DRY-ness” here on our tag then is some sensible average over all relevant concerns – good judgement provided.

(requirement 13, Modelling Quality – DRYness and SoCness)

The same observation as for DRY-ness holds for SoC-ness. Similarly, here’s a finer classification beyond “separated/not so separated”.

For two given information artefacts and with respect to a certain given concern (one of many), we can distinguish degrees of DRY-ness:

• SoC-4 – completely mixed up and therefore unmaintainable
• SoC-3 – separated but both parts refer to each other
• SoC-2 – separated but only one part refers to the other
• SoC-1 – separated but all references are via an appropriate abstraction shielded
• SoC-0 – not referring to each other at all

For a given set of models covering some system and a given concern we would like to have only SoC-1 or SoC-0 relations to the one and only model that covers this concern in a DRY-1 fashion, as described above.

Again, the overall “SoC-ness” here on our tag then is some sensible average over all relevant concerns.