Acceleo 2

Here we are, EMF Compare 2.1.0 is just around the corner. This was a very exciting, yet very busy year. EMF Compare 2.0 was released last summer, laying out the foundations for all of the cool stuff we wanted to (but could not) include. Now, 2.1.0 ... [More] comes to fill the gap between the 1.* and 2.* streams, most notably through the re-introduction of support for graphical comparisons.So what can you really expect from Compare 2.1? Let's skip the project life and focus on the cool features that can now be used.Graphical ComparisonWe introduced a "preview" support of the graphical display of differences into the project in its fifth milestone (M5) back in february. This was one of the biggest features we wanted to polish for the release, and polished it has been :).This support is quite generic, and it should be able to handle most GMF-based modelers without too much work from their side (a few extensions are needed to tell EMF Compare how to open their diagrams). For now, our primary target was Papyrus.Though the differences themselves were all pretty well detected, we were not happy with how they were displayed in this first draft. The decorators we use to tell the users "what changed in there?" were thus our primary focus. Here are a few examples of the differences that can be detected in Papyrus UML diagrams... and how we display them in said diagrams.Adding a ClassBoth "new" and "old" models are displayed, on the left and right sides respectively. The Class "A" has been added : it is highlighted in the left (new) diagram, and a transparent placeholder for its shape is shown over the right (old) diagram.Removing a featureWithin lists, the placeholder is shown as a single line:And if we need some context to understand the change?Some changes cannot be understood if shown alone. For example, cascading differences (delete a package and all of its content) need some context to understand the differences related to said "content". Likewise, if we delete both sides of an association along with the association itself, we'll need contextual information to understand the association difference. This is handled through lighter-colored placeholders.What about conflicts?In case of conflicts, we try and highlight all related information on all three sides of the comparison:Comparing models without identifiersOne of the hardest part of comparing EMF models is that we need to "match" the elements contained by these models together. When we are given two instances of a given model in two different versions, we need a way to tell that some package "library" in the first version is the same element as the package "library" in the second version. Likewise, we need to be able to tell that the attribute "pages" of a class "Book" in the first is the same as the attribute "length" of the class "Book" in the second version before we can even tell that there is a difference on that attribute (it has been renamed).When we have identifiers in our model, this is an easy matter. We assume that the identifier of one given object has not changed between the two versions. However, this is not always (rarely, in fact) the case. EMF Compare 2.1.0 re-introduces support for such models, computing and matching objects through their similarity. For example, here is the result of comparing two ecore files together:Enhanced user experienceThe amout of data we compute is quite large, reflecting the accuracy we desire for the comparison; and the number of differences between two versions of the same model can be daunting. We strived to improve the comparison UI in order to provide a much more precise and intelligible information. We've used two means to that end, both of which can be extended by clients of the API.Grouping differences togetherBy default, EMF Compare does not group differences, and simply displays them as they've been detected: One of the options we provide by default lets you group these differences according to their originating side (in the case of three-way comparisons, comparing with a remotely controlled version for example), along with a special group for the conflicts (if any):Filtering differences out of the viewA second option (of course, both can be combined) to limit the number of visible information is to filter out differences that could be considered somewhat as "noise". For example, EMF Compare detects all differences within the containment tree: if the Class "Book" has been removed, then of course its attribute "pages" has been removed. And in turn, the "type" of this attribute has been unset. Those are three differences resulting from a single one. By default, EMF Compare will not display the "resulting" differences, focusing on the "root" only: However, they are still computed, and they are still there in the comparison. We called these "cascading" differences, and users can choose to have them displayed instead by unticking the associated filter: This has already become too long of a post (kudos if you read all the way till here ;)). Anyone interested in the full list of enhancements and highlights of this release can find it here on the project's wiki, with a little more details. [Less]

