We propose a model-based software development process based on UML state machines. State machines are executable models and such models offer the advantage to capture the behavior of a system at a high-level of abstraction. Besides, the business parts of the system can be specified and weave onto the executable models, applying a good separation of concerns. While advanced standards such as fUML enable to define the complete contents of an application at the model level, it leads to too much complexity and prevents flexibility in the use of existing code. For these reasons, we propose an intermediate and pragmatic approach where a UML state machine is compiled onto Java code for our lightweight execution engine PauWare. The business parts of the application are then implemented in standard Java.

The main goal of Model-Driven Engineering (MDE) is to manipulate productive models to build software. In this context, model transformation is a common way to automatically manipulate models. It is then required to ensure that transformation has been correctly processed. In this paper, we propose a contract-based method to verify that a target model is a valid result of a source model with respect to the transformation specification. The verification is made in a black-box mode, independently of the implementation and the execution of the transformation. The method allows the contract to be written in any constraint language. In association with this method, we have implemented a tool that partially generates contracts written in OCL and manages their evaluation for both endogenous and exogenous transformations.

After thirty years, it is reasonably time to critically look at Model Driven Software Development (MDSD). Who may nowadays claim that MDSD has been massively adopted by the software industry? Who may show numbers demonstrating that MDSD allowed/allows massive cost savings in daily software development, but, above all, software maintenance? This paper aims at investigating executable modeling as a balanced articulation between programming and modeling. Models at run-time embody the promising generation of executable models, provided that their usages are thought and intended to cost-effective software development. To envisage this not-yet-come success, this paper emphasizes expectations from the software industry about “reactive programming”. Practically, executable modeling standards like the SCXML W3C standard or the BPMN OMG standard are relevant supports for reactive programming, but success conditions still need to be defined.

The separation of concerns is a fundamental principle that allows to build a software with separate parts, thereby improving their maintainability and evolutivity. Executable models are good potential representatives of this principle since they capture the behavior of a software-intensive system, that is, when, why and how calling business operations, while the latter are specified apart. EMF is the de facto framework used to create an executable DSL (xDSL) but a solution to weave business operations into it is still missing. This is compounded by the fact that such business operations can be tied to specific technological platforms that stand outside the EMF world (e.g. Android SDK). To that purpose, in this paper we describe a solution for managing business operations both at design-time (creation of executable models with EMF) and at run-time (operation calls from the deployed execution engine). This solution is generic enough to be integrated into any Java-based environment and for any xDSL.

Within the model-driven engineering field, the con- cept of “i-DSML” (interpreted Domain Specific Modeling Language) refers to executable models which are interpreted through an engine. While several works discussed the key ingredients of an i-DSML, few of them answered the original question: What is the class of models that are executable by nature and those that are not? This paper attempts to provide some answers by proposing two discriminating criteria: The possibility of defining execution steps and the reification of the behavior of the running system into the executed model. On this basis, we reconsider some well-known DSML and notice a paradoxical situation with UML diagrams.

Dans le contexte de l’ingénierie des modèles, l’exécution de modèles est un des moyens principaux pour supprimer le fossé entre le code, c’est-à-dire le système développé, et le modèle. Pour adapter une exécution de modèles, nous proposons de directement adapter le modèle en cours d’exécution. Cela oblige à rajouter des éléments nécessaires à l’adaptation dans le modèle mais évite d’avoir un second modèle dédié à l’adaptation comme c’est le cas pour les méthodes de type models@run.time. Cet article présente une approche d’adaptation directe d’exécution de modèle par contrats. Si des conditions du contrat ne sont pas respectées, une action d’adaptation doit être entreprise. L’approche est illustrée par un i-DSML (interpreted Domain Specific Modeling Language) de machines à états et un exemple de signalisation ferroviaire avec comme problématique de s’assurer qu’un modèle est adapté à un environnement d’exécution donné.

In the model-driven engineering field, model execution is one of the main ways to fill the gap between the code (i.e. the developed system) and the model. For adapting a model execution, we propose to directly adapt the model under execution. This requires to add onto the model requisite elements for the adaptation but this avoids to have a second model dedicated to the adaptation as for models@run.time. This paper proposes a contract-based approach for directly adapting a model execution. If some conditions of the contract are not respected, an adaptation action has to be undertaken. The approach is illustrated through a state machine i-DSML (interpreted Domain Specific Modeling Language) and an example of a railway signaling based on the ability to ensure that a model is adapted with a given execution environment.

