openArchitectureWare.org

oAW has moved to Eclipse.

At this site you will find information about the outdated version openArchitectureWare 4, only.
Please read our letter of intent for further information.

 

 Forum Index > openArchitectureWare > General Discussions New Topic Post Reply
 General questions on MDA/MDSD, DSLs and so on
 |  Printable Version
Tom85
 Wednesday, March 25 2009 @ 01:15 PM CET (Read 4466 times)  


Status: offline

Registered: 03/25/09
Posts: 13

Hello everybody,
first of all: Please excuse my probably very silly general questions, but I do not know a place where I can ask those general questions on mda/mdsd (if you know a forum please let me know).

In order to be able to refer to certain books, let me introduce some abbreviations:
[Stahl] : Modellgetriebene Softwareentwicklung Techniken, Engineering, Management 2. Auflage
[Petrasch] : Model Driven Architecture - Eine praxisorientierte Einführung in die MDA

Before I start with the questions, I can only say that I appreciate any kind of help and any kind of answer.
I tried to group the questions to make it easier to read the text. At some points I wrote sentences instead of questions. Such sentences are my personal opionion. If something is wrong with this, please let me know.

MDSD vs. MDA (general):
According to [Stahl, Page 4] one goal of MDSD is to find domain specific abstractions and to make these accessible using a formal modeling. Therefore DSLs build a key concept of MDSD.
An important difference between MDSD and MDA is that MDSD does not "force" you to build platform independent and platform specific models, right? This is just part of the MDA, which is finally a "kind of" MDSD respectively an initiative of the OMG with the goal to standardize MDSD (see [Stahl, Page 5]). This shows that MDA primarily aims at interoperability and portability. Can you say that MDSD aims at automating parts of the software development, by generating running software from formal models? Therefore it does not "dictate" a certain approach (as long as you use formal models) like the MDA? The user can use a DSL, which suits his domain and therefore certain parts of the application can automatically be generated.

MDSD vs. MDA (DSL's):
MDSD does not restrict you to use dsl's based on uml, right? In contrast to that MDA focusses on uml-based modeling languages (see [Stahl, Page 5]), which means on dsl's based on uml? Is that really right? Isn't it possible to use other MOF-based languages? I always thought you could use any MOF-based language. Ok, MOF is based on the UML Infrastructure library and therefore you can say that MDA is merely based on UML. Or do I understand something wrong? See [Petrasch, Page 78], there it is said that for the mda (PIM,PSM and PM) other languages besides uml can be used, as long as their metamodel is based on MOF. Also see [Petrasch, Page 130].

In case of MDA you have two possibilities to build your DSL: Using UML Profiles or directly extending the existing uml-metamodel. Is that right? See [Stahl, Page 66 ff]. Using UML Profiles corresponds to a lightweight extension and extending the existing metamodel corresponds to heavyweight extension. In [Stahl, Page 67] it is said that the extension using uml profiles is limited to uml. But isn't the profiles-package part of the UML Infrastructure Library? According to [Petrasch, Page 74] the lightweight approach is not only usable in the context of uml-metamodels, as it is residing on the metametalevel, which means all mof-based metamodels can use this extension mechanism. Isn't that a contradiction (between [Stahl] and [Petrasch]?).

Transformations (MDA theory vs. MDA practice):
The general transformation scheme is as follows: We have a PIM and a PM (PDM). These two models build the input of a transformator. The transformation finally leads to a PSM, which can be transformed into the PSI. Does the general MDA approach (in the theory) necessarily include the marking of the PIM? Like this: Create your PIM and create your PM. Mark your PIM using Marks defined by the PM. The marked PIM and the PM are the input for the transformator, which returns the PSM. Or is it possible to transform the PIM and PM into the PSM without markings (according to the mda theory)?

If I got it right this approach is usually not used in real projects. Instead of it the code is usually generated directly from the marked PIM. By the way, isn't the uml profile which belongs to a cartridge, the PM? This profile defines the marks, which are used to mark the PIM. The marked PIM is finally transformed to code by using the templates defined within the generator.

Relationship between EMF and MDA:
Using EMF I can build my own metamodels (based on Ecore) and Ecore corresponds to MOF, concerning the metalevel - is that right? Using other tools I can build my own modeling editors for my own metamodel and so own.
Doesn't that mean that I do not use the MDA approach as soon as I use EMF? I read somewhere that Ecore is more or less identical to EMOF, but Ecore is not based on MOF or? Building your own metamodels using EMF is part of MDSD, but not of MDA or did I get something wrong?

AndroMDA vs. oaW:
Is AndroMDA limited to MDA? (as the name suggests) oaW can be used in combination with lots of other tools and meta(meta)models, therefore it is suitable for MDA and MDSD. Is such a statement too much simplified or is it true?

I know that I have lots of questions and lots of probably very very silly questions. But I'm willing to learn more about MDA/MDSD and of course oaW ;) I appreciate any kind of help! Thank you very much in advance.

Greets Tom


 
Profile Email
Quote
Meinte Boersma
 Wednesday, March 25 2009 @ 01:49 PM CET  
Forum Expert
Expert

Status: offline

Registered: 10/20/07
Posts: 940

These are a lot of questions, so I'm not going and try to answer them all fully.

In general: MDA is a (proposal to a) paradigm for creating software (or even loftier: architectures) so it's not just a methodology but also a set of standardized specifications and a way of thinking. MDSD is also a paradigm but a lot less stringent in it's interpretation and the basic driver seems to be to "get things done" along the most sensible and efficient route instead of through one very general and in many situations largely unapplicable route (as is the case with MDA).

EMF vs. MDA:
MDA is a (proposal to a) paradigm whereas EMF is "just" a framework which indeed allows you to define meta models and editors etc. for them. There are elements which are part of the OMG's MDA proposal which have counter parts in EMF (which then have an actual implementation), being the things you already mentioned: Ecore and MOF are almost identical -with the "almost" rendering them incompatible, hence e.g. UML needs an EMF-specific implementation.
MDSD doesn't imply "use EMF" at all, period. EMF is not part of MDSD, either -nor is it part of oAW, for that matter. (In fact, it's a common misunderstanding that oAW's type system is based on EMF "under the hood". It's not, but usually using EMF is by far the quickest way to get integrated.)

