Industrialized Software

Thanks,
Jorn

1. A domain is partitioned into well-defined areas of knowledge, each of which relates to exactly one role
   • I agree with the first part, but disagree that a role is connected with this. A language should not make any assumptions of the different rolss in which it is used. — Jos
   • How do you determine whether an area of knowledge is well-defined? In practice a big part of separation of concerns consists of disentangling the responsibilities between different roles, and in avoiding different roles having to edit the same artefact (work product) at the same time for different reasons. But also note that of course two languages may share a common part, no need to invent any concept more than once. — Jorn
   • Still, roles have to do with the process you design around developing artufacts. A language should be unaware of the proces. Different organisations, different typoes of projects and different cultures will need different processes and different roles for developing models. But they do use the same language. — Jos
   • Yes, roles have a bit to do with the process, and even more with the dependencies between artifacts/work products. Hence I consider them key to modeling language design. I agree that organisations differ in roles and processes, and I would add that these differences should not be brushed away by force, that is by attempts of "standardization". I do allow for different roles in different organizations, and also for different terminology in different organizations - this is very much related to modeling of variability in a product family. The most valuable languages are organization-specific, but at the same time they can be part of a language family. A lot of the debate about "correct" terminology and process goes away if you allow for the natural variability - but of course the variability needs to be modeled if you want to exploit the commonalities. — Jorn
2. All artifacts are based on information produced by a specific role as a result of a specific event
   • I miss the definition of artifact, on which everything is based. How is this related to model, model instance, meta model, modular model? — Jos
   • See above comment, I use the term artifact in the sense of work product. All of the items in your list are artifacts. — Jorn
3. A modeling language is developed for each kind of artifact (modular meta models)
   • Depends on the definition of artifact. — Jos
   • I am perfectly aware that some people prefer to work with "larger" languages, and then resort to heavy use of "multi-view" editors etc. Many common separation-of-conern problems originate by cramming too much into a single language. — Jorn
   • I am not in favor of large languages at all, and have doubts about the usefulness of heavy multi-view editors. It seems that we agree more that we disagree here.
4. The meta model of a modeling language has exactly one root node that relates to the modeled artifact
5. Variants of meta models and model instances are expressed as extensions of a common root
   • Not sure what a variation is and how extensions are defined. I think that there are deeper implications of this statement that remain unclear — Jos
   • Yes, this topic is not trivial. The paper on Gmodel provides relevant background information. — Jorn
6. Artifacts are the only granularity at which versioning is applied
   • I do agree that you need to define the level of granularity for versioning. This is now at artifact level, which is not defined. It should not be too small, som depending on the definition of artifact this might be a good or bad rule — Jos
   • This principle means that artifacts/work products need to be designed such that the granularity is suitable for versioning. Too coarse grained, and there is bound to be contention between different people wanting to edit at the same time, and too fine grained, and there is little hope of work products representing any useful piece of consistent information. — Jorn
7. Artefacts are locked for other users while being edited
   • No, certainly not ! Locking behavior is not relevant to principles of language design. This is an orthogonal issue and the language design should allow for different ways to handle multi-user access. This included parallel changes, diffing and merging. This rule should be removed. — Jos
   • I disagree. The poor separation of concerns encountered in traditional source code is the root of a lot of evil, including the pervasive need for diffing and merging. This rule works together with other rules to ensure appropriate attention is paid to a sensible granularity of work products. — Jorn
8. An explicit modularization mechanism is required within a modeling language if the meta model allows for model instances of unlimited size (modular models)
   • Yes, such a mechanism should be designed as part of the language. I would then expect that the module (as defined in the modularization mechanism) should be the level at which versioning takes place. Without knowing what an artefact is, therefore it seesm that I haave to disagree that versioning should be done at the lever of an artifact. — Jos
9. Meta models are artifacts as well
   • So ? This is not a rule applying to fundamental principles for modeling language design. I would remove this rule altogether — Jos
   • Some meta languages make it difficult to design modular meta models. Not what I consider conducive to high quality. Hence this rule. — Jorn
10. Two meta models may be joined via references between meta classes in both meta models
    • This sounds like a bad design rule. Meta models of different languages should be independent of each other. Of course the joining may apply, but it should not be encouraged because you are conceptually creating one big(ger) language again. What is the intention of this rule? — Jos
    • How about a rule on how models may refer to model elements in other models? Shouldn't be allowed either. — Jos
    • See the next rule below. These two rules together provide a very nice way to integrate languages. I expect a whole number of opinions in this area, and it remains to be seen how much consensus is possible on this particular point. I suggest this is a good discussion point at one of the KISS workshops :-) — Jorn
11. No circular or bi-directional dependencies between meta models are allowed
12. The set of models associated with a meta model is recorded as part of the meta model artifact or via a reference to the meta model within each model artefact
    • A meta model should never contain references to its models. I can't see why this would be beneficial. The other way around: yes. — Jos
    • I am inclined to concur, but I would not want to set the direction of the dependency in concrete. In the end it is an implementation decision. Would you be comfortable to dismiss all tools that implement the dependency the other way around, without taking a closer look first? What matters is that meta models and models are strongly and permanently linked. — Jorn