Un profil RequirementComposerProfile définit la classe Link et le stéréotype RRCElement, avec un attribut de liens qui contient une collection d'éléments de lien. Dans les liens, toutes les informations de com.ibm.rdm.base.Element sont préservées en utilisant l'application du stéréotype RCElement et en copiant toutes les données des liens depuis le modèle d'élément de Rational Requirements Composer vers le modèle UML. L'URL qui se réfère à l'élément Rational Requirements Composer original (tel que Actor ou Usecase) est placée dans un commentaire UML, stéréotypé en tant que URL. Toutes les données des groupes d'attributs sont placées dans la propriété attributeGroup du stéréotype RCArtifact.
Le tableau suivant répertorie les éléments de modèle de spécification pris en charge par la transformation, et la sortie UML correspondante créée par la transformation.
| Métamodèle d'élément RRC | |
|---|---|
com.ibm.rdm.base.Element |
org.eclipse.uml2.uml.NamedElement<<RRCElement>> |
com.ibm.rdm.base.Element :: |
RRCElement::links(<EList>Link) |
com.ibm.rdm.base.Element :: |
org.eclipse.uml2.uml.NamedElement :: |
com.ibm.rdm.base.Element :: |
org.eclipse.uml2.uml.Element :: |
com.ibm.rdm.richtext.model.Body |
org.eclipse.uml2.uml.Comment<<documentation>>:: |
| Métamodèle UseCase | UML 2.0 |
|---|---|
com.ibm.rdm.ba.usecase.Usecase |
org.eclipse.uml2.uml.UseCase |
com.ibm.rdm.ba.usecase.Usecase:: |
org.eclipse.uml2.uml.Element :: |
| Diagramme de cas d'utilisation | Diagramme de cas d'utilisation avec des références d'élément sémantique ajustées de façon à pointer vers un élément transformé de RRC en RSx |
|---|---|
com.ibm.rdm.ba.actor.Actor |
org.eclipse.uml2.uml.Actor |
com.ibm.rdm.ba.actor.Actor::details(com.ibm.rdm.richtext.model.Body) |
org.eclipse.uml2.uml.Element :: |
Connexions entre acteurs et cas d'utilisation |
Associations |
Il existe deux types de diagrammes de processus métier dans Rational Requirements Composer- les processus simples et les processus collaboratifs. Les diagrammes de processus simples sont constitués d'un processus BPMN unique. Les diagrammes collaboratifs contiennent des collaborations entre deux et plusieurs processus métier. Chaque processus BPMN possède un certain nombre de tâches connectées par flux de séquences et associations de données, et il peut ou pas posséder des couloirs, un couloir étant simplement un élément de notation non associé à une sémantique.
Un processus BPMN est transformé en activité UML. Chaque couloir devient une partition et chaque tâche un noeud d'action dans l'activité UML respective.
Chaque processus BPMN est également représenté par l'intermédiaire d'une interface UML. Par exemple, un processus Process1 est représenté par une interface IProcess1 et le type Process2 est IProcess2. Toutes les tâches du processus BPMN deviennent des opérations UML sur l'interface UML respective. Les DataObjects deviennent des noeuds d'activité DataStore. La transformation crée également des classes pour représenter les DataObjects et les placer dans un package discriminants communs à la racine du modèle UML. Ces classes sont utilisées pour représenter les types de noeuds DataStore, ainsi que les types de broches d'entrée et de sortie sur un noeud d'activité UML connecté au noeud DataStore. Pour chaque broche d'entrée et de sortie, un paramètre d'opération est créé sur l'opération UML qui représente la tâche. Le type du paramètre est le même que celui de la broche d'entrée et de sortie respective.
Les collaborations BPMN sont constituées de paires de pools et de participants par processus participant. Un pool représente un processus métier et un participant un rôle que joue le processus métier respectif. Les participants à la collaboration BPMN sont transformés en rôles de collaboration UML. Chaque rôle comporte une interface UML, créée pour représenter son processus métier respectif. Par exemple, si participant1 représente le processus BPMN Process1, le type du rôle de collaboration UML 'participant1' prend la valeur de l'interface IProcess1.
Le connecteur situé entre les rôles de collaboration UML représente un échange de messages entre les processus participants. Cette transformation ne dépasse pas cela pour montrer comment les processus communiquent entre eux, la communication inter-processus étant un comportement de la collaboration. Ce comportement peut donc être décrit de différentes manières adaptées au domaine d'application, par exemple un modèle Activité, un diagramme de séquence, un diagramme de communication ou un diagramme d'état-transition.
La table ci-dessous présente plus de détails sur le mappage métamodèle BPMN :
| Métamodèle BPMN 2.0 | UML 2.0 |
|---|---|
com.ibm.bpmn20.Process |
org.eclipse.uml2.uml.Activity |
com.ibm.bpmn20.Process:: |
|
Types d'éléments de flux : |
|
com.ibm.bpmn20.CallActivity com.ibm.bpmn20.CallActivity |
org.eclipse.uml2.uml.Activity :: org.eclipse.uml2.uml.Activity :: |
com.ibm.bpmn20.Task com.ibm.bpmn20.Task :: com.ibm.bpmn20.Task :: |
org.eclipse.uml2.uml.Activity :: CallOperationAction:outputPin CallOperationAction:inputPin |
com.ibm.bpmn20.DataObject |
org.eclipse.uml2.uml.DataStoreNode org.eclipse.uml2.uml.Class (package de discriminants communs) |
com.ibm.bpmn20.DataAssociation com.ibm.bpmn20.DataAssociation :: com.ibm.bpmn20.DataAssociation :: com.ibm.bpmn20.DataAssociation :: com.ibm.bpmn20.DataAssociation :: |
org.eclipse.uml2.uml.ObjectFlow org.eclipse.uml2.uml.ObjectFlow :: org.eclipse.uml2.uml.ObjectFlow ::
|
com.ibm.bpmn20.StartEvent |
org.eclipse.uml2.uml.InitialNode |
com.ibm.bpmn20.EndEvent |
org.eclipse.uml2.uml.FinalNode |
com.ibm.bpmn20.Event |
org.eclipse.uml2.uml.Event |
com.ibm.bpmn20.IntermediateReceiveEvent com.ibm.bpmn20.IntermediateReceiveEvent::type(com.ibm.bpmn20.TimerEventDefinition) |
org.eclipse.uml2.uml.AcceptEventAction org.eclipse.uml2.uml.AcceptEventAction:: trigger(EList<org.eclipse.uml2.uml.Trigger>) org.eclipse.uml2.uml.AcceptEventAction:: trigger(EList<org.eclipse.uml2.uml.Trigger>) ::event(org.eclipse.uml2.uml.AnyReceiveEvent) |
com.ibm.bpmn20.IntermediateSendEvent com.ibm.bpmn20.IntermediateSendEvent::type(com.ibm.bpmn20.MessageEventDefinition) |
org.eclipse.uml2.uml.SendSignalAction org.eclipse.uml2.uml.SendSignalAction:: signal(org.eclipse.uml2.uml.Signal) org.eclipse.uml2.uml.SendSignalAction::input(EList<org.eclipse.uml2.uml.InputPin>) |
com.ibm.bpmn20.LinkEventDefinition |
org.eclipse.uml2.uml.ObjectFlow |
com.ibm.bpmn20.TimerEventDefinition |
org.eclipse.uml2.uml.TimeEvent |
com.ibm.bpmn20.Gateway |
org.eclipse.uml2.uml.DecisionNode |
com.ibm.bpmn20.ExclusiveGateway |
org.eclipse.uml2.uml.DecisionNode |
com.ibm.bpmn20.InclusiveGateway |
org.eclipse.uml2.uml.DecisionNode |
com.ibm.bpmn20.ParallelGateway |
org.eclipse.uml2.uml.DecisionNode |
com.ibm.bpmn20.SequenceFlow com.ibm.bpmn20.SequenceFlow:: source com.ibm.bpmn20.SequenceFlow:: target |
org.eclipse.uml2.uml.ControlFlow org.eclipse.uml2.uml.ControlFlow::source org.eclipse.uml2.uml.ControlFlow::target |
com.ibm.bpmn20.Collaboration |
org.eclipse.uml2.uml.Collaboration |
com.ibm.bpmn20.Collaboration :: pool(EList< |
org.eclipse.uml2.uml.Activity |
com.ibm.bpmn20.Collaboration :: pool(EList< com.ibm.bpmn20.Collaboration :: |
org.eclipse.uml2.uml.Interface org.eclipse.uml2.uml.Interface::operation(EList<org.eclipse.uml2.uml.Operation>) |
com.ibm.bpmn20.Collaboration :: |
org.eclipse.uml2.uml.Collaboration::collaborationRole(EList<org.eclipse.uml2.uml.ConnectableElement>) |
Couloir de notation |
Partition d'activité |