kaizen

A very lame DSL Editor. The “role” and the “item” figures are created with Grid Layout. The “workflow” figure demonstrates the use of Insets (padding around the text).

The first goal with my DSL Toolkit experiments is to create an “operations manual generator”, a bit like EPF (see this post), but using my own favorite meta-model (see this page).

It could be argued that I lack imagination as I have already created a couple of such generators before, one based on Rational Rose and one based on StarUML. (In both cases I used UML stereotypes for defining the meta-model.) Unfortunately both these solutions have serious drawbacks: Rational Rose is forbiddingly expensive (or at least was at the time) and StarUML is a dead open source project despite its very impressive qualities. Eclipse and the DSL Toolkit don’t seem to have those two particular drawbacks but I’m sure I’ll run into other road-blocks why I’m doing this in a risk-based fashion.

I believe that intuitive graphics, particularly good looking modeling element icons and a diagram editor that works as expected (no random reordering of elements, no rounding errors when snapping to grid, rectilinear lines behaving well etc), are important to make a domain specific language attractive to use. I have therefore spent several hours to explore the layout options in the gmfgraph model. I wish to eventually use my own icons with icon (class) labels centered below the icon. It took me quite some time to actually manage to center the label. There might be more than one way of doing it but only way that worked for me was the Grid Layout with default Grid Layout Data for the child element.

I still don’t have the full mental model of the modeling elements (e.g. the Child Access) in the diagram definition models so I guess I’ll spend a few more rainy hours making small adjustments and generating new diagram code. Fortunately I have a pretty fast computer.

I have waded through numerous tutorials on the Internet (links to those that I found most useful can be found below). I used the reference section of the DSL Toolkit book to understand the layout options (the reference part is actually pretty good).

GMF Tutorials

[1] A very basic tutorial that creates a class diagram editor using the wizards. The created solution is a good starting point for further experiments though.

[2] A basic tutorial with some hints as to how to change to look of elements in the diagram etc.

[3] A tutorial that covers more than just the basic diagram with a few classes-as-rectangles and associations.

[4] The official Eclipse GMF tutorial. Unfortunately, it seems a bit outdated. The Taipan example can for instance not be found at the indicated location.

I have decided to use some of the rainy days (I’m sure they’ll come) of my vacation to test out the Domain Specific Language Toolkit (DSLT) associated with the Eclipse project. As I mentioned in an earlier post, I’d like to implement my own metamodel for process (enterprise) modeling and learn some stuff along the way. (Maybe it could also be used for that other hobby of mine: digital media players but that’s for later.)

This first post is only intended to convey that rather heavy feeling I usually get when starting something totally new. It’s very much like when I joined the MPC-HC project last year (see this post). The textbook on DSLT [1] says things like “I highly recommend that you first read… the book on EMF”. That is before even starting to read this book on DSLT. And the basis for DSLT, the Eclipse platform seems complicated enough. I guess I will need to learn some of its philosophy along the way too.

I have at least managed to download and install the DSL Toolkit application. It’s a bit hard to find just using the instructions in [1] but the link below should work [2].

So now I have an application with an example loaded. It has a “Package Explorer” with a lot of stuff in it. The stuff seems to be pointing at files in the workspace. Learning has begun…

Links

[1] A Domain-Specific Language Toolkit. Richard C. Gronback.

[2] DSL Toolkit Build: 1.0.0M8

As you might have seen, there are a few pages on this site about operations manuals and process modeling, i.e. about describing the way of working in an organization in a semi-formal way. I have implemented a custom meta-model for process modeling [5] in Rational Rose and used it to describe the whole operations manual for a medical device company. The manual itself was generated in HTML format from the UML model in Rose. Since Rose is much too expensive for private use, I have also played around with StarUML, an open source UML editor, and made a translator that generates contents for a WordPress (blog) site from a process model in StarUML. StarUML is a very powerful and well documented tool with a good API. Unfortunately it’s a dead project so continuing that line of development doesn’t seem too attractive.

