The Model Driven Software Network

Raise your level of abstraction

In various recent discussions (Tool for mdd, feedback on Fenomen, CG2011 fishbowl session, LWC 2011 etc.), attempts were made or at least the question was raised to compare different MDx approaches.

It seems, at present, we have a few rather different ideas of what MDx technology is, or should be. Far too often we compare apples and oranges.

For comparison, at least we should distinguish the following aspects:

- How do you interact with your model?
(graphical, textual, guided by a tool, validation)

- What do you model?
(level of abstraction, amount of models, completeness)

- What do you get "out of the box"?
(ranging from: complete domain specific business solution, up to: raw technical model to code transformations)

- What do you create?
(artefacts, completeness, level of abstraction of artefacts etc.)

- What can be modified, and how?
  (the answer to this question must be a really lengthy one and goes to the heart of MDx)

Related to the last question is, e.g.:

- How does your transformation chain look like?
(one stage, MDA, interpretation, something else/more/less)

All these questions can't be answered simply "yes/no" (except in marketing brochures, where of course all solutions are business oriented, totally complete and absolutely felxible).

For a different context, I was preparing an overview of MDx technologies. It's work-in-progress, but I thought it might be interesting to present it here in this early stage. The link is

http://technology-map.biz/index.php/Model_Driven_Technologies

The diagram shows the area of models and artefacts in MDx context. From left to right it goes through abstraction levels from business to software. The other axis corresponds vaguely to multi tier software leves (UI, BL, DB).

The purpose of the diagram is to be able to draw different approaches into it, and allowing a comparison of what each approach actually does in the area.

If you like, you can help improving that overview (your contributions will be save since it will be under a creative commons license). You can also help editing the diagram itself via an integrated browser-based svg-editor.

I'd appreciate your comments, either here at MDSN or in the wiki.

 

Andreas

Views: 1545

Reply to This

Replies to This Discussion

Ok, so that would make another good list: "Goals of MDx".

1st draft (from above):

- make software production faster and more reliable

- enable non-technical business people to get a grip on their systems

- make software production more agile

 

And yes, fully agree with your "...hate to ... choose...". I was just quoting vendors' claims :)

 

Andreas and Meinte,

I think there are a number of different things implicitly present in this thread: technology, methodology and innovation process. I will give some examples to explain what these mean for me:

Technology: MetaEdit+, Mendix Suite, Obeo Designer, etc.. LWC2011 focus on capabilities of tools to model and transform.

Methodology: DSM, MDA, AALM (by Mendix), etc..

Innovation process: how to "do"/introduce/evolve MDx in real-life project situations.

 

Do you recognize these as well in the discussion? Is there more?

I guess I do but personally, I find Methodology to be completely uninteresting. Most "methodologies" boil down to a combination of common sense, some well-known principles and best practices (Separation of Concerns, the Single Source-Principle, etc.) and some kind of flavoring through a manifesto of sorts. In view of that, most MDx methodologies reduce to "some_other_methodology using models" anyway.

So I don't think they are really valuable on their own, at least not without bringing more to the table. The most important thing would be how to combine MDx with the dev methodology that's presumably already in place. I don't really believe total MDx green fields projects exists: there's always some kind of company or project standard to conform to. That's not bad, we just have to know how to work with that and that's precisely what something like MDA doesn't do, period.

Without some discussion on the combination aspect, any comparison is going to be as useful as one on whether steam or nuclear power is better for dish washers ;)

Usually, my innovation process looks something like this:

1. Get to know the domain.

2. Identify a part of the domain that would benefit from modelization.

3. Create an (end-to-end) implementation for that part (language, modeling environment, code generation, integration into continuous deployment, etc.).

4. Provide business value with that implementation (roll out, train users, etc.).

5. Goto 1.

If the comparison were to address how a particular fits in with this process, I'd be vary happy.

Hm, I can easily understand for (3) that you can show e.g. which standards are supported so that something fits into a given scenario.

 

What do you have in mind with (1), (2), and (4), with regard to "fitting with the process"?

@3: I really don't care about standards. In fact, I think that word has done more damage to MDx than it brought good - except for the EMF and XMI standards, but these arose as "working standards" which is a bit different from the ivory tower-kind like MDA and UML. I've never encountered a situation where having a standard in itself brought any value to the table.

 

@the rest: With "fitting with [in] the process", I mean how well any tool or methodology fits in with "my" innovation process. So it's really an easy rephrasing game: how well does tool X/methodology Y allow me to get to know the domain, etc.

 

@"Goals of MDx": the goals shouldn't really be different from "goals of software creation", IMHO.

@standards

Sadly enough, yes. Considering XMI and tool support, it's not even a working standard, but a rough idea of a potentially working standard.