Here we are, EMF Compare 2.1.0 is just around the corner. This was a very exciting, yet very busy year. EMF Compare 2.0 was released last summer, laying out the foundations for all of the cool stuff we wanted to (but could not) include. Now, 2.1.0 ... [More] comes to fill the gap between the 1.* and 2.* streams, most notably through the re-introduction of support for graphical comparisons.So what can you really expect from Compare 2.1? Let's skip the project life and focus on the cool features that can now be used.Graphical ComparisonWe introduced a "preview" support of the graphical display of differences into the project in its fifth milestone (M5) back in february. This was one of the biggest features we wanted to polish for the release, and polished it has been :).This support is quite generic, and it should be able to handle most GMF-based modelers without too much work from their side (a few extensions are needed to tell EMF Compare how to open their diagrams). For now, our primary target was Papyrus.Though the differences themselves were all pretty well detected, we were not happy with how they were displayed in this first draft. The decorators we use to tell the users "what changed in there?" were thus our primary focus. Here are a few examples of the differences that can be detected in Papyrus UML diagrams... and how we display them in said diagrams. Adding a ClassBoth "new" and "old" models are displayed, on the left and right sides respectively. The Class "A" has been added : it is highlighted in the left (new) diagram, and a transparent placeholder for its shape is shown over the right (old) diagram. Removing a featureWithin lists, the placeholder is shown as a single line: And if we need some context to understand the change?Some changes cannot be understood if shown alone. For example, cascading differences (delete a package and all of its content) need some context to understand the differences related to said "content". Likewise, if we delete both sides of an association along with the association itself, we'll need contextual information to understand the association difference. This is handled through lighter-colored placeholders. What about conflicts?In case of conflicts, we try and highlight all related information on all three sides of the comparison: Comparing models without identifiersOne of the hardest part of comparing EMF models is that we need to "match" the elements contained by these models together. When we are given two instances of a given model in two different versions, we need a way to tell that some package "library" in the first version is the same element as the package "library" in the second version. Likewise, we need to be able to tell that the attribute "pages" of a class "Book" in the first is the same as the attribute "length" of the class "Book" in the second version before we can even tell that there is a difference on that attribute (it has been renamed).When we have identifiers in our model, this is an easy matter. We assume that the identifier of one given object has not changed between the two versions. However, this is not always (rarely, in fact) the case. EMF Compare 2.1.0 re-introduces support for such models, computing and matching objects through their similarity. For example, here is the result of comparing two ecore files together:Enhanced user experienceThe amout of data we compute is quite large, reflecting the accuracy we desire for the comparison; and the number of differences between two versions of the same model can be daunting. We strived to improve the comparison UI in order to provide a much more precise and intelligible information. We've used two means to that end, both of which can be extended by clients of the API. Grouping differences togetherBy default, EMF Compare does not group differences, and simply displays them as they've been detected: One of the options we provide by default lets you group these differences according to their originating side (in the case of three-way comparisons, comparing with a remotely controlled version for example), along with a special group for the conflicts (if any): Filtering differences out of the viewA second option (of course, both can be combined) to limit the number of visible information is to filter out differences that could be considered somewhat as "noise". For example, EMF Compare detects all differences within the containment tree: if the Class "Book" has been removed, then of course its attribute "pages" has been removed. And in turn, the "type" of this attribute has been unset. Those are three differences resulting from a single one. By default, EMF Compare will not display the "resulting" differences, focusing on the "root" only: However, they are still computed, and they are still there in the comparison. We called these "cascading" differences, and users can choose to have them displayed instead by unticking the associated filter: This has already become too long of a post (kudos if you read all the way till here ;)). Anyone interested in the full list of enhancements and highlights of this release can find it here on the project's wiki, with a little more details. [Less]