The EPF editor and the resulting web site. With tweaked styles.

In the mean time, a standard meta-model for process modeling, the SPEM (Software Process Engineering Meta-Model) [1], has been adopted by the Object Management Group. A variant of the SPEM meta-model has been implemented in the Eclipse Process Framework (EPF) Composer, an open source tool based on Eclipse [2]. I write “variant” because I haven’t had the time look at the exact mapping between SPEM and the implementation but it is not 1:1. In contrast to the StarUML project, the Eclipse project is one of the most active open source projects on the net. The basic platform seems very stable and a large number of other adaptations are also available, e.g. for UML2.

The purpose of the EPF is “To provide an extensible framework and exemplary tools for software process engineering – method and process authoring, library management, configuring and publishing a process.”.

SPEM is based on the more or less formal meta-model used for describing the original Rational Unified Process in its early web version (the Rational heritage is also hinted by the meta-model documentation that is generated from Rose and some of the code in the web site generated from the EPF model).

I have been using SPEM and EPF for a few days now and have compared them to my earlier experiences from tools and meta-models for process modeling. These are some of my tentative conclusions:

• The documentation of both SPEM and EPF is excellent including a good tutorial. Very few open source projects can claim such good user guidance.
• The Eclipse tool itself seems stable and runs equally well on Windows XP and Ubuntu 8.04 (the Ubuntu platform requires some tweaks at installation though, see [4]). I particularly appreciate the Linux compatibility.
• The tool has an attractive user interface.
• I’m happy that the modeling element Outcome is added to the meta-model. It took me a while to realize that such a modeling element was needed to represent those intangible results like a “informed customer”. (It corresponds roughly to the Objective modeling element in my meta-model.)
• The Category concept is very useful, particularly for defining various structures for publishing the model.
• Importing and exporting process models work fine.
• There are provisions to manage the models in ClearCase and CVS. To what extent Subclipse can be used with EPF I haven’t investigated.

There are in general too many modeling elements in SPEM. I prefer my meta-models simple and conceptually lean. That was one of my goals with my own meta-model [5]. More specifically:

• There are numerous different modeling elements for an activity (Step, Task, Process, Capability Pattern, Discipline, Activity, Task Descriptor, Phase) where I have only two (Activity and Workflow) that can be hierarchically structured. It is hard to remember the relationship between for instance a Task and a Task Descriptor (~inheritance) or to understand the conceptual difference between an Activity and a Task Descriptor (hierarchy).
• There is a multitude of classes for various types of guidance. The only advantage that I really see with this is that one doesn’t have to write a title for the guidance since the title is given by the modeling element type.

Some other observations in the negative territory have to do with the fact that the implementation of SPEM in EPF is rather hard-wired:

• There is no modeling element for Event which I have used quite heavily to describe the events that for instance trigger a change request or a customer support ticket. And I don’t see any way to add it either.
• I would have preferred free format class diagrams through which to define the relationships between modeling elements. At least as a complement to the form based entry mode. It is nice that diagrams are created automatically from the data but still.
• There is no way to add custom attributes to modeling elements. I have often needed this in my models to describe attributes that are there in the real implementation of the artifact (in a document header or in a field in a database object). Some examples are Approved by (the formal approver of the document), Valid from (the date from which a document is valid), ID (the unique identifier of the artifact) and so on.
• There is no true inheritance mechanisms through which new modeling elements (“classes”) can be added to the language. I have often found it useful to design inheritance hierarchies when for instance specifying all artifact types used in an organization when these artifacts have several different levels of formality (for an example, see [5]). Instead there is this, in my mind somewhat ad-hoc-ish, mechanism for specializing Roles, Tasks and Artifacts from the Method library into the Process descriptions.

Last but not least, a couple of comments on visual appearance:

• Some of the generated views are very cluttered, for instance some that belong to the Phase modeling element.
• Tweaking the style of the published web site is very difficult as the style definitions are spread on at least 5 different files. Being able to modify the style is important for industrial users. They will invariably want to use their own graphical profile.

