tag:blogger.com,1999:blog-4242067780986004250.post8636663472911069687..comments2014-06-13T02:56:31.235-03:00Comments on World of Reuse: What should Model-Driven Reuse look like?Vinicius Garciahttp://www.blogger.com/profile/03195836733794481906noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-4242067780986004250.post-68310494749954756612007-09-21T11:17:00.000-03:002007-09-21T11:17:00.000-03:00Thanks for the comments, folks. You are right Edua...Thanks for the comments, folks. You are right Eduardo, I don't see much difference between current MDD ideas and early code generation. When I first saw the term MDD, I though: "Hey! That's what I've been doing!". The only difference that I see (and to me this is a MAJOR difference), is that now it is easier to do that. This means that it is easier to: develop AND maintain modelers and generators. I remember when working with MVCASE, whenever somebody found a bug, they asked me to fix it. There were some jokes, that MVCASE does not work without me being around (it was the truth, for most cases). But now, you can do it yourself! You can build your own generator, your own modeler, and that is a big difference!<BR/>Regarding these names, everyone (specially the industry) started to use MDD to sell their tools. For me, if your process uses a model as a primary asset, then you are using MDD. This means that for you, a model is not only a reference, a document, but is part of the software, and if you need to change something, you do it on the model, and not on the code. In this sense, most of these tools are indeed MDD tools. Some are very limited, of course, they only support a fixed type of model, and only generate one specific type of code. But still, the development is based on a model, right? What MDD researchers are currently trying to do (including myself) is to expand the usage of models throughout the software lifecycle. There are works for modeling aspects, round-trip engineering, model-based simulation (this can save lots of money in some domains).<BR/>Regarding reengineering, I think MDD can help, but I am not sure exactly how. The way I understand, this could work better in some domains, where I already have enough knowledge to build the needed modelers and generators. Nevertheless, this surely deserves some further researching too.Daniel Lucrédiohttps://www.blogger.com/profile/10572570408447629002noreply@blogger.comtag:blogger.com,1999:blog-4242067780986004250.post-83627982255445690662007-09-21T08:28:00.000-03:002007-09-21T08:28:00.000-03:00Hum.. Thinking about the Eduardo's comment, mainly...Hum.. Thinking about the Eduardo's comment, mainly about the use of MDD in reengineering process... could be very interesting.<BR/>Do you remember the works based on transformations, performed at UFSCar? Of course yes :D, but... in the same way that some organizations using tools to generate partial source code, some reengineering/reverse engineering works that use the model recovery (like the works using the Draco-PUC machine + MVCASE/Rational ROSE - mdl language) can be "classified" as MDD-based reengineering approaches (methods, process, strategies, techniques)?Vinicius Garciahttps://www.blogger.com/profile/03195836733794481906noreply@blogger.comtag:blogger.com,1999:blog-4242067780986004250.post-73108230957218150482007-09-21T01:18:00.000-03:002007-09-21T01:18:00.000-03:00Daniel, I am not an expert on MDD, but I have some...Daniel, I am not an expert on MDD, but I have some doubts about it. I remembered when I saw the MVCASE tool in 2000 and it could generate code based on some specification. Nowadays, all the tools which can generate code are called MDD complaint. Thus, was MVCASE a MDD tool seven years ago? I suppose no. But what I am sawing in the market are companies all the time saying things like that, just based on generate <I>partial code</I> such as signatures, etc. On the other hand, I remembered the first works in this direction by <A HREF="http://www.softwaregenerators.com/bio.html" REL="nofollow">Ted Biggerstaff</A> and <A HREF="http://www.cs.utexas.edu/~dsb/" REL="nofollow">Don Batory</A> <I>(see his paper about FDD and MDD in ICSE 07)</I> with software generators which I am not able to see the main differences. Yes, we have a PIM, PSM, transformations, but sometimes the final result for me looks similar. <BR/><BR/>Yes, your comment about how to merge the ideas is important. We have several things in a side of the discussion including things such as DSLs, Code Generators and Applications Generators and what are the differences and how to combine it? We can define several mixes with it. In fact, I think that we could do it and exercise more this idea based on criteria, tools, skills, etc. <BR/><BR/>About the picture – it was amazing – but I have some questions, mainly, after reading your technical report. In this figure, you said that your approach starts just after the domain analysis, is it correct? For me it starts during domain analysis to domain design transition modeling features and others assets (requirements, use cases if applicable). Moreover, if in RiDE you define the domain architecture including classes and components what do you define in this phase? Do you refine the previous assets? Is it a problem? Using a terrible analogy, are the transformation – semantically – similar for the <I>if-defs</I>, for example? <BR/><BR/>On the other hand, changing the point of view, I think that MDD can be useful in reengineering. For example, we can recovery an independent model and after doing the forward in several languages. What do you think about it?Eduardo Almeidahttps://www.blogger.com/profile/01941938498234009016noreply@blogger.comtag:blogger.com,1999:blog-4242067780986004250.post-51602075589749238882007-09-06T11:09:00.000-03:002007-09-06T11:09:00.000-03:00Fred and lica: Propagating changes in the code bac...Fred and lica: Propagating changes in the code back to the model is just one way to keep them synchronized, but is normally the main point of criticism regarding MDD. I think MDD (and round-trip engineering techniques) are still not practical enough to allow such task to be carried out without adding more accidental complexity.<BR/><BR/>What not everybody sees (at least people unfamiliar with MDD), is that we have been using a much simpler technique to maintain model and code synchronized: how often do you change the bytecode of your generated Java classes? How often do you change machine code inside compiled C++ programs? Although some cases require extremely fine tuning, most people NEVER change the generated machine code. It is the same concept in MDD, because source "code" programs as we know are indeed models - textual ones. And they are used to generate lower-level code, through a text-to-assembly transformer (compiler).<BR/><BR/>Now, I agree that a Java program is much closer to the computing universe than a domain-specific visual model, and therefore it is easier to do that kind of generation. However, there are some cases where things are more predictable, such as simple database CRUD operations (see Ruby On Rails). In these cases, it is possible to do the very same thing compilers have been doing, so that you don't need the generated code - and hence model and code remain synchronized. Another good example of that is Netbeans Matisse (the GUI designer). You use a higher level model (the "visual" widgets), and you don't even have to bother about what is being generated.<BR/><BR/>This is where we should focus our work. How to find those "predictable" cases, how to carefully plan the creation of the modeler and the transformations, so that synchronization (fred is right, this is THE most important requirement in MDD) is maintained. And what we are starting to discover is that the domain information, and well-defined variability points, may offer excellent clues about where to focus our efforts and build modelers and transformations to improve productivity and reuse. Of course, it will only work within the domain scope, and probably with some parts of the system only, but hey: if that saves time and effort, why not?Daniel Lucrédiohttps://www.blogger.com/profile/10572570408447629002noreply@blogger.comtag:blogger.com,1999:blog-4242067780986004250.post-83644655293618156322007-09-06T00:20:00.000-03:002007-09-06T00:20:00.000-03:00Good proposal! For sure MDD is a very good soluti...Good proposal! For sure MDD is a very good solution for companies' productivity and reuse. However, one of its problems (at least from my experience) is when you have to do some kind of modification in the generated code. There comes a big problem. <BR/>And this leads to what Fred said: how to synchronize code and model? <BR/>In GMF situation it only allows you to maintain the changes you did in the code, which are identified through tags, when the model's code is regenerated.<BR/>But it is not possible to transfer these changes back to the model.Lica Barachisiohttps://www.blogger.com/profile/02854988917575651180noreply@blogger.comtag:blogger.com,1999:blog-4242067780986004250.post-73830704974337231922007-09-05T18:26:00.000-03:002007-09-05T18:26:00.000-03:00Good post! But, since you ask us to provoke the di...Good post! But, since you ask us to provoke the discussion, have you read the recent article <B><I>The Inevitable Cycle: Graphical Tools and Programming Paratigms</I></B>, in IEEE Computer, vol 40, issue 8? The idea behind this article is that, no longer, programmers turn back to low level paradigms, against graphical modeling tools or tools for automated code/systems generation.<BR/>According this, i think that the UML is the next technology to disappear, like other examples listed in the article. But not to give place to a new low level technology... maybe to give place to MDD. But will MDD give place to a higher or lower level development technology? It depends on how do programmers feels about both technology.Yguaratã C. Cavalcantihttps://www.blogger.com/profile/18443060218459700151noreply@blogger.comtag:blogger.com,1999:blog-4242067780986004250.post-17508738492172570422007-09-04T17:08:00.000-03:002007-09-04T17:08:00.000-03:00Good speech, Lucrédio! It is really good to see yo...Good speech, Lucrédio! It is really good to see your belief in this software branch where controversially many companies stay away from. In my point of view this happens because the lack of information about its advances, resources and ongoing studies like yours. I believe this technology is promissory, however, I also understand that more successful cases should be published to sell the idea. In addition I guess “modelware” initiative, at least initially, is not mature enough to comprise all kind of development. I am not sure, but I suppose it should work better for product line. Correct me if I am wrong. Additionally I provoke you: “how flexible the modelware are in terms of code and model synchronization?” I mean, how mature are the modelware technologies to reflect in the model eventual code improvement? Particularly, this is a feature the will credit modelware at the marketplace. Good luck my friend!Fred Duraohttps://www.blogger.com/profile/07941402295240624449noreply@blogger.com