Anyway. I dare to question whether this is due to too many/bad standards, but instead due to a lack of an amount of really working standards. After all, it might be a reason why MDx is not so widespread accepted as we wish here; it was not just once that I heard from the customers' side that he does not know what to bet on; even with open source there's possibly a "vendor" lock-in.

 

@the rest

I see your point. Do you have a list in mind of such potential benefits of technologies (business/IT approaches, tools, methodologies etc.), or possibly properties they shall have to serve the various steps?

 

@Goals

software creation, yes agreed, plus: business issues at the intersection of organisation/management/architecture/IT. As an example, there's BPM (all flavours). It does not necessarily concern software creation, it might affect in addition or alone work coordination, while it's for sure (to some degree) "model driven". More than that, there's the finally most interesting integrating area of "enterprise modelling" - defintely related to software (today), as well as definitely radically more than software (today).

@standards

I'm pretty much restricted to the Java/Eclipse/EMF ecology but over there XMI and EMF are very much working standards. The perceived need to adhere to some standard is mostly a manager thing, IMHO and usually not because of fear for "vendor lock-in" but because a built-in and irrational "we need standards!"-type of thinking, where real, rational reasons have little or no place.

Besides that: I think that standards for which you can't readily create a reference implementation are useless anyway. Usually, anything outside the communication/formats (like XML, XMI, etc.) or platform (like the JVM) domain doesn't meet that condition.

 

@the rest

I always feel that lists sort-of insinuate exhaustiveness and having checkboxes in front of the items, which typically prevents thinking about these... One simple "thing" is that tooling should support agility/software evolution.

 

@goals

I don't see BPM as a business goal, but rather as a means (and usually a very poorly implemented one, at that). Also, "business issues at the intersection of organisation/management/architecture/IT" already implies a precise direction in which you're willing to find business value which might very well detract from finding the real business value. In the end, the goal is probably something like "improving people's lives" (+ a description of the scope of that statement). While it's useful to keep that in mind, MDx could focus just as well on allowing the software creation effort to be as efficient as possible, not just in execution but in discovering the actual business value as well.

@Meinte

 

So let me go back to the original question. Do you have a suggestion how a comparison might look light to meet your requirement?

 

> 1 ... 5

> If the comparison were to address how a particular fits in with this process, I'd be vary happy.

You are clearly interested in MDE development process. What you outline is approximately the process I follow in MDE projects as well. In my opinion this process is a traditional development process. (In fact, I found that sensible use of MDA process works very well for me). However, there are a few peculiarities and a complication:  

The complication is that MDE development is usually coupled with introducing a relatively drastic change within an organization, because it affects knowledge workers, and MDE is still relatively new and unknown. So this complication needs to be managed in addition to the primary work. This however belongs to social/organizational sphere.

One peculiarity is that domain knowledge/ontology analysis is very important as its artifacts have strong (isomorphic) relationship with DSL concepts. (This is in contrast to traditional development and methodologies, DDD being an exception.) Therefore, it would help if MDx tools had proper support for such analysis. 

Another peculiarity is that MDE subjects are knowledge processes, and therefore process view (and appropriate tech support) is important e.g. to learn domain and identify subject activities with best ROI. 

The bad news is that no MDx tech gives me what I need for the above work. All of them focus on step #3 (in your post) with possibility to use traditional development methodology.

The (semi-)good news is that good quality MDx tools allow me to make my own DSLs to support my MDE process. (However in practice I tend to use simple tools).

Taking Meinte's angle, it would be nice if the comparison addressed dedicated support for domain modeling and process modeling.

 

Hi Andriy,

@first post

I'm not sure where you see the "traditional MDE development process", likely you're referring to diagram 1 again (Domain Layer Overview)? If so, be careful not to mix "development process" and "artefacts/information/models": the overview shows possibilites of artefacts which are somehow affected by MDx technology, it contains alternatives which would never be used in a specific scenario simultaneously (e.g. domain model interactions and ui flow - these are typically mutual exclusive). Sure you can draw specific processes into the diagram (e.g. the CASE/MDA-links at the top (which are, just for the records, not my favourites in their simplicity)). But beyond that any specific process is in the viewer's eye!

It's of course debatable whether the overview is typical/complete/representative/wrong; whether and how it is affected by language crafting technology; whether and how it is affected by people and culture working with them; by growing out of pure IT domain into business domain; by affecting not only systems, but organisations and people.

Very interesting questions.

(and with respect to being intermangled with the enterprise it might be a good idea to extend the diagram to the left and show how the organisation is affected, e.g. by the process model; in fact we could draw to the left a diagram giving an overview of information used in organisational and management methodologies, underlining the importance of a "Business Technology" angle once more; but this would stretch the meaning of "explaining MDx technology" a bit, so it might be better for now to put it on a separate page, correspondingly linked).

