Active Knowledge Modeling

The visual modeling editor of the Oslo platform is now available for community technology preview (CTP). Since the first Oslo CTP half a year ago, the focus of the public discourse has been the textual language M, taking a programmers’ perspective, focusing on the design of textual domain specific languages and repository database structures. For those of us more interested in visual modeling and a new paradigm for model-driven applications, it has been a long wait.

This post summarizes early experiences from playing with Quadrant. Its user interface is novel, uniform, and functional, but a bit cumbersome, and as an early preview it exposes a lot of the underlying wiring, nuts and bolts. Interesting features are the combination of textual and graphical views, and the use of multiple layers for zoom and navigation. Some functionality is well supported, such as customizing views and interacting with large models in multiple workpads. On the other hand, services for e.g. relationship modeling are poor. The current scope of Quadrant is limited to visualizing and editing instance data. Metamodeling and definition of new extents (storage areas) must be done in the Intellipad text editor.

Installation and Getting Started

The installer has improved progressively over the three CTP releases, and now it worked fully out of the box on my second try. Had I read the release notes about SQLServer Express and XP first, it would probably have worked perfectly the first time.

One of the first thing you notice when you open Quadrant, is the simplicity of the user interface, with few and small menus. You find no commands for creating new models or diagrams, even though the repository comes with types for e.g. UML2 already installed. If you open a workpad for e.g. classes and try to insert an item, you get an error message saying that creation has been disallowed on that entity. That makes sense, I guess, but how can I create a new extent to store my own classes? Creating a new workpad does not help, as it does not really become useable until you have specified a query for it on the existing repository content. It seems Quadrant does not yet support creation of new extents (repository storage areas, tables). You can define repository folders to organize your data, but items for the folders must first be created within an extent. Later you can select the folder to put it in from the item’s property view. Visualization is the focus, more than modeling.

In order to explore Quadrant, then, you should first load some M models (metadata and data) into the repository using the command line tool chain. There is an easy-to-follow tutorial about how to load sample data provided by Microsoft. The Quadrant samples include typical enterprise data (people, requirements etc.) and process models. This post is based on experiences with these data.

Visual User Interface

The main part of the Quadrant user interface is taken up by the workspace. A workspace is not really a modeling surface, rather it serves as a container for workpads where the visualization of and interaction with model data takes place. The workpads resembles windows in the old, much berated multiple document interface. Individual workpads may be pushed to the back, popped to the front and enlarged, or maximized. The workspace supports “infinite zoom”, however zooming only affects the background workpads. This dual layer approach is really nice when you need to work on a certain part of larger model, then move on to another. Making size and location of the popped and maximized workpads stick to the editor window rather than the workspace behind it, works well. However, since you will mainly be working in popped and maximized workpads, the lack of zoom abilities locally in the workpad is really annoying. With a typical process model, my screen cannot show all elements at once.

A screenshot with different workpads is shown below, the Inspector workpad (bottom right) is always popped, the rest of the workpads are pushed back.

Quadrant user interface

“Everything” in your model is treated in a uniform way. Both instances and collection can be dragged from an existing workpad onto the workspace to create a new workpad. For each workpad you can select between several views, like tables, lists, trees, diagrams, and various master-detail combinations. User can define their own customized views, and it is easy to set the default view for an element type. The layout of diagrams is partially automated, however when you close and reopen a diagram, it will revert to an automatic layout, not keeping the location changes you made manually the last time.

For our Configurable Visual Workplaces (CVW) prototype, we have also tried to implement windows-like functionality inside a model editor (Troux). We did not have two layers at our disposal, so everything was done inside a single surface, using zoom to move between workpads, and to focus on certain elements within a workpad. While the CVW user interface is probably more uniform, we lacked the ability to always show the frame of the workspace around whatever part of the model the user was focusing on. This led us to include a header toolbar with every workpad, in addition to the one for the whole workspace. Zoom locally for a workpad was a much wanted functionality in CVW as well. The screenshot below shows a workspace with a navigation menu to the left and four workpads. While CVW has the advantage that “everything stays in place” and the user moves around, the approach taken by Quadrant has the advantage that the user stays in the same place, and may bring workpads closer to herself by popping them.

Configurable Visual Workplace (CVW)