AndroMDA vs. oAW:
Can you really say that a tool is MDA? It's just a tool, after all. You could say it conforms to MDA, and as far as I can see AndroMDA (last experience: version 3.2 or something) does conform to AndroMDA...which seems to limit AndroMDA in itself because the tool's really centered around PIM/PSM. It provides great out-of-the-box functionality but you'd better not want to deviate from that as that's quite painful to do.

MDA and UML:
MDA seems to be tied in with UML to a great extent, but I don't think they're really coupled even though they both are coined by the OMG. Having said that, I haven't really seen MDA being done outside of the context of UML so in practice they seem to be coupled.

UML and profiles:
The profile mechanism of UML is an abberation -there; I've said it Wink The problems are manifold:
1. Usually, almost all of the model's semantics reside in the use of stereotypes and tags from these profiles instead of in actual UML constructs. So, you've already defined a "heavyweight meta model extension", but you just don't know it.
2. Defining a "lightweight extension" in UML itself and then using that to provide extra semantics (basically at "interpretation-time") is an act of meta-level crossing, which is prone to really odd problems (and severe headaches for most of us, in the very least), and in fact, these happen quite a lot (both the problems and the headaches).

My $0,02 for now...


 
Profile Email
Quote
Tom85
 Wednesday, March 25 2009 @ 02:22 PM CET  


Status: offline

Registered: 03/25/09
Posts: 13

Thank you very much for your quick and extensive answer.

Quote by: Meinte+Boersma
EMF vs. MDA:
MDA is a (proposal to a) paradigm whereas EMF is "just" a framework which indeed allows you to define meta models and editors etc. for them. There are elements which are part of the OMG's MDA proposal which have counter parts in EMF (which then have an actual implementation), being the things you already mentioned: Ecore and MOF are almost identical -with the "almost" rendering them incompatible, hence e.g. UML needs an EMF-specific implementation.
MDSD doesn't imply "use EMF" at all, period. EMF is not part of MDSD, either -nor is it part of oAW, for that matter. (In fact, it's a common misunderstanding that oAW's type system is based on EMF "under the hood". It's not, but usually using EMF is by far the quickest way to get integrated.)