You might have noticed some signs of excitement from us lately, one being the following tweet :4:45 pm : I'm clicking on "send" and it's gonna rock.— Cédric Brun (@bruncedric) 6 mars 2013 What was sent at 4:45pm? a new project proposal for Eclipse ... [More] , one which, in my opinion, is a major event.Let me introduce you to Eclipse Sirius !Have you ever wanted a nice graphical environment customized for your domain data but been discouraged by the complexity of all the technologies needed to create one? Maybe you compromised and decided to use an existing format or notation, even if it does not completely fit your needs, just to benefit from the associated tools. Fear no more! Instead of adapting your needs to some existing tool, with Sirius the tooling adapts itself to you, as it should be. And you don't even need to learn about the Eclipse Modeling stack, we did it for you.That said, if you want to tweak something you can always plug your customization in through the underlying frameworks, namely : GMF, GEF, EMF and the Eclipse Platform.How did it all start ?It's no vaporware. We started the development of Sirius a few years ago with Thales. We've set-up together a great team to build this technology, known as Doremi at that time.Thanks to this collaboration, we've reached a very high level of maturity: Sirius is used in many very large projects within Thales and it's been around in Obeo Designer for a few years already. It is also the foundation of several tools you can already find in the Eclipse Marketplace, some of them being installed by more than 2000 users a month.We are not kidding.This contribution to Eclipse means a whole new team will become commiters. They have been working on Sirius for years and you already know them as contributors. You will now see those guys from Thales and Obeo co-leading and working in the open.What about Obeo Designer ?Sirius is one Obeo Designer's components. Once published via Eclipse the Sirius open source version will be included in Obeo Designer.Sirius being open-source doesn't change much besides strengthening Obeo Designer by significantly growing the user base of one of its components. This means more diverse usages, more tests "in the wild" and potentially more designers to reuse or extend.Obeo Designer remains a commercial product : a strong and open platform to build and deploy your modeling environment with well integrated and tested components. It is the perfect companion for professional usage by bringing collaborative modeling and support.Why ?First because it is in our DNA, we strive to build great products in the open. And our partners are supporting us on this, especially Thales, since Sirius is the result of many years of a joint and rich collaboration with Obeo.Secondly to unleash the energies in Eclipse Modeling. There is a lot of interest in this domain,  companies are in dire need of solutions but the cost to fill the gap between what they need and what Eclipse Modeling provides right now is too high. We are reducing this gap with Sirius and this will trigger more usage and more funding for Eclipse Modeling as a whole.We also want to work with you, fellow commiters and OSS tool providers, in building the best tools ever. We are building a great component, but having a non open-source runtime may slow down its adoption. This last barrier is now gone.Have some questions ?I'm sure you have tons of them. Please use the dedicated Eclipse forum.Want to know more ?I'll be at EclipseCon Boston next week. At 1:30 pm On Tuesday .I'll present the project with Stephane Bonnet from Thales in the session :"Your custom modeling environment definition made easy. At last !"During this session you'll learn about the project, its goals, its current deployments and you'll see it in action with live demos.I will also introduce the project during the Modeling Symposium later the same day !Sirius brings you the ability to quickly define your dedicated editors : diagram, tree, tables, it would be a shame not to show you what you can do with it :  [Less]

You might have noticed some signs of excitement from us lately, one being the following tweet :4:45 pm : I'm clicking on "send" and it's gonna rock.— Cédric Brun (@bruncedric) 6 mars 2013 What was sent at 4:45pm? a new project proposal for Eclipse ... [More] , one which, in my opinion, is a major event.Let me introduce you to Eclipse Sirius !Have you ever wanted a nice graphical environment customized for your domain data but been discouraged by the complexity of all the technologies needed to create one? Maybe you compromised and decided to use an existing format or notation, even if it does not completely fit your needs, just to benefit from the associated tools. Fear no more! Instead of adapting your needs to some existing tool, with Sirius the tooling adapts itself to you, as it should be. And you don't even need to learn about the Eclipse Modeling stack, we did it for you.That said, if you want to tweak something you can always plug your customization in through the underlying frameworks, namely : GMF, GEF, EMF and the Eclipse Platform.It's no vaporware, it's real and it's been around in Obeo Designer for a few years already. It is the foundation of several tools you can already find in the Eclipse Marketplace, some of them being installed by more than 2000 users a month.We are not kidding.This contribution to Eclipse means a whole new team will become commiters. They have been working on Sirius for years and you already know them as contributors. You will now see them working in the open.What about Obeo Designer ?Sirius is one Obeo Designer's components. Once published via Eclipse the Sirius open source version will be included in Obeo Designer.Sirius being open-source doesn't change much besides strengthening Obeo Designer by significantly growing the user base of one of its components. This means more diverse usages, more tests "in the wild" and potentially more designers to reuse or extend.Obeo Designer remains a commercial product : a strong and open platform to build and deploy your modeling environment with well integrated and tested components. It is the perfect companion for professional usage by bringing collaborative modeling and support.Why ?First because it is in our DNA, we strive to build great products in the open. And our partners are supporting us on this.Secondly to unleash the energies in Eclipse Modeling. There is a lot of interest in this domain,  companies are in dire need of solutions but the cost to fill the gap between what they need and what Eclipse Modeling provides right now is too high. We are reducing this gap with Sirius and this will trigger more usage and more funding for Eclipse Modeling as a whole.We also want to work with you, fellow commiters and OSS tool providers, in building the best tools ever. We are building a great component, but having a non open-source runtime may slow down its adoption. This last barrier is now gone.Have some questions ?I'm sure you have tons of them. Please use the dedicated Eclipse forum.Want to know more ?I'll be at EclipseCon Boston next week. At 1:30 pm On Tuesday .I'll present the project with Stephane Bonnet from Thales in the session :"Your custom modeling environment definition made easy. At last !"During this session you'll learn about the project, its goals, its current deployments and you'll see it in action with live demos.I will also introduce the project during the Modeling Symposium later the same day !Sirius brings you the ability to quickly define your dedicated editors : diagram, tree, tables, it would be a shame not to show you what you can do with it :  [Less]