Software adaptation has become prominent owing to the proliferation of software in everyday devices. In particular, computing with the Internet of Things requires adaptability. Traditional software maintenance, which involves long, energy-consuming cycles, is no longer satisfactory. Adaptation is a lightweight software evolution that provides more transparent maintenance for users. This article classifies types of adaptation and describes an implementation of it.

En ingénierie dirigée par les modèles (IDM), le concept de ≪ i-DSML ≫ (interpreted Domain Specific Modeling Language) fait référence à des modèles exécutables qui sont interprétés par un moteur d'exécution. Tandis que de nombreux travaux ont techniquement discuté des élèments constitutifs d'un i-DSML, peu d'entre eux se sont attachés à répondre à la question originelle : quels sont les modèles qui sont exécutables par nature et ceux qui ne le sont pas ? Dans cet article, nous proposons d'y répondre en établissant deux critères discriminants. À la lumière de ces critères, nous reconsidérons quelques DSML bien connus.

Within the model-driven engineering field (MDE), the concept of "i-DSML" (interpreted Domain Specific Modeling Language) refers to executable models which are interpreted through an engine. While several works discussed the key ingredients of a i-DSML, few of them answered the original question: what is the class of models that are executable by nature and those that are not? In this article, we try to answer it by proposing two discriminating criteria. Based on the latters, we reconsider some well-known DSML.

One of the main goals of Model-Driven Engineering (MDE) is the manipulation of models as software artifacts. Model execution is in particular a means to substitute models for code. Precisely, if models of a dedicated Domain-Specic Modeling Language (DSML) are interpreted through an execution engine, then this DSML is called interpreted-DSML (i-DSML for short). The possibility of extending i-DSML to adapt models directly during their execution, allows the building of adaptable i-DSML. In this article, we demonstrate that specializing adaptable i-DSML leads to the potential definition of accurate adaptation policies. Domain-specicities are the key factors to identify adaptations that really make sense. In effect, we introduce the concept of family as a mean to encapsulate adaptation operations that are attached to a particular domain. Families can be specialized with the special purpose of defining a hierarchy of adaptation contexts.

One of the main goals of model-driven engineering (MDE) is the manipulation of models as exclusive software artifacts. Model execution is in particular a means to substitute models for code. More precisely, as models of a dedicated domain-specific modeling language (DSML) are interpreted through an execution engine, such a DSML is called interpreted-DSML (i-DSML for short). On another way, MDE is a promising discipline for building adaptable systems based on models at runtime. When the model is directly executed, the system becomes the model: This is the model that is adapted. In this paper, we propose a characterization of adaptable i-DSML where a single model is executed and directly adapted at runtime. If model execution only modifies the dynamical elements of the model, we show that the adaptation can modify each part of the model and that the execution and adaptation semantics can be changed at runtime.

One of the main goals of model-driven engineering (MDE) is the manipulation of models as exclusive software artifacts. Model execution is in particular a means to substitute models for code. On another way, MDE is a promising discipline for building adaptable systems thanks to models at runtime. When the model is directly executed, the system becomes the model, then, this is the model that is adapted. In this paper, we investigate the adaptation of the model itself in the context of model execution. We present a first experimentation where we study the constraints on a model to be able to determine if it is consistent (that is, adapted) with an execution environment, possibly including fail-stop modes. Then, we state some perspectives and open issues about model execution adaptation.

L'ingénierie dirigée par les modèles (IDM), ou Model-Driven Engineering (MDE) en anglais, a permis plusieurs améliorations significatives dans le développement des systèmes complexes en fournissant des moyens permettant de passer d'un niveau d'abstraction à un autre ou d'un espace de modélisation à un autre. L'occupation clé de cette ingénierie est le modèle, qui est considéré l'élément au premier plan au sein du développement du processus logiciel. De ce fait, l'étude des transformations de modèles constitue un défi majeur pour l'IDM. Il ne s'agit pas seulement de définir et exécuter des transformations de modèles, mais également de s'assurer qu'elles se sont correctement déroulées. La vérification des transformations peut être faite de plusieurs façons, parmi elles la vérification par contrats.

Dans ce document, nous présentons des généralités sur l'IDM et la conception par contrats et nous abordons nos travaux de recherche centrés sur l'utilisation des contrats OCL dans la définition et la vérification des transformations de modèles.