Of course you are right, it was not my intention to directly compare EMF and MDA. I tried to find out more about their general relationship, that is: If you try to develop conform to the MDA paradigm, can you still use EMF as a framework to define meta models etc. Isn't the UML2-Framework based on a Ecore Meta model? That is, isn't the UML2 Project (from Eclipse) the realisation of the UML2 Meta model using the ecore meta meta model?
Ok, following the MDSD approach does not imply "use EMF", but I can certainly follow the MDSD approach building my metamodels using Ecore or by using the EMF Framework in general?

Quote by: Meinte+Boersma
AndroMDA vs. oAW:
Can you really say that a tool is MDA? It's just a tool, after all. You could say it conforms to MDA, and as far as I can see AndroMDA (last experience: version 3.2 or something) does conform to AndroMDA...which seems to limit AndroMDA in itself because the tool's really centered around PIM/PSM. It provides great out-of-the-box functionality but you'd better not want to deviate from that as that's quite painful to do.

I probably expressed it vaguely. I wanted to say, as you said, that it conforms to MDA.

Quote by: Meinte+Boersma
UML and profiles:
The profile mechanism of UML is an abberation -there; I've said it Wink The problems are manifold:
1. Usually, almost all of the model's semantics reside in the use of stereotypes and tags from these profiles instead of in actual UML constructs. So, you've already defined a "heavyweight meta model extension", but you just don't know it.
2. Defining a "lightweight extension" in UML itself and then using that to provide extra semantics (basically at "interpretation-time") is an act of meta-level crossing, which is prone to really odd problems (and severe headaches for most of us, in the very least), and in fact, these happen quite a lot (both the problems and the headaches).

I'm probably wrong, but I do not understand this part of your answer. According to the book the lightweight approach corresponds to using UML profiles. Do you define your lightweight extension in a different way? Otherwise I do not understand why this extension is prone to problems.

To summarize the part on the dsl's : Following MDA (usually) means defining an uml profile, that means that I can define my DSL using UML Profiles. Is that right?

Thank you very much again.


 
Profile Email
Quote
Meinte Boersma
 Wednesday, March 25 2009 @ 03:37 PM CET  
Forum Expert
Expert

Status: offline

Registered: 10/20/07
Posts: 940

You're asking a lot of "can you ... ?". The rough generic answer to these is "Yes (you can)!" Wink The slightly more subtle generic answer "Yes, you can provided you put enough time in it and can put up with negative and derisive comments from people who think you're abusing the Principles." Wink

In any case: UML2 is defined using MOF (in a bootstrap-kindof way), but the only widely used implementation (at least in the Java world) is based on EMF, so it has a meta model defined in Ecore and an implementation which is largely generated (albeit in a way which is slightly different than the standard EMF code generation). (Btw: you should see the trickery required to get profiles working in the EMF universe. It serves as a very succint way of explaining why "dynamic" meta model extension are a bad idea generally.)

Just as MDSD doesn't imply EMF, EMF doesn't imply MDSD. Whether you want to do MDSD using EMF or AnyFrameworkWhichWhyTheLuckyStiffCookedUpOnARainySundayAfternoonBeforeTeaTime, doesn't matter fetid kidney dingo's Wink

I think [Stahl] actually means "technically lightweight" by "lightweight". My point is that this might be an illusion in many situations: it may seem technically simpler, but it can give you a lot of problems elsewhere which are then really hard to solve in a good way. Problems can range from purely technical ("Can't seem to get my profiles recognized by oAW." - not uncommon, given the forum messages) to integration-related ("My models aren't validated at editor-time, only until generation-time.") to really intrinsic ("You can't model this using UML + profiles."). When this occurs, it is good to pause and rethink your decision to stick with UML + profiles.

I think your summary is correct with a non-optional "usually".


 
Profile Email
Quote
Tom85
 Wednesday, March 25 2009 @ 04:05 PM CET  


Status: offline