I don't know about you, but at Obeo we're preparing for EclipseCon North America. Eclipse Conferences are great, so many things are built on top of Eclipse or within the Eclipse projects. Tooling of course, but also rich applications, runtimes, you ... [More] can get a clear vision of what's going on in these areas in just a few days being there.  You could think : "all right, but he is an Eclipse commiter, of course Eclipse conferences are interesting to him". Actualy I'm also CTO at Obeo and when Obeo comes at EclipseCon it's not a one man trip. Seven people from Obeo will go this year to Boston, it's not unusual, and for a company like us it's no small investment.So, with my CTO hat (and not the Eclipse commiter one) let me give you a hint : its worth it !During a few days your team is getting to learn from the source ! The community is so diverse, they will learn about developping mobile apps, web apps, rich applications, runtimes, but also about product management, tooling, business intelligence, quality, processes. They will learn tips and tricks on using technologies and in our world these tips are making the difference between a successful project and a complete failure. The knowledge you'll get is high quality:  you'll learn either from people using the technology day to day or from people actually building the technology !Looking back at the few years the company have been around, there is no doubt Eclipse conferences had the most profound impact on how we use technology and how we develop products.I'll take a few samples from what we are presenting there but make sure you have a look on the program yourself.EMF Compare 2.0 : Scaling to Millions : performance and scalability related talks are in general giving a lot of insight into a technology. Here Mikaël will describe by which mechanisms Compare is now able to produce diffs from models too huge to even be completely loaded in memory and merge these diffs while keeping the model integrity.EMF.Edit : the Force Unleashed : how EMF brings a flexible command support, and how you can use it even not how of an Eclipse context in for instance, a JavaFX application.  "This talk is dedicated to EMF rookies that know EMF as a generator of JavaBeans on Steroids and want to know more about steroids "Documentation Driven Testing : if you think documentation is an important part of your software but you don't want to spend time doing it for nothing.Buildroot Eclipse Bundle : a powerful IDE for Embedded Linux developers : see how Eclipse tools can help in building your complete embedded Linux system.Stop Throwing your doc away : Agile Documentation with Mylyn Intent : you might learn there how the tools from Eclipse can save you a lot of time telling you where your documentation is not up to date.And thats a tiny extract of the conference which has 7 parallel tracks during 3 days +  a full day of 3 hours tutorials.And I am not even mentioning the discussions, the BOF sessions and the keynotes.Well, of course you won't be able to send all your developers there. Just make sure to send those who are good at sharing knowledge with the others and you'll see it will impact both your software and your practices.ps :  better hurry to register [Less]