Despite the above critique I will try out EPF in an industrial setting in the near future. It seems easy enough to grasp and use and gives a much better framework for structuring the processes than e.g. unstructured Word documents. Maybe I later get the inspiration to implement my own meta-model in the Eclipse Domain Specific Language Toolkit.

Links

[1] Software Process Engineering Meta-Model, version 2.0. OMG.

[2] Eclipse Process Framework Project (EPF).

[3] Open Unified Process.

[4] Editors do not work [message #55830] (EPF Forum)

[5] My process modeling meta-model

The research about the human brain and behavior strongly suggests that most of the information processing we do in our brains including a substantial amount of decision making happens without ourselves being aware of it (in the sense that we can communicate such awareness). Libet’s experiment (see a Libet’s short delay) for instance shows that an action potential builds up in the brain up to half a second before we become aware of ourselves taking an action.

Other unrelated research suggests that a lot of the knowledge we use when performing familiar tasks is tacit knowledge, i.e. knowledge in a format that isn’t easily describable or communicable. So not only do we make subconscious decisions, we base those decisions on subconscious knowledge when we are really good at what we are doing. The natural development of competence has by several authors (the original source seems difficult to find) been described with the model in the exhibit below.

The stages of competence development.

When discussing knowledge a distinction is often made between “knowing that” and “knowing how”. We know that 2 + 2 = 4 and we know how to add numbers. (In my native languages Finnish and Swedish there are actually, in contrast to common English, different words for these two types of knowledge. In Finnish we say “tietää” and “osata”, in Swedish “veta” and “kunna” – probably corresponding to the old English words “wit” and “ken”.)

The whole purpose of an operations manual is to describe and facilitate the build-up of know-how in the organization. The question is: How can we describe and disseminate know-how that in its most evolved form is unconscious? This is an other way of asking the questions put forth in an earlier post.

I still don’t have answers to the questions referred to above that I’m satisfied with but I’m convinced that we have to take into account how the human brain is wired.

Now to something completely different

I started out my career designing image processing algorithms and hardware. At one point I rather inexplicably diverted into management consulting and took interest in issues such as operational effectiveness, cycle time reduction, and quality management. A while after my defection an old colleague of mine, who was at that time working on his PhD in image processing, asked me in an email what I was doing nowadays. Having tried to explain to him what I was doing, I got a reply with only one word in it – “perverted”.

In some of my darker moments as a management consultant, especially when working with quality management systems, I tend to agree with my former colleague. The quality management system manual, or using my preferred term, operations manual (OM), is too often that Dilbertian “big honking binder” that everybody treats as a “dead raccoon”.

All is not gloom though. There are a number of compelling reasons to create and use an OM and there are success stories out there:

• An OM is a good place to store and make available good practices, a place for storing tips and tricks that have proven to work in each particular organization.
• An OM can be used as a basis for discussions and deliberations about good ways of working within the organization.
• An OM is the basis for training and training material regarding the organization’s way of working.
• An OM may be required as an evidence that you have practices required by various laws and regulations in place. Such specific documented practices are for instance required for manufacturers of medical devices and aircraft.
• An OM with common practices facilitates collaboration. If everybody in a global organization agree upon the typical steps in their project development process, then project managers can get a fair picture of the progress of the project and subproject teams can coordinate their work.

The benefits of the right number of good, required, and common practices are hard to dismiss. Try this corporate policy from hell to convince yourself: “It is our policy to throw away and forget past experiences, to ignore the law, and to let every project reinvent their ways of working from scratch.” If you really believe that the above policy is a good one, then you can stop reading here.

Those of you who are still with me may now ask (1) what a really useful OM would look like and (2) what it should contain, not to be treated as a dead raccoon by the staff, and (3) how should the management of it be organized so that it would continue to reflect the best practices of the staff that actually perform the work. I will attempt to address these question in later posts.