Registered: 03/25/09
Posts: 13

Quote by: Meinte+BoersmaYou're asking a lot of "can you ... ?". The rough generic answer to these is "Yes (you can)!" Wink The slightly more subtle generic answer "Yes, you can provided you put enough time in it and can put up with negative and derisive comments from people who think you're abusing the Principles." Wink

I'm a supporter of Obama, therefore I like your answer ;) I do not want to disturb you or others in this forum in any kind of way, therefore please excuse the amount of stupid questions.

Quote by: Meinte+Boersma
Just as MDSD doesn't imply EMF, EMF doesn't imply MDSD. Whether you want to do MDSD using EMF or AnyFrameworkWhichWhyTheLuckyStiffCookedUpOnARainySundayAfternoonBeforeTeaTime, doesn't matter fetid kidney dingo's Wink

Ok, I think I got it. I searched for this framework ("AnyFramework..") but I couldn't find it. No, just kiddin' ;)

Thanks again. I'm glad that there are people like you helping beginners like me!

After all I think the only part left is "Transformations". I would really appreciate an answer to this part. Thanks in advance. I do not expect Meinte Boersma (btw. which part of the name is the surname? I just wondered reading the name) to answer. Instead I'm just happy about any kind of answer.


 
Profile Email
Quote
Christoph Wienands
 Friday, March 27 2009 @ 12:54 AM CET  


Status: offline

Registered: 03/26/09
Posts: 8

Hey all,

I thought I'm gonna chip in my 2 cents as well :-)

For that matter I will equate MDSD with domain-specific modeling, which in my opinion is pretty much the same but if anybody disagrees with that I'll be happy to listen. The most important aspect of DSM is to encapsulate the concepts and rules from the problem/business domain in a domain-specific language, which then can be used to efficiently create models, from which in turn you can generate code or transform captured information to other models.

To explain the problem domain a little bit better, for example a DSL for factory automation would provide concepts such as conveyor belts, machines, valves, timers, workflows, etc. These are the concepts that the domain experts, the process engineers, understand and can work with. In contrast, the solution domain stands for concepts such as computer, node, network, process, component, thread, etc. By separating the two, domain experts can model solutions without needing explicit knowledge about the underlying solution platform. The mapping between the abstract concepts from the problem domain and the implementation concepts of the solution domain is provided by generators, which transform DS models into executable solutions. Software engineers then add the solution-specific parts. Unlike with traditional approaches where domain experts provide requirements to software developers who have to interpret them and build solutions according to their understanding, with DSM domain experts play an active part in the software development process.

This is very similar to the PIM approach of MDA. What DSM does not prescribe is the intermediate transformation into a PSM, which is generated from a PIM and from which the software is generated. Personally I don't see a point in doing that and that's also the reason why I think the theoretical MDA cannot work. You're starting out with a pretty abstract model. No matter how many transformations or code generations you execute from this model, unless you manually add information at later stages the end result will never contain more information than your original, abstract model. Therefore, if your primary PIM does not have enough information you will never ever achieve 100% and automatic code generation from that. So why bother strictly defining PIM, PSM, etc.?