My personal observation regarding these questions is, that at present the majority of MDx projects operate rather precisely in the area shown, and few reach even the presented degree of differentiation. This is then sold as "individuality", but in fact it's a different kind of immaturity: not having managed the task of organising the information architecture properly, which affects the quality of the results - organisation as well as IT system - substantially. A DSL which in a customer specific fashion creates something whatsoever *can* be a good, agile, and desirable solution - but the DSL attribute alone does not guarantee this by itself, it might as well be a sign that the vendor has not the slightest idea of how to improve the inbetween information architecture; the necessity for and corresponding risks of trying to solve this task on-the-fly within a running project is one of the reasons why MDx does not take off as much as desired.

I think some of us have just given up to seek such an improved information architecture, since it's been an underestimated challenge to find it (it's marketed since for at least two decades), the code generation community is still seeking. I'm very aware of the various kinds of arguments trying to convince ourselves that it is just *unsolvable*, but I'm afraid we're betraying ourselves if we do so. Actually there is some progress, but it is slow, and mainstream likes to make unneccessary loops (just to give an example, early BPM notations like EPCs had a rather holistic view, then with BPMN we at first lost our artefacts in the processes, now the call for unification of BPMN/UML rises again). The problems are the same, independent of the kind of approach we're trying to tackle them with, being them innovative software components, skilled people, modern methodologies or flexible processes. Which does *not* imply hat there is "the one and only correct architecture", it just implies that extreme positions are wrong.

Anyway - we are (not really surprising) being drawn into actually comparing. The intent of this thread and the wiki is not to do this, but to present information, to enable informed readers to compare and judge on their own. It would be really great if we could create something like that, and I think it would help the MDx community as a whole, since our customers are clever enough to draw their own conclusions from inner-community marketing battles.

So, let's be specific: are there any more aspects to consider in the overview of artefacts/models/information kinds? What do you deal in your projects with? Are there more, the same, variants of, always completely different ones? Which ones? In case they are always different, there must be lots of examples to proof that; if not, we should be able to list them.

One dimension is surely missing in the picture, which are concrete domain, process, task, trade, customer, or organisational unit specific model instances (or frameworks, or reference models). These have an inner architecture as well, and they are connected with and rely on the languages we use, and they are utterly interesing, too. Whether they deserve their own "language" or are just "model instances" is an interesing issue.

> ... complication ... MDE ... drastic change ... knowledge workers ...social/organizational sphere...

Yes. I agree very much to that. So: who exactly (which roles) in which organisation is affected by which part of which new process? We can differentiate at least business people interacting with high level (abstract) models, business and/or IT people analysing, understanding and designing various architectures, people defining the (possibly various) syntaxes, semantics and interpreters/transformators and people providing software components for running all this.

Not necessarily all people are always affected by all these issues. Depending on the involved organisation(s) goals, it might in one case be the customers' explicit wish to be kept as far away as possible from the "intrinsics" (only the quality of the top level model counts as well as the results), and in another case he wants (or should want) to be involved as deeply as possible (the quality of the tooling counts directly to him). I have seen a number of different combinations, there's no one-size-fits-all point of view we can take.

> ... MDE subjects are knowledge processes, and therefore process view...
> ... learn domain and identify subject activities with best ROI...

Are you referring to business processes or development processes, or both?

> ... bad news ... no MDx tech ... for the above work ... focus on step #3

Well, given that not even the task of performing step #3 is managed sufficiently and this fact is a reason for high software development costs and insufficient flexibility, I can't see why it should be bad news that MDx technology tries to improve that.

> ...domain knowledge/ontology analysis ... strong (isomorphic) relationship with DSL concepts...
> ... support for such analysis...
> ... good news ... MDx tools ...own DSLs ...
> ... dedicated support for domain modeling and process modeling...

Which kind of support? You mention DSL crafting. What does support for domain/process analysis/modeling comprise?

@second post

> ... embrace the "unembraceable"... four different things...

Yes, these aspects are present, what is the problem with that? I mean, to compare MDx approaches, one has to understand the various implications and connections. In which way would you like to separate them to make them more comprehensible?

> ... measuring metamodel quality...

Thanks for the link. This is indeed useful, I'll do my best to incorporate it. I think I should read that metamodelling paper. Concerning level 5, I do not understand how dynamic semantics can be (completely!) specified in a formal as well as practicable way, do you?

Andreas

Hi Andreas,

 

Thank you for the time you took to think over my points. At the moment I can give only a few brief answers.

 