The increasing importance of metamodeling calls for metamodels that are free of ambiguities, contradictions and redundancies. This is specifically the case for the core of UML (Infrastructure). This paper proposes to rewrite a part of this core, the Class and Property metaclasses especially. To avoid infinite regression, the notion of meta-circularity is used. This rewriting is done by means of inductive types in constructive logic. The proposed specification is proven correct using the Coq automated prover. Proven lemmas and theorems about a "metaness" relationship are proposed.

Dans le contexte de l'IDM, l'exécution de modèles est un des moyens principaux pour supprimer le fossé entre le le code, c'est-à-dire le système développé, et le modèle. D'un autre côté, l'IDM ouvre des perspectives intéressantes pour l'adaptation logicielle avec la notion de models@run.time. Les modèles utilisés à l'exécution permettent de représenter l'état du système adaptable et de travailler sur ce modèle pour gérer l'adaptation du système. Quand on exécute un modèle, le système est le modèle et alors l'adaptation est réalisée directement sur le modèle. Dans cet article, nous étudions la notion de contrats d'adaptation qui sont basés sur nos contrats d'exécution. Ils ont pour but de vérifier si un modèle exécuté est adapté à un contexte d'exécution donné. A partir de quelques règles simples de modélisation ainsi que la possibilité de définir une connaissance limitée sur le comportement du modèle ou sur l'environnement d'exécution, nous pouvons définir des hiérarchies de contrats, des plus contraignants jusqu'à la validité de versions dégradées de modèles. Nous appliquons notre approche sur des machines à états UML simplifiées et en utilisant OCL pour exprimer les contrats.

One of the main goals of model-driven engineering is the manipulation of models as exclusive software artifacts. Model execution is in particular a means to substitute models for code. MDE is a promising discipline for building adaptable systems thanks to models at runtime. When the model at runtime is directly executed, the system becomes the model, then, this is the model that is adapted. We propose an approach based on previous execution contracts for defining adaptation contracts. Their goal is to verify that an executed model is valid or has an acceptable failsoft behavior accordingly to an execution environment. If not, the model has to be adapted. Based on some basic modeling rules and the ability to have only a partial knowledge on the model specification and on the execution environment, we can define a hierarchy of contrats, from strongest to weakest. We apply our approach on simplified state machines and using OCL for expressing the contracts.

Regarding the design and the development of distributed applications, service, component and agent oriented approaches provide their own interests and characteristics. Most of current applications are designed according to a single approach but it would be interesting to use these approaches simultaneously to provide a more efficient paradigm for developing distributed applications. Our goal is to integrate these three approaches by focusing on the concepts of service and interaction as key points, notably regarding cooperation between agents and components. The service is the business abstraction of a component or agent and it represents a pivot to support its interactions. We presented previously our service, component and agent models for this purpose. In this paper, we establish the semantic mapping rules between the concepts of each of these domains to be able to move on from one model to another.

Pour le développement d'applications distribuées, les approches orientées services, composants ou agents offrent chacune des intérêts et des caractéristiques propres qu'il serait intéressant de pouvoir utiliser conjointement. Notre but est d'intégrer ces trois approches en se focalisant sur les concepts de service et d'interaction, points clé notamment de la coopération entre des agents et des composants : le service représente l'abstraction métier d'un composant ou d'un agent et permet de les faire interagir. Précédemment, nous avions présenté nos modèles de services, d'agents et de composants dans ce but. Dans cet article, nous établissons les correspondances sémantiques entre les concepts de chacun de ces domaines afin de pouvoir passer d'un modèle à un autre.

Multiagent systems and component-based systems are two mature approaches; each one owns strengths and weaknesses points. Our goal is to integrate these two approaches by reaching a high level of connectivity between them to overcome their shortages. The concept of service plays a key role in their interoperability. Indeed, the relations between these three domains are manifold. From a service perspective, agents and components are considered as service providers or consumers while services can be seen as their functional abstractions. Therefore, the concept of service as the interaction point between agents and component is the base of our integration approach. We will define a specification process composed of several models. They are dedicated to specify an application through several aspects: abstract services, components, agents and mix of them. In this paper, we present a global view of this process and three of its models: service, agent and component ones.