With the looser definition of DSM you capture whatever information you can through one or more high-level modeling languages, then less abstract, more implementation-related information through manually written source code, configuration, or even other, lower-level DSLs (please excuse me if I'm not expressing myself super-precisely but I hope you understand my point ;-)

Ecore/EMF are metamodeling frameworks with which you can build the foundation for DSLs. Add a visual (e.g. GMF) or textual editor (e.g. xtext) on top of that, a code generator (e.g. JET or xpand) and have the toolkit for building a DSL. Another difference to MDA is that, as you mentioned it, MDA heavily builds on UML. The problem with UML is that you're pretty much locked into diagram styles offered by UML (boxes and lines). UML can be extended with profiles but it is very difficult to remove what you don't need (if you're following the standards). If you drop that UML focus, you are free to use concrete syntaxes (textual or visual) that are much more natural and intuitive to domain experts than a class diagrams, and limit the available concepts to exactly what is needed.

I can recommend a very good book that specifically goes into the technology-independent aspects of DSM. It's "Domain-Specific Modeling" written by Kelly and Tolvanen.

Greetings,

Christoph


 
Profile Email
Quote
Sven Efftinge
 Friday, March 27 2009 @ 06:31 AM CET  
Forum Moderator
Moderator

Status: offline

Registered: 08/21/05
Posts: 760


Thanks again. I'm glad that there are people like you helping beginners like me!

I'm also glad that we have such a smart guy helping the users.
I really agree with everything Meinte said.


After all I think the only part left is "Transformations". I would really appreciate an answer to this part. Thanks in advance. I do not expect Meinte Boersma (btw. which part of the name is the surname? I just wondered reading the name) to answer. Instead I'm just happy about any kind of answer.[/p]


Basically this idea of transforming models between PIMs and PSMs is stupid, because it
presumes that you want to switch platforms and therefore want to introduce all kinds of complexity.
Personally, I don't care whether something is MDSD, MDA, DSM or compiler construction. It just doesn't matter as long as you do it to get your things done. The most important thing is that you do not stick to dogmatic guidelines.
That said, there are of course scenarios where model transformations are important. But that really depends on your problem at hand.

Cheers,
Sven


 
Profile Email Website
Quote
Tom85
 Friday, March 27 2009 @ 10:30 AM CET  


Status: offline

Registered: 03/25/09
Posts: 13

Thank you very much for your answers. I tried to understand the differences between the approaches in order to be able to focus on a certain area. I want to write my Master Project on a topic from this area, therefore I try to find out what I can look at and what I can do in the Master Project. Therefore it was important for me to understand the differences, as I didn't want to say "ok, I'll handle the MDA approach" and later in an example I'm using stuff that is actually not part of the MDA approach. Perhaps this shows why I tried to differentiate.

A last point concerning UML profiles vs. Direct extension of the uml meta model: I looked at the "classic uml" example from the oaw-reference. There you didn't use an uml profile but direct extension of the meta model. This can always be done and should be used (in "practice"), since using profiles actually contains some problems? (see the first post of Meinte).

Btw. I looked at the forum and at some "AndroMDA vs. oaW" posts. In these posts most said that the main advantage of AndroMDA is that you can develop easy standard applications quite fast, because it provides some cartridges. But as there are some cartridges for oaW (fornax platform), I get the impression that even for quite simple applications oaW is the better choice. Moreover oaW seems to be much more flexible and powerful.

Greets, Tom


 
Profile Email
Quote
Meinte Boersma
 Friday, March 27 2009 @ 01:24 PM CET  
Forum Expert
Expert

Status: offline

Registered: 10/20/07
Posts: 940

Let me be clear on what I said about the profiles: I am not saying "don't use profiles", I was merely pointing out various problems you can have with using UML+profiles as opposed to defining a custom meta model which is made-to-fit. I (definitely) wouldn't go the way of extending the UML meta model itself: it seems to me that that approach has all the disadvantages of using UML (with or without profiles), none of the advantages of using a custom meta model and all of the disadvantages of using a custom meta model, the necessity to build custom tooling for it being the most important one of the latter.

About Fornax: that is becoming quite mature as of late (last 2 years) and is also a good example of application modeling outside of UML. I'm not familiar with recent versions of both, though, so I can't really comment. AndroMDA does seem to have more cartridges which are a little more buzz word bingo-compliant than Fornax' architectural stack, which may seem a pro for the more enterprisy types.

As for the transformations, it's really what Sven said: adhering to a strict PIM -> PSM approach is ridiculous. You should see how "real MDA"-ists are struggling to fit everything inside that "one transformation"-approach and failing and/or disregarding reality in the process. In fact, it's like saying "do all your coding in one Java Main class" Wink I think one of the most important realizations/insights I had over the past couple of years, is that profiles/(custom) meta models, DSLs, generator, transformations, etc. are all software as well and that you should use the same practices in creating, maintaining and adapting those artifacts as in your "regular" software. In fact, you should adhere to those practices even more stringently since a bug in your "meta software" probably leads to a lot of bugs in your regular software (i.e., the generated stuff + what's hand-crafted against it behind the Generation Gap) and thus to loss of productivity and whatnot. In that respect, you should create/write/implement any model transformation keeping principles like chain of responsibility, encapsulation, loosely coupledness and such in mind. This also means that one big transformation is not very desirable and should probably be broken up in various stages or parts. In turn, this means that you'll probably see opportunities to realize certain requirements in a more natural and meaningful way by inserting them somewhere into the chain of transformations, instead of always before or after the transformation.


 
Profile Email
Quote
Tom85
 Wednesday, April 01 2009 @ 08:12 AM CEST  


Status: offline

Registered: 03/25/09
Posts: 13

Quote by: Meinte+Boersma

Let me be clear on what I said about the profiles: I am not saying "don't use profiles", I was merely pointing out various problems you can have with using UML+profiles as opposed to defining a custom meta model which is made-to-fit. I (definitely) wouldn't go the way of extending the UML meta model itself: it seems to me that that approach has all the disadvantages of using UML (with or without profiles), none of the advantages of using a custom meta model and all of the disadvantages of using a custom meta model, the necessity to build custom tooling for it being the most important one of the latter.


Ok, then I got this part wrong.

Quote by: Meinte+Boersma


As for the transformations, it's really what Sven said: adhering to a strict PIM -> PSM approach is ridiculous. You should see how "real MDA"-ists are struggling to fit everything inside that "one transformation"-approach and failing and/or disregarding reality in the process. In fact, it's like saying "do all your coding in one Java Main class" Wink I think one of the most important realizations/insights I had over the past couple of years, is that profiles/(custom) meta models, DSLs, generator, transformations, etc. are all software as well and that you should use the same practices in creating, maintaining and adapting those artifacts as in your "regular" software. In fact, you should adhere to those practices even more stringently since a bug in your "meta software" probably leads to a lot of bugs in your regular software (i.e., the generated stuff + what's hand-crafted against it behind the Generation Gap) and thus to loss of productivity and whatnot. In that respect, you should create/write/implement any model transformation keeping principles like chain of responsibility, encapsulation, loosely coupledness and such in mind. This also means that one big transformation is not very desirable and should probably be broken up in various stages or parts. In turn, this means that you'll probably see opportunities to realize certain requirements in a more natural and meaningful way by inserting them somewhere into the chain of transformations, instead of always before or after the transformation.


Thanks for your answers.

Do you know "good" introductory topics I could work on? The comparison of certain tools and the implementation of an application using AndroMDA or oAW has been treated several times before. As I'm currently missing a real overview, its a bit hard to define a marked-off topic. I appreciate any kind of proposal. I do not expect a proposal of an exact topic, but it would be nice to get to know a coarse subject area.

Finally I want to thank you all for your help. I know that I have to learn a lot, but I'm willing to learn ;)

Greets, Tom



 
Profile Email
Quote
Meinte Boersma
 Wednesday, April 01 2009 @ 08:50 AM CEST  
Forum Expert
Expert

Status: offline

Registered: 10/20/07
Posts: 940

Quote by: Tom85
Ok, then I got this part wrong.

Never mind, I was being a bit terse, anyway Wink

Quote by: Tom85
Do you know "good" introductory topics I could work on? The comparison of certain tools and the implementation of an application using AndroMDA or oAW has been treated several times before. As I'm currently missing a real overview, its a bit hard to define a marked-off topic. I appreciate any kind of proposal. I do not expect a proposal of an exact topic, but it would be nice to get to know a coarse subject area.

It would help if you gave some more info on your background and the kind of thesis you have to deliver, because that really says a lot about the possible scope of the introductory topic. Also, there's a lot of choice but at the same time not very much choice in doing new, but introductory things, since most new stuff takes either a lot of time or a lot of quite specific knowledge -of course, this is true for any Master Thesis' subject Wink

Currently, I'm quite interested in a modern version of executable UML, and more precisely: executing your application directly from the model rather than generating code and deploying that. Apparently, this idea (which has existed for some time now, basically since the beginning of UML) has been around but I've never seen a concrete implementation of it. So, the questions regarding this would be: (1) What is the history of this topic? (2) How does it compare to "old-fashioned" generation (pros, cons)? (3) What should a sensible implementation of this look like?


 
Profile Email
Quote
Tom85
 Thursday, April 02 2009 @ 11:06 PM CEST  


Status: offline

Registered: 03/25/09
Posts: 13

Quote by: Meinte+Boersma
It would help if you gave some more info on your background and the kind of thesis you have to deliver, because that really says a lot about the possible scope of the introductory topic. Also, there's a lot of choice but at the same time not very much choice in doing new, but introductory things, since most new stuff takes either a lot of time or a lot of quite specific knowledge -of course, this is true for any Master Thesis' subject Wink


Concerning model driven software development it is pretty simple: I have absolutely no experience in this subject area, as there are no courses, seminars or something like that on that topic in our university. I justed started to read some books some weeks ago. Of course I'm familiar with object oriented analysis and draft and with other stuff, that is in some parts perhaps related to mdsd - like the development of compilers/parsers.

The kind of thesis is called "Master Projektstudium", which is a kind of master thesis, only a bit less extensive. The good thing and the bad thing as well is that my professor has not specified a topic, therefore it is (more or less) my free choice which topic I'll work on. As I know him quite well, I know that he prefers "practical" topics. It does not mean that there should not be any theory, especially because I usually like some theoretical subjects, but he probably wants to see what "this mdsd thing looks like".


Quote by: Meinte+Boersma
Currently, I'm quite interested in a modern version of executable UML, and more precisely: executing your application directly from the model rather than generating code and deploying that. Apparently, this idea (which has existed for some time now, basically since the beginning of UML) has been around but I've never seen a concrete implementation of it. So, the questions regarding this would be: (1) What is the history of this topic? (2) How does it compare to "old-fashioned" generation (pros, cons)? (3) What should a sensible implementation of this look like?
[/p]

Is it a kind of interpreter for your uml model, which reads your model as an input and which executes the application (like a typical interpreter would do)?


 
Profile Email
Quote
The0retico
 Monday, April 06 2009 @ 01:54 AM CEST  


Status: offline

Registered: 03/04/09
Posts: 4

Hi,
I am also just a beginner and I am writing bachelor's work on MDSD. In the beginning the topis was MDA and UML profiles for enterprise applications development, but during the study of materials me and my lead(from actual software development company) decided, it is not a best approach, so we made it more general with textual dsls etc. I became quite fascinated about this topic, ikt really looks to me as a way of shifting the software development some abstraction layers higher. I am already thinking of some master thesis topics, which imho could be: model versioning, creating mdsd process, model weaving... I can think of much more:) I think there is a lot of space for practical examples. One of which I am seriously thinking is scheduling software. Some things which I would like to see would be XWeave extensions, because I think the tool is too limited compared to its potential. Maybe you could work on heterogenous/homogenous weaving, maybe on non-additive weaving which I suggested previously in this forum.
Executable UML is imho also great topic, because in past it laked standard and afaik there is one coming out of OMG kichen. It would be very interesting to write about model testing and verification in this context.
The last topic which I found interesting is architecture centric mdsd. Would it be possible to test different architectures for one application? Is it possible to get enough information from specification to automatically decide the right architecture?
So as a student, I wish you much luck and fun with your work on mdsd:)


 
Profile Email
Quote
Tom85
 Tuesday, April 07 2009 @ 03:37 PM CEST  


Status: offline

Registered: 03/25/09
Posts: 13

Thank you for your answer! I actually started using textual dsl's and I think its an interesting subject area. Model weaving sounds interesting too, I think I'll take a look at it after I'm a bit more familiar with everything.

Thanks for all the input, I really appreciate that! This is really a nice forum.


 
Profile Email
Quote
Content generated in: 0.86 seconds
New Topic Post Reply



 All times are CET. The time is now 02:27 PM.
Normal Topic Normal Topic
Locked Topic Locked Topic
Sticky Topic Sticky Topic
New Post New Post
Sticky Topic W/ New Post Sticky Topic W/ New Post
Locked Topic W/ New Post Locked Topic W/ New Post
View Anonymous Posts 
Anonymous users can post 
Filtered HTML Allowed 
Censored Content