Hi all,

Sorry for the long message, this probably is better suited for a blog, but I don't have one (yet).

In various threads issues have been mentioned that deal with handling large models. For example in In Multi-User Capability there is a question on multi-user capabilities, and in Collaborating on models? a solution is proposed.

In How to make Multiple Views a request for supporting multiple views has been done.

In Question on roadmap to DSL features a repository feature is requested.

We have been working with the DSL toolkit since November 2005. The first DSL's are now ready for production, several others are under development. Based on our experience with developing these DSL's, I would like to give some feedback on these requests. The main message I want to give is that it is very questionable whether features like views, repositories and model element based version control are needed at all. They are rather complex features and might introduce more problems than they solve. Let's take a look.

Views

The need for views arises from the fact that models are too big. Coming from the world of UML (which I certainly am :-) the first idea is that you need one big interconnected model that describes everything. Following this approach there is a clear need for views, because the full model is not displayable and understandable anymore. The question is whether there is a need for models to be big, or whether we are just used to that by our UML heritage. Within our software factory we have designed our DSL's in such a way that models remain small. For one DSL, we always create multiple models in a project. As a consequence we get more but smaller models. It does take a different point of view to modeling and to what models are.

We have found the approach of more and smaller models much more flexible than having less and bigger models. As each model remains small, the need for views dissappears automatically.

Reposititory

The need for a repository is clear in a UML environment, where we work with one big interconnected model. In practice, UML repositories are overly complex and hard to build and use. I have use many UMLm tools over time, but none of them solved this issue in a good way. Also, keeping all the invividual models synchronised with a repository has proved to be hard and errorprone.

In contract, we use many small standalone models, and have added to the DSL Tools a component that allows us to share some (not all!) specific information between models. This allows us to do full inter-model validation, such that we can guarantee that a collection of models is complete and consistent. The same component also allows us to use intellisense between models and can be used to perform refactoring over models. Models themselves use explicit reference elements to refer (by name) to elements in other models.

Modelelement based version control

I do not see version control of indivisual model elements as nesssecary. Having used many UML tools that try to achieve this I can only say that in my experience this never works. It only leads to an unnessecary complexity. Apart from that you always end up with non-standard version control systemns. When using smaller models, we can use standard file based version control. We all have much experience with these systems and they are known to be reliable.

More and Smaller Models

Using the approach of more and smaller models, we also find additional advantages. For example, resue of models becomes easier. Existing version management for sorce code be used for models as well, as each model is small enough for one modeler to work on. Just try to compare one model with one source code file. They are standalone entities, and the development environent can check and resolve any dependencies.

Conclusion

By moving into the direction of creating large repositories, views and finegrained version control for model elements, we will be tempted to design DSL's that will become larger and larger. In the end I fear that we will end up with UML implemented as DSL's. This will introduce all of UML's problems, which, as far as I am concerned, is exactly what we are trying to avoid. At least, I don't want to do this again.

Views and repositories are not requirements for a modeling environment. They are solutions to an underlying problem. I think that the underlying problem is that models are too big. We have found that the underlying problem can be solved in a very different way, using more and smaller models. TO se this we need to step away from the idea that a model must be one complete integrated whole. Instead we can view a model the same way as a source file and handle it as such. This has many advantages. I therefore think that the DSL Tools team should consider features in this area very carefully, since building them will take up considereble effort which I thin can be spent om more interesting features. I am interested whether other people have similar experiences.

Brian,

I tend to disagree with your opinion about views, simply because allowing multiple views (diagrams) on a model looks to me as a (single file) repository. Such a feature would encourage the development of huge DSL's that have much language features, and will most likely address multiple patterns.

A DSL that rich will be more difficult to change or exchange. It might also loose scope, i.e. the area in which you can use the DSL, simply because a lot of the DSL might be relevant for the DSL user except of ....

Still there is a need of sharing common data, so that:

- data is not entered more than once

- cross validation over models is possible

- kind of intellisense can be offered

The challenge is to implement the common data independend of one or more particular DSL's. The coupling between the DSL's should not be tight.

John

Brian OByrne wrote:

John, I think we agree on the important stuff here, just that the names are giving us trouble. When I talk of views here I'm not thinking of different aspects of a model, but different models describing the same software. I'm getting different views of the end result by looking at it though different models. Brian.

Brian, I see one model, with different ways of looking at it. If you mean that views are different (related) models of the same system I think your definition of views is different from mine. I would call a view in your terms a model. I think we agree Jos PS: If natural language was unambiguous life would be easier, but probably less fun :-)

Jos Warmer

Alain DP