I don't know about you, but at Obeo we're preparing for EclipseCon North America. Eclipse Conferences are great, so many things are built on top of Eclipse or within the Eclipse projects. Tooling of course, but also rich applications, runtimes, you ... [More] can get a clear vision of what's going on in these areas in just a few days being there.  You could think : "all right, but he is an Eclipse commiter, of course Eclipse conferences are interesting to him". Actualy I'm also CTO at Obeo and when Obeo comes at EclipseCon it's not a one man trip. Seven people from Obeo will go this year to Boston, it's not unusual, and for a company like us it's no small investment.So, with my CTO hat (and not the Eclipse commiter one) let me give you a hint : its worth it !During a few days your team is getting to learn from the source ! The community is so diverse, they will learn about developping mobile apps, web apps, rich applications, runtimes, but also about product management, tooling, business intelligence, quality, processes. They will learn tips and tricks on using technologies and in our world these tips are making the difference between a successful project and a complete failure. The knowledge you'll get is high quality:  you'll learn either from people using the technology day to day or from people actually building the technology !Looking back at the few years the company have been around, there is no doubt Eclipse conferences had the most profound impact on how we use technology and how we develop products.I'll take a few samples from what we are presenting there but make sure you have a look on the program yourself.EMF Compare 2.0 : Scaling to Millions : performance and scalability related talks are in general giving a lot of insight into a technology. Here Mikaël will describe by which mechanisms Compare is now able to produce diffs from models too huge to even be completely loaded in memory and merge these diffs while keeping the model integrity.EMF.Edit : the Force Unleashed : how EMF brings a flexible command support, and how you can use it even not how of an Eclipse context in for instance, a JavaFX application.  "This talk is dedicated to EMF rookies that know EMF as a generator of JavaBeans on Steroids and want to know more about steroids "Documentation Driven Testing : if you think documentation is an important part of your software but you don't want to spend time doing it for nothing.Buildroot Eclipse Bundle : a powerful IDE for Embedded Linux developers : see how Eclipse tools can help in building your complete embedded Linux system.Stop Throwing your doc away : Agile Documentation with Mylyn Intent : you might learn there how the tools from Eclipse can save you a lot of time telling you where your documentation is not up to date.And thats a tiny extract of the conference which has 7 parallel tracks during 3 days +  a full day of 3 hours tutorials.And I am not even mentioning the discussions, the BOF sessions and the keynotes.Well, of course you won't be able to send all your developers there. Just make sure to send those who are good at sharing knowledge with the others and you'll see it will impact both your software and your practices.ps :  better hurry to register [Less]