Another striking feature of the Quadrant user interface is the use of positioning devices. Probably in order to simplify, and work with hardware such as touch screens, the right mouse button is not very functional. It seems all you can use it for, is to add new elements to a diagram. Also, there is no multi-select, probably because the Inspector window shows the properties of the selected element. This is inconvenient when you would like to perform the same operation on a collection of objects, e.g. to change the shape of a selection of objects in a diagram.

The process diagram is an example of what kind of diagram notations and functionality that can be configured into Quadrant. It works ok, though I was unable to add new items to a subprocess. Probably this service was not configured, because opening the subprocess in a separate workpad did not help.

The image below shows a diagram where for some reason the user is not allowed to add any new elements. Speaking as a designer of model-driven applications, I would like to see default configurations applied more. By default, each diagram should allow the user to add any kind of element that it already includes. The solution modellers should not be required to configure this separately for every diagram. 

Diagram with relationships, where no new elements can be added

Speaking as a model language designer, I find it really annoying that subprocess is a different type from task, so that you have to know in advance whether you would like to add another level of detail. This should be handled dynamically, by simply converting the task to a subprocess as a side effect of adding the first child element. Ideally, subprocess should be treated as a derived type, defined by a query: Every task that has a child, is a subprocess.

The entry point and primary navigation structure for your model data is the Repository Explorer. It organizes entities according to a Folder hierarchy. Each entity can however only be located in one folder, so to serve your multi-dimensional navigation needs, Quadrant provides tree views that let you browse along any relationship structure, as shown below. I have not investigated how these structures are configured, but I would hope it is not hardcoded, and the navigation setup can be modeled.

Relationship navigation in Quadrant

It is annoying, though, that you cannot place entities in folders by drag/drop in the repository explorer. This should also be supported for any tree view, where dropping an entity into a tree node would result in creating the underlying relationship between the parent and the child.

Modeling Paradigm and Concepts Exposed by Quadrant

My primary interest in this version of Quadrant was not to test the user interface and detailed functionality, but to understand better the underlying modeling framework. Intellipad and M caused some concerns that the promise of model-driven applications was becoming dominated by more traditional programming perspectives. I’ve commented on this here and here.

Quadrant expose

1. A repository driven modeling framework
2. Based on textual metamodeling (types) and data storage management (extents)
3. Visual modeling of instance data
4. A customizable modeling environment for domain specific languages
5. A strict separation of roles and responsibilities between programmers (metamodeling in Intellipad) and users/modelers (instance modeling in Quadrant)
6. A strict separation of design time and run time for the modeling environment, caused by the compilation and loading steps from M to the repository

The figure below is an attempt at representing the core constructs and data flows in the Oslo modeling platform.

Core constructs and data flows in Oslo

The repository or database driven framework makes it easy to store the data, and creates a simple, uniform model. However, the support for key visual modeling concepts like relationships is not native and limited. Out of the box, Quadrant does not recognize many-to-many relationships from entities, leading to relationship diagrams like the one above, where all the numbered shapes are really relationships to requirement objects. It is the requirement objects that you would like to see visualized as objects, while the PersonToRequirement relationship table rows should be shown as links. Though you can fix this by defining queries for which repository items are to be shown as nodes and links respectively, standard patterns for e.g. many-to-many relationships and multivalued attributes should be supported by default mechanisms. It will be very cumbersome to define technical-level queries over and over again for every type. A native relationship type should be provided. On the other hand, this also indicates high degrees of tailorability of the viewing mechanisms in Quadrant, a promising sign for those of us who would like to implement our own methodologies on top of the Oslo foundation.

I would also like to be able to visualize relationships between workpads, like in the CVW screenshot above. This would greatly facilitate navigation and management of dependencies in large models. Modeling in the workspace could also be supported, with workpads for individual entities used like shapes.

For active knowledge architectures, the lack of integrated modeling and metamodeling, not enabling metamodeling on-the-fly at runtime by end users, is a showstopper. In knowledge intensive tasks like product design, the users are not just creating a new product, they are also creating a new language for describing the product. Requirements analysis leads to the specification of critical design parameters (properties), while design and engineering typically end up defining different product classes, as well as variant parameters for configuring customized products within a family. Still, there is sufficient promise in Oslo to warrant a closer investigation of that kind of additional components would be needed for modeling and utilizing active knowledge architectures.