Organizational multi agent systems and component-based systems are two mature approaches; each one owns strengths and weaknesses points. Our goal is to integrate these two approaches by reaching a high level of connectivity between them to overcome their shortages. The concept of service plays a key role in their interoperability; we consider it as the interaction point between agents and components. We will define a model-driven engineering process composed of several DSLs (Domain Specific Languages). They are dedicated to specify an application through several aspects: services, components, agents and mix of them. Several transformations and projections will allow the addition of agent or component features into an application specification. In this paper, we present a global view of this process and of its DSLs.

A model-driven engineering process relies on a set of transformations which are usually sequentially executed, starting from an abstract level to produce code or a detailed implementation specification. These transformations may be entirely automated or may require manual intervention by designers. In this paper, we propose a method to verify that a transformation result is correct with respect to the transformation specification. This method both includes automated transformations and manual interventions. For that, we focus on transformation contracts written in OCL. This leads to making the proposed method independent of modeling and transformation tools. These contracts are partially or fully generated through a dedicated tool.

A model-driven engineering process relies on a set of transformations which are usually sequentially executed, starting from an abstract level to produce code or a detailed implementation specification. These transformations may be entirely automated or may require manual intervention by designers. In this paper, we propose a method to verify that a transformation result is correct with respect to the transformation specification. This method both includes automated transformations and manual interventions. For that, we focus on transformation contracts written in OCL. This leads to making the proposed method independent of modeling and transformation tools. These contracts are partially or fully generated through a dedicated tool.

Un processus logiciel basé sur l'ingénierie des modèles est construit à partir d'un ensemble de transformations qui sont exécutées en séquence pour partir d'un niveau de modélisation abstrait et arriver au code final ou à une spécification d'implémentation détaillée. Ces transformations correspondent pour beaucoup à des raffinements, c'est-à-dire à de l'ajout de détails ou d'information sur un modèle. Ces raffinements peuvent être entièrement automatisés ou nécessiter l'intervention manuelle du concepteur. Nous proposons ici une méthode pour valider que le résultat d'une transformation, y compris lorsque le concepteur intervient manuellement sur les modèles, respecte la spécification d'un raffinement. Nous nous basons pour cela sur des contrats de transformations de modèles écrits en OCL afin de rendre notre méthode indépendante des outils de modélisation et de transformations de modèles.

A model-driven engineering process relies on a set of transformations which are sequentially executed, starting from an abstract level to produce code or a detailed implementation specification. These transformations are mostly refinements, that is to say detail or data added to models. These refinements may be entirely automated or may require manual intervention by designers. In this paper, we propose a method to demonstrate that a transformation result is correct with respect to the specification of the refinement. This method both includes automated transformations and manual interventions. For that, we focus on transformation contracts written in OCL. This leads to make the proposed method independent of modeling and transformation tools.

Model-Driven Development (MDD) corresponds to the building of models and their transformation into intermediate models and code. Modeling components and compositions is a natural consequence of MDD. We show in this paper the advantages of using an executable modeling language associated with a Java library which pre-implements the execution semantics of this language. The proposed executable language is based on UML State Machine Diagrams. The semantic variation points linked to these diagrams lead us to manage equivalent variations in the Java implementation of components. The paper offers a comprehensive component design method based on a tailor-made UML profile whose role is the control of the semantic variation points in models.

L'Ingénierie Dirigée par les Modèles (IDM) arrive à maturité via en particulier une existence de compétences et d'expertises ainsi qu'une offre d'outils structurante pour les applications, autour d'Eclipse Modeling Framework (EMF) pour l'essentiel. Paradoxalement, l'IDM en tant que technologie logicielle achoppe toujours sur les fondamentaux : l'adoption massive et à grande échelle par les développeurs, le caractère formel des modèles (sémantique non-ambiguë, interprétable, voire exécutable), la cohérence entre les niveaux de modélisation (CIM, PIM, PSM et code), la traçabilité du processus IDM, la componentization des applications pour réellement favoriser réutilisabilité et composabilité, et finalement l'interopérabilité des frameworks IDM. Concernant cette dernière préoccupation, l'interopérabilité des dialectes XML comme XMI est insuffisante (quand elle marche !) car MOF 2.0, EMF et maintenant d'autres standards comme Microsoft Domain-Specific Language (DSL) tools divergent. Dans un contexte aussi dynamique, cet article vise à établir le cadre d'évolution de l'IDM, ses orientations probables et pertinentes et finalement ses enjeux.

