Model decoration
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 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 here
This 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.
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 here
This 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.
Auteur d'origine: Cedric Notot