Yes there is a need to share information between models, but that does not necessarily mean a repository. Let me illustrate this with an example . If you take visual studio, you can edit source code in a c# file. You will most likely use code written in other files (as all OO and other programmers do). The visual studio intellisence will help you by offering suggestions about the code in the other file. The intellisence does not have a central repository. It just reads the relevant code files in the solution real-time. So the code files themselves form the repository. The references to that source in your code file are soft, i.e. refered just by names (ascii names). I think there are similaraties between source code files and dsl models and the need to share data and intellisence: - A dsl model is comparable with a source code file. The graphical editor for the model is like the c# editor for the code file. - You might refer to information in other dsl models. The reference should be soft, i.e. references by names. There are big advantages of loosly coupling the data in models and thus the coupling of dsl's. - The shareable information must be determined real-time, just as the intellisence tool does. Somehow dsl's must be able to request this information to enable things like intellisence, cross model validation and other stuff. The big difference is that there can be multiple dsl's. They all target their own problem domain. This makes it more difficult to build a specific, easy to use API like the intellisence tool has. Anyway, this is the idea that we use to share data to support the above functionality and to generate code from multiple models that fits like a puzzle. John

John Dekker

Sorry for the long answer?

Jos Warmer

Need Multiple types of relationships and multiple views on same model elements Here is a more detailed and significant example Let's say I have a very automated organization exposing a lot of Web Services to other companies and their system(s). Let's say that I want high quality data types to ensure the quality of my services. To do this I could create a type dictionary. In this type dictionary, I could define a "Simple Type" (using SWSD terminology) called BankAccountID with some specific constraints (that could be expressed using XML facets e.g.) This BankAccountID is used - as a parameter of some of my Web Service operations - in some of my database tables - as the type of a property in some C# classes - as a field of a paper-based form (for manual task) - as the type of field in some InfoPath or ASP form - as the the type of a field in a BizTalk message .... Obviously, this BankAccountID is involved in some behaviors e.g. to access a Bank Account and in some structure electrnically, but als to fill the form manualy.... So there can be many views on the same item. And there can be many kinds of relationships that this item can have (taht needs to be viewed as well). Hence we need multiple views, but these shouldn't be create dby hand (like in UML). I hope that explains better Alain

Alain DP

Alain De Preter wrote: Need Multiple types of relationships and multiple views on same model elements Here is a more detailed and significant example Let's say I have a very automated organization exposing a lot of Web Services to other companies and their system(s). Let's say that I want high quality data types to ensure the quality of my services. To do this I could create a type dictionary. In this type dictionary, I could define a "Simple Type" (using SWSD terminology) called BankAccountID with some specific constraints (that could be expressed using XML facets e.g.) This BankAccountID is used - as a parameter of some of my Web Service operations - in some of my database tables - as the type of a property in some C# classes - as a field of a paper-based form (for manual task) - as the type of field in some InfoPath or ASP form - as the the type of a field in a BizTalk message .... Obviously, this BankAccountID is involved in some behaviors e.g. to access a Bank Account and in some structure electrnically, but als to fill the form manualy.... So there can be many views on the same item. And there can be many kinds of relationships that this item can have (taht needs to be viewed as well). Hence we need multiple views, but these shouldn't be create dby hand (like in UML). I hope that explains better Alain Alain, A simple answer: BankAccountID is defined with all neccesary details in one model. In all other models you can use a reference (by name) to BankAccountID. Inter-model validation enables you to validate that the referred BankAccount is defined in some model. This is not what I call a view, is this waht you would call a view? Jos

Jos Warmer

Hi guys, Very interesting discussion! I as your DSL client absolutly agree that it's necessary to have relations between metamodels, but there are several type of them: Reference, for example, domain property of one the DSL's element, type of this property is an element of the second DSL's metamodel. This type of relation is possible right now, you can create ExternalType, with name of the domain class's name and namespace of the referenced DSL's metamodel. Add Reference to assembly with external DSL model. Make that property as CustomStorage, and create separate file with referenced DSL model. It works fine. Also it is possible to create handler and invoke file openning when navigating to referenced DSL's model. Inheritance relation, it is very usefull when you want to support extentions for your model. For example, I have FileSystemDefinition DSL's metamodel. I have abstract element FileModel. And I want to have a possibility to create additional DSL's to extend this base metamodel by providing implementation of abstract FileModel element. And when the instance of my model is loaded into the designer, I want to see those new element inside ToolBox. There is almost the same example, but vice versa - I want to reuse SDM or CD elements, for an instance (when you implement them base on last version of the DSL ) Evgeny

Evgeny Popov