Nous décrivons ici une approche visant à se concentrer sur la composition hiérarchique lors de la conception et du développement des applications basées composants. Nous rappelons le modèle de composition sur lequel nous nous appuyons qui est basé sur l'expression de propriétés de composition bien identifiées. Nous montrons ensuite comment nous avons implémenté un mécanisme de contrôle de ces propriétés de composition dans Julia, une implémentation du modèle de composant Fractal.

We describe an approach focussing on hierarchical composition of components during both design and development levels. We present an overview of our UML composition model which is based on well-defined composition properties. Thus we present how we have implemented a control mechanism of theses properties into Julia, an implementation of the Fractal component model.

Cet article s'intéresse dans un premier temps à la modélisation et à la simulation des systèmes complexes qui constituent notre champ d'investigation. Après avoir mis en évidence les besoins de cette communauté, des éléments de solution basés sur le paradigme « agent » sont listés. Dans un second temps nous présentons les grandes lignes d'Ugatze, un modèle de composants logiciels développé au sein de l'équipe, dédié à l'ingénierie de systèmes complexes distribués, basé sur le concept d'interaction. Enfin, il décrit l'état de nos réflexions concernant le recours à l'ingénierie des modèles (IDM ou MDE) pour intégrer les paradigmes « agent » et « composant » et définir une architecture de haut niveau pour la simulation distribuée.

A major challenge of the OMG Model-Driven Architecture (MDA) initiative is to be able to define and execute transformations of models. Such transformations may be defined in several ways and with various motivations. Our motivation is to specify model transformations independently of any transformation technology. To achieve this goal, we propose to define transformation contracts. We argue that model transformation contracts are an essential basis for the MDA, they can be used for specification, validation and test of transformations. This paper focuses on the specification of model transformation contracts. We investigate the way to define them using standard UML and OCL features. In addition to presenting the approach and some experimental results, this paper discusses the relevance and limits of standard OCL to define transformation contracts.

Everything changes in our everyday lives: New discoveries, paradigms, styles, and technologies. Frequently, software systems success depends on how they can quickly adapt to requirement or environment evolution. Software architectures are ABSTRACT models at the highest level. As such, they should assume conceptual guidance on what parts of the system changed. However, many software architectures often evolve from an uncoordinated build-and-fix attitude. The result is opaque and not analyzable. We present in this paper a practical experience of using aspect oriented programming principles for managing software architecture specification evolution. Our approach aims at clarifying software architecture evolution steps. It extends software architecture ABSTRACT models for the specification and the analysis of new concern integration.

Lors de la conception et du développement d'applications distribuées, la communication et les interactions entre les composants répartis représentent un point crucial. La spécification d'abstractions d'interaction entre ces composants est donc un élément primordial lors de la définition de l'architecture d'une application. Si bien souvent des abstractions d'interaction de haut niveau sont définies au niveau de la spécification, à celui de l'implémentation il est par contre plus courant de ne trouver que des abstractions bien plus simples (comme des appels de procédure à distance ou de la diffusion d'événements). Pendant le raffinement qui mène à l'implémentation, ces abstractions de haut niveau ont été diluées, dispersées à travers les spécifications et implémentations des composants de l'application.

Nous proposons un processus de réification d'abstractions de communication ou d'interaction sous forme de composants logiciels. Ce processus permet de conserver l'unité et la cohérence d'une abstraction d'interaction pendant tout le cycle de développement d'une application. Que l'on soit à un niveau de conception abstraite, de conception d'implémentation, d'implémentation ou de déploiement, l'abstraction réifiée et manipulée est toujours la même. Ces composants logiciels sont aussi appelés médiums pour les différencier des autres composants d'une application.

Le processus est composé de plusieurs éléments. Le premier est une méthodologie de spécification de médiums en UML. Cette spécification est réalisée à un niveau abstrait, indépendamment de toute implémentation. Dans la terminologie du MDA (Model-Driven Architecture) de l'OMG, il s'agit d'une spécification de niveau PIM (Platform Independent Model). Cette spécification est le contrat du médium qui doit ensuite être respecté quel que soit le niveau de manipulation considéré. Le deuxième élément est une architecture de déploiement de médiums qui offre la flexibilité nécessaire pour implémenter a priori n'importe quelle abstraction d'interaction. Enfin, le troisième élément est un processus de raffinement qui permet de transformer une spécification abstraite de médium en une ou plusieurs spécifications d'implémentation prenant en compte l'architecture de déploiement et différents choix de conception ou d'implémentation. Dans la terminologie du MDA, le processus de raffinement sert à transformer une spécification de niveau PIM en une ou plusieurs spécifications de niveau PSM (Platform Specific Model).

