Active Knowledge Modeling

With model-driven applications in Oslo, Microsoft aims to reduce the amount of code needed for custom applications by 90%. Recognizing that “the model is the application”, they envision a move away from the model editor as a separate tool for developers. In our perspective, UML is a visual programming language and Microsoft’s M is a textual modeling language. To be accessible to business users, a visual modeling language is needed.

From my experience I’ve come to realize that modeling languages for software development such as UML are not ideal for this model-driven applications. Recently, Microsoft seems to have come to similar conclusions. Their software factories approach and the Oslo platform takes several steps in the right direction, following some of our active knowledge modeling principles. In particular, we find it promising that they are looking at more mature industry sectors for advice. More insight from design methodologies, with concepts like concurrent plant and product design, product lines and families, mass customisation, functional deployment, and parameter balancing, could greatly improve software development practice. Industrial data modeling also offers a far deeper understanding of e.g. classification and property modeling than what is common in the IT industry. (For a while during the 80s and 90s the term software factory was hijacked by a research community that believed software development could be automated based on formal models of the development processes. Microsoft’s approach should not be confused with these misconceptions). 

Microsoft’s M, like UML, is designed as an abstraction of underlying programming concepts. However, while UML is commonly presented as a high level modeling language, M is recognized as a programming language. This seems the more insightful position, one that does not confuse the real world with computerized representations of it. From the material on Oslo, I’ve in particular been impressed with the simplicity, power, and customizability of the Quadrant modeling editor, as shown in this video from PDC.

What makes Oslo more suited for model-driven applications than UML, according to our modeling principles?

• Better support for instance modeling. M separates the typing of data from the storage (extent) of the data. The database interface MSchema thus maps extents to database tables, not types like most OO methodologies would. M supports naming or identification of instances (entity values) the same way types are named, and properties may be defined locally for instances just like for types. Most importantly, M sees every instance as a member of a type if it possesses the properties of the type. This is called structural typing. Values have no notion of which types are used to ascribe them. Such derived classification handles evolution and multiple views a lot better than OO methodologies enforcing the single instantiation class constraint, treating instances as second class citizens controlled by their type. However, duck typing would have been even more flexible, checking only against the features applied. We also prefer dynamic typing, checked at runtime, to the static approach taken by M. True model-driven applications cannot separate runtime from design time …
• The M language specification starts down-to-earth with values, and then derives more abstract concepts such as types and extents from collections (sets) and entities of values.
• The software factories frameworks are based on templates and patterns as reusable elements, rather than classes to be instantiated. Though Oslo is based on similar ideas, it is still too early to judge whether the tools, e.g. the visual editor Quadrant, provides services for template use and management. Adaptation and binding of patterns into the local models where they are to be used, is another challenge. The M language lets you define constructors for entity types, and with structural typing it is no problem to define a type for each template. Entities that have the same structure would still be recognized as belonging to the same root type, even if they were created from different template types.
• Classification is complemented by data-driven categorization, where new types can be defined as queries over existing types, in combination with set operations such as union and intersection, and entity operations such as projection and join. If only MSchema had created views from such type definitions, user-defined categories could be managed for different disciplines and roles.
• Quadrant seems a highly configurable modeling editor which can be customized by modeling. It is a self-modifying, reflective tool.
• Aspects are supported through type composition and projection operators, and at the instance level through multiple ascription and queries (facilitating both join and projection). The identity scheme, where each entity only has one identity member, and local identity overrides inherited identity, is also well suited for aspect oriented structures. Full support for aspect lifecycles requires operational services such as weaving, which is outside the scope of the M language specification.

However, Oslo also has some limitations:

• Oslo does require that any value is an instance of a single intrinsic type (entity, collection, or a basic datatype), so full reflective freedom is not offered, e.g. treating an entity as a single value in some contexts.
• There is no native relationship concept. Relationships are the most important kind of elements in knowledge models, because they capture the dependencies that need to be managed. Specialization is not treated as a relationship, making generalized inheritance difficult. It also seems unnecessary cumbersome to model relationships twice, at the type level as the type of a member (e.g. Responsible:Person), and then at the instance level as a constraint between extents (e.g. where Responsible in Persons).
• Properties are not first class citizens, cannot be named, related, specialized, decomposed, or modeled separately from their entity type, other than as single-feature entity types.
• Values cannot be defined as first class citizens, which can be named and related to other elements. Later linking what was originally just defined as a simple value to the context where it comes from, is thus not possible.
• Modules offer a structure to model architectures similar to UML packages. They offer some view management services, and a federated architecture could be set up. One element could for instance be assigned a local interpretation inside one module through ascription, which it did not possess outside of the module. Queries further facilitate specification of views derived from underlying data. For partial views it is important to be able to add new members to an entity dynamically inside a module, but in this area documentation is missing. Operational services are not specified.

There is also a troubling lack of alignment between MSchema, used for the repository and databases, and the textual notation of M:

• Identity is handled in two different ways, using names or a data member referred to as identity.
• Specialization is not aligned (cf. this forum discussion). Subtyping using the : operator is replaced by the System.Item pattern in MSchema. We can see this as moving from a declarative to an operational style, and from the type level to the instance (value, extent) level. Our position is that the same representation may be seen as declarative by one person and operational by another. What and How are closely related aspects, and “one man’s ceiling is another man’s floor”. A reflective architecture that treats types and instances the same way, and allow instance level inheritance, would greatly simplify the modeling architecture. Even experts have a hard time sorting this artificial complexity out, like this account shows.

Once Quadrant becomes available to a wider audience, it will the interesting to explore how this modeling editor resolves these issues. A modeling editor has to provide operational services for the lifecycle evolution of models, adding, updating, deleting, connecting and storing entities, values, collections, extents, and types. As a text editor for programming, Intellipad does not have to deal with this complexity.

It is unfortunate that Microsoft has started to design M as a textual language, and not as a structured, conceptual, visual language. This continues their previous work on domain-specific language (DSL) tools, and their approach to define new levels of abstraction on top of existing technologies. While UML is a visual programming language, M is a textual modeling language. To be accessible to business users, a visual modeling language is needed. Having worked since 1996 on visual, domain specific languages in the Metis modeling and metamodeling tool, I recognize that both Microsoft and the OMG has some distance to cover before they really enable model-driven applications controlled by business users.