A lot of things are being worked on for EMF Compare, and while we're polishing the core and refining the user-interface, a few new features have been included in the latest milestones. The biggest focus is on the graphical (GMF) comparison and ... [More] displaying of differences:Graphical ComparisonIt's been a while since I mentionned that graphical comparison with EMF Compare 2 was coming. Well, the feature has been included as a preview in the M5 milestone of EMF Compare (which can be installed from this update site). We can now properly detect and merge graphical differences in GMF models.However, we have now initiated a more thorough reflection on how to display these graphical differences. Our preliminary implementation is not satisfactory:Should we use a custom color code or reuse the "team" colors (those that show on the icon's overlays), should be draw a rectangle "around" the differences or decorate the existing figure's borders, how can we best show that an element has been deleted?We are trying to determine how these differences would be best displayed... and your opinion matters :). If you think you can help on this reflection, or wish to share any thought on this point, the specification of what we expect the graphical display to look like can be found on the wiki. We've initiated a thread on the compare forum for the discussion to take place for anyone interested.Two special integration features for Papyrus and Ecoretools are also contributed, though these only include means to detect "label" differences and may be temporary: labels are computed when displayed, potentially from many distinct other features... thus detecting and merging them is very costly. For the technical, we have to create off-screen editparts and compare the labels textually. Merging requires calls to the direct edit tool when there is one. These integration features may not be kept in the final release. User InterfaceThe second most visible change that's coming with this M5 milestone of EMF Compare is a deep modification of how differences are displayed in the structural view. In short, we previously had a very long sentence that tried to describe the changes in details:While we have reduced this to the bare minimum useful information with this new version:We expect that the simple label, along with the change icon (remote, local, conflict...), will be enough to understand what happened in the model. We add the name of the feature that actually changed along with the type of difference we detected as additional information.The content viewers (the two/three panes displayed as the bottom half of the comparison editor) are also expected to change before Kepler is live. Namely, we are currently changing the way we show the differences in their context. Currently, the only context we offer is the list of siblings of the changed element:For containment changes, this is quite disturbing, and we are changing that to display the whole tree instead (along with the other containment changes detected during this comparison:ExtensibilityEMF Compare is thought and implemented as a framework, and we are striving to provide all extensibility means that could be necessary to tweak, customize or replace the comparison and merging processes. I won't go in much detail here, more information on each possibility will be added to the wiki, or questions can be asked on the forum. Customize the comparison process: Most steps of the comparison process can be modified, be it the matching, differencing, detection of equivalences, detection of conflicts, resolution of the logical model... Custom mergers: We now provide an extensible merging framework so that extenders (or users) can alter the default behavior or contribute their own merging policy for either default or custom differences. Filtering or grouping differences: Differences displayed in the structural view can be filtered and/or grouped together. A number of default options are provided, but new ones can be added seamlessly through extension points. Customized user interface: There are a number of entry points to customize the user interface of EMF Compare. For example, the graphical comparison we were discussing above is entirely contributed to the EMF Compare UI as an extension. Clients can also tweak the labels and icons of the differences, contribute new toolbar actions, ... This is a part that still lacks good documentation, feel free to get in touch through the forum if you need more details on this. [Less]

A lot of things are being worked on for EMF Compare, and while we're polishing the core and refining the user-interface, a few new features have been included in the latest milestones. The biggest focus is on the graphical (GMF) comparison and ... [More] displaying of differences:Graphical ComparisonIt's been a while since I mentionned that graphical comparison with EMF Compare 2 was coming. Well, the feature has been included as a preview in the M5 milestone of EMF Compare (which can be installed from this update site). We can now properly detect and merge graphical differences in GMF models.However, we have now initiated a more thorough reflection on how to display these graphical differences. Our preliminary implementation is not satisfactory:Should we use a custom color code or reuse the "team" colors (those that show on the icon's overlays), should be draw a rectangle "around" the differences or decorate the existing figure's borders, how can we best show that an element has been deleted?We are trying to determine how these differences would be best displayed... and your opinion matters :). If you think you can help on this reflection, or wish to share any thought on this point, the specification of what we expect the graphical display to look like can be found on the wiki. We've initiated a thread on the compare forum for the discussion to take place for anyone interested.Two special integration features for Papyrus and Ecoretools are also contributed, though these only include means to detect "label" differences and may be temporary: labels are computed when displayed, potentially from many distinct other features... thus detecting and merging them is very costly. For the technical, we have to create off-screen editparts and compare the labels textually. Merging requires calls to the direct edit tool when there is one. These integration features may not be kept in the final release. User InterfaceThe second most visible change that's coming with this M5 milestone of EMF Compare is a deep modification of how differences are displayed in the structural view. In short, we previously had a very long sentence that tried to describe the changes in details:While we have reduced this to the bare minimum useful information with this new version:We expect that the simple label, along with the change icon (remote, local, conflict...), will be enough to understand what happened in the model. We add the name of the feature that actually changed along with the type of difference we detected as additional information.The content viewers (the two/three panes displayed as the bottom half of the comparison editor) are also expected to change before Kepler is live. Namely, we are currently changing the way we show the differences in their context. Currently, the only context we offer is the list of siblings of the changed element:For containment changes, this is quite disturbing, and we are changing that to display the whole tree instead (along with the other containment changes detected during this comparison:ExtensibilityEMF Compare is thought and implemented as a framework, and we are striving to provide all extensibility means that could be necessary to tweak, customize or replace the comparison and merging processes. I won't go in much detail here, more information on each possibility will be added to the wiki, or questions can be asked on the forum.Customize the comparison process: Most steps of the comparison process can be modified, be it the matching, differencing, detection of equivalences, detection of conflicts, resolution of the logical model...Custom mergers: We now provide an extensible merging framework so that extenders (or users) can alter the default behavior or contribute their own merging policy for either default or custom differences.Filtering or grouping differences: Differences displayed in the structural view can be filtered and/or grouped together. A number of default options are provided, but new ones can be added seamlessly through extension points.Customized user interface: There are a number of entry points to customize the user interface of EMF Compare. For example, the graphical comparison we were discussing above is entirely contributed to the EMF Compare UI as an extension. Clients can also tweak the labels and icons of the differences, contribute new toolbar actions, ... This is a part that still lacks good documentation, feel free to get in touch through the forum if you need more details on this. [Less]

When you model a system, you use a specific language (meta-model) to represent information. So, you use a particular language fitted to your business needs. It may be required to specialize this model giving a precise semantics on each object, but ... [More] also to rise above it through other business concepts to read, understand, exploit it better or enhance it from different viewpoints. So, you can imagine to manage a requirements model which decorates/references/plugs in a design model allowing to check that this last one is conform to the specifications.In the example below, I focus on the decoration of a UML model with a DSL (Domain Specific Language). The need was to configure a UML model (design of communicating components) and to test these configurations against code generation. Each configuration defines a combination of different and particular communication protocols to use on the connectors between components. And, of course, each protocol brings its own parameters which may be quite difficult to model directly on the UML model (with profile/stereotypes for e.g.) and which may involve structural impacts.To define the DSL, I have chosen to create a generic language to address any model decorations or configurations. The aim is to base on a generic behavior in order to create easily new decoration concepts and to benefit from a set of wired facilities (At the level of meta-model implementation, decoration instantiation with its life-cycle management and code generation). I inspired from the principles of Architectural Description/Styles Language that I extremely simplified, defining two main concepts: a Configuration and a Parameter, a Configuration being able to own a set of parameters. For me, a Configuration or a Parameter are a kind of Decoration.Then I extended this meta-model to define my own decoration in order to configure the UML model with the Ethernet protocol (use case presented below). So, I described an Ethernet Configuration which is a kind of Configuration and which applies on UML connectors. As Parameter of this Configuration, I defined the concept of Container which will be intended to federate the components communicating from each side of the connectors configured with this protocol. An IP address and port number have to be set on each Container.What is presented below can be downloaded from the TopCased project: "UML to real time Java with RTSJ".At the end of the video, I introduce how it is possible to strengthen the understanding of his configuration/architecture, approaching model decoration through graphical viewpoints (out of scope of TopCased project). For that, I rely on the free UML Designer, based on the Viewpoint technology of Obeo Designer, which can be installed from the Eclipse Marketplace and whose the configuration is Open Source. The interest of this designer is that it is easily integrable with other designers based on the same technology and easily extensible.The use case can be watched here: french version hereThis puts in relief other benefits of model decoration.Indeed, it enables to distinct the applicative preoccupations from the architectural ones and to make evolving the last ones easily without impacting the decorated model.Then, it allows to apply, on the same model, different configurations, and so to be modular.Besides, the readability of information is improved through a fit language, some wizards and suitable viewpoints.At last, the UML model is not dependent from some configuration, and so it is more inter-operable. In the same way, the concepts of the decoration may evolve without impacts on the UML model. [Less]

When you model a system, you use a specific language (meta-model) to represent information. So, you use a particular language fitted to your business needs. It may be required to specialize this model giving a precise semantics on each object, but ... [More] also to rise above it through other business concepts to read, understand, exploit it better or enhance it from different viewpoints. So, you can imagine to manage a requirements model which decorates/references/plugs in a design model allowing to check that this last one is conform to the specifications.In the example below, I focus on the decoration of a UML model with a DSL (Domain Specific Language). The need was to configure a UML model (design of communicating components) and to test these configurations against code generation. Each configuration defines a combination of different and particular communication protocols to use on the connectors between components. And, of course, each protocol brings its own parameters which may be quite difficult to model directly on the UML model (with profile/stereotypes for e.g.) and which may involve structural impacts.To define the DSL, I have chosen to create a generic language to address any model decorations or configurations. The aim is to base on a generic behavior in order to create easily new decoration concepts and to benefit from a set of wired facilities (At the level of meta-model implementation, decoration instantiation with its life-cycle management and code generation). I inspired from the principles of Architectural Description/Styles Language that I extremely simplified, defining two main concepts: a Configuration and a Parameter, a Configuration being able to own a set of parameters. For me, a Configuration or a Parameter are a kind of Decoration.Then I extended this meta-model to define my own decoration in order to configure the UML model with the Ethernet protocol (use case presented below). So, I described an Ethernet Configuration which is a kind of Configuration and which applies on UML connectors. As Parameter of this Configuration, I defined the concept of Container which will be intended to federate the components communicating from each side of the connectors configured with this protocol. An IP address and port number have to be set on each Container.What is presented below can be downloaded from the TopCased project: "UML to real time Java with RTSJ".At the end of the video, I introduce how it is possible to strengthen the understanding of his configuration/architecture, approaching model decoration through graphical viewpoints (out of scope of TopCased project). For that, I rely on the free UML Designer, based on the Viewpoint technology of Obeo Designer, which can be installed from the Eclipse Marketplace and whose the configuration is Open Source. The interest of this designer is that it is easily integrable with other designers based on the same technology and easily extensible.The use case can be watched here: french version hereThis puts in relief other benefits of model decoration.Indeed, it enables to distinct the applicative preoccupations from the architectural ones and to make evolving the last ones easily without impacting the decorated model.Then, it allows to apply, on the same model, different configurations, and so to be modular.Besides, the readability of information is improved through a fit language, some wizards and suitable viewpoints.At last, the UML model is not dependent from some configuration, and so it is more inter-operable. In the same way, the concepts of the decoration may evolve without impacts on the UML model. [Less]