> I'm not sure where you see the "traditional MDE development process", 

 

I was referring to the 5 steps described by Meinte. This is an MDE development process that leads to MDE infrustructure (Tools +DSLs + transformation) to support a traditional business or development process. In my experience, an MDE process is just a traditional development process with a few complications I outlined previously. 

 

>> ... complication ... MDE ... drastic change ... knowledge workers ...social/organizational sphere...
>

> .. Yes. I agree very much to that. So: who exactly (which roles) in

> which organisation is affected by which part of which new process?

> We can differentiate at least business people interacting with high

>level (abstract) models, business and/or IT people analysing, 

The point is that it does not matter. MDE does not fixate problem domain, nor particular type of activity. In fact MDE can be applied to improve work of MDE developers as well.

 

 

>> ... MDE subjects are knowledge processes, and therefore process view...

>> ... learn domain and identify subject activities with best ROI...

>

> Are you referring to business processes or development processes, or both?

 

Yes, both.

 

 

>> ... bad news ... no MDx tech ... for the above work ... focus on step #3

>

> Well, given that not even the task of performing step #3 is

>managed sufficiently and this fact is a reason for high software

>development costs and insufficient flexibility, I can't see why it

>should be bad news that MDx technology tries to improve that.

 

 

I think you are placing step 3 in the context of traditional development process. My comment was in the context of MDE development process. Here all tools I know focus on part of step 3 only. (To make an analogy, imagine a traditional dev. process with only software developers equipped with IDEs..)

 

 

>> ...domain knowledge/ontology analysis ... strong (isomorphic) relationship with DSL concepts...

>> ... support for such analysis...

>> ... good news ... MDx tools ...own DSLs ...

>> ... dedicated support for domain modeling and process

>>modeling...

>

> Which kind of support? You mention DSL crafting. What does

> support for domain/process analysis/modeling comprise?

This is a very big question. Here is s brief answer:

Before I even start making DSLs (step 3), I usually sketch the processes in the domain. Flow charts and even ER can be repurposed for this. However, the focus is not on flow of data or contol, or on concepts, but on knowledge, languages and technology/tools and costs of mapping different kinds of knowledge. This helps process analysis.

Domain analysis: before going to metamodelling, I create an ontology of the problem domain. This is the most concise and close to customer world summary of domain knowledge. Modelling this has its specifics, that again are not directly supported by available tools. I tend to use simple ER language and spend too much time manually maintaining consistency and readability of domain models.  

 

(The above is not a common practice, but what I found useful in my work.)

 

 

 

>> ... embrace the "unembraceable"... four different things...

> Yes, these aspects are present, what is the problem with that? I

> mean, to compare MDx approaches, one has to understand the

> various implications and connections. In which way would you like

>to separate them to make them more comprehensible?

 

The problem is if these are implicit in the discussion, which is bad for communication. It is good to make them explicit and to establish links among them.. In which way to do it? I don't know.. focus on each independently and then on relations among them?

 

>> ... measuring metamodel quality...
>
>Thanks for the link. This is indeed useful, I'll do my best to

>incorporate it. I think I should read that metamodelling paper.

Glad the link was useful! :)

 

Andreas, I have to look at your diagrams again and to think about your other points. But this will have to wait until after my vacation :)

 

Andriy

> ...MDE process is just a traditional development process with a few complications...

Ok, I see.

> > > ... drastic change ... knowledge workers ...social/organizational sphere...
> > .. who ...is affected by which ...?
> ...does not matter. MDE does not fixate problem domain, nor particular type of activity...

Hm, I don't get this.

To choose some MDx technology, one of the major issues for next to all companies is the required people and skills. So, to compare MDx technology, this must be addressed.

 

How could "MDE" change that?

Maybe I do not understand what you precisely mean by "MDE"...


> > Are you referring to business processes or development processes, or both?
> Yes, both.

Ok. And agreed.

> > > ... bad news ... no MDx tech ... for the above work ... focus on step #3
> > ...can't see... should be bad news ... tries to improve...
> I think you are placing step 3 in the context of traditional development process. My comment was in the context of MDE development process. Here all tools I know focus on part of step 3 only.

Don't get this exactly, too. Can you explain what in your understanding is "MDx tech ... for the above work"?

> > > ...domain knowledge/ontology analysis ...
> > ...DSL... [more] support for domain/process analysis/modeling...

> Before I even start making DSLs [...]
> Domain analysis: [...]


I'd be interested in what information the models you describe capture, and what kind of tooling you'd wish for that.
Do you have more information on that? If it gets too much offtopic here, we could get in direct exchange.

> vacation

Have a nice time :)

RSS

Badge

Loading…

© 2017   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service