During the development of distributed applications, communications and interactions among remote components are a key-point. The specification of interaction or communication abstractions among these components is thus a major task during the definition of an application architecture. If high-level abstractions are very often defined at the specification level, yet, it is common to find only much simpler abstractions at the implementation level (such as remote procedure calls or event broadcasting). During the refinement process, i.e. from specification to implementation, these high-level interaction abstractions are lost and split among the component specifications and implementations.

We propose a process of reification of interaction or communication abstractions into software components. The process allows the consistency and the unity of an interaction abstraction to be maintained, from abstract specification to implementation. The abstraction manipulated remains unchanged throughout the software process, from abstract specification to implementation and deployment through specification implementation. These components are also called mediums in order to differentiate them from standard software components of an application.

The process is composed of three parts. The first one is a medium specification methodology in UML, at an abstract level, independently of any implementation. In the MDA (Model-Driven Architecture, defined by the OMG) terminology, this specification is done at PIM (Platform Independent Model) level. This specification is the medium contract that has to be fulfilled at all the levels of the software development process. The second part is a medium deployment architecture that provides the necessary flexibility to implement, in principle, any kind of communication or interaction abstraction. The last part is a refinement process, enabling the transformation of an abstract specification into one or several implementation specifications, conforming to our deployment architecture and to the design or implementation choices. In the MDA terminology, the process enables the transformation of a PIM specification into one or several PSM (Platform Specific Model) specifications.

One of the touchstones of Object-Oriented Design is that the management of complexity is seldom located within any single object. It should instead be an emerging property of the collaborations within a society of objects, each one of these being as simple as possible. These collaborations can easily be specified using UML collaboration diagrams. We propose to reify UML collaborations as interaction components. This allows the easy handling and reusing of interaction abstractions among components at both specification and implementation levels. This paper focuses on the specification of these components. We propose criteria to define the type and the `frontier of an interaction abstraction. We present a UML collaboration specification methodology that deals with the constraints of component specification.

Collaborations (between objects) are increasingly being recognized as fundamental building blocks to structure object-oriented design, and they have made their way into UML. But very often the first class aspect of a design level collaboration is lost during the detailed design process, making it difficult to keep good traceability between the design and the implementation. The problem is not simple, because for any given collaboration abstraction, there might be several possible design solutions depending on the many non-functional forces impacting a given application. We propose a process and an architecture in which the notion of collaboration is preserved from analysis to design and implementation, while allowing the designer to change his mind about which particular design trade-off is selected in order to face changing non-functional requirements during maintenance. We illustrate our approach with a case study inspired by the real example of a large French railway company attempting to adapt a flight reservation system to its own context.

Reusable software components are being used more and more in application development. Our approach introduces a new type of component: the communication component (or medium). It is a component that encapsulates any kind of communication service or protocol. Other components, that could possibly be distributed, are connected to these mediums and use their communication services. This paper explains how to specify a medium in UML. A medium is defined by a UML collaboration. The constraint language OCL and statecharts are also used to specify the behavior of the services offered by a medium. This specification has two aims: to define the precise behavior of a medium and to use this in a UML CASE tool to validate the medium and automatically generate code.

Les composants logiciels réutilisables sont de plus en plus utilisés dans la construction d'applications. Notre approche introduit un type de composant particulier : le médium de communication. Il s'agit d'un composant implémentant un service ou un protocole de communication de type quelconque. Les autres composants de l'application, qui seront éventuellement distribués, utiliseront ces services. Cet article explique comment et pourquoi décrire formellement un médium de communication à l'aide d'UML. Un médium est défini par une collaboration UML. Le langage de contrainte OCL ainsi que lesdiagrammes d'états d UML permettent de spécifier le comportement des services de communication offerts par un médium. Cette spécification a deux buts : permettre au composant utilisant le médium de savoir exactement ce que fait le médium et de générer automatiquement du code vers un modèle de composant existant (Entreprise JavaBeans, composants CORBA).