-
R1000 : Un Model Element ne peut pas s’abstraire lui-même.
-
R1010 : Les Partitions racines d’une Activity ne doivent pas avoir de Super-Partition.
-
R1020 : La source et la cible d’un Flow doivent être contenues dans le même Structured Activity Node.
-
R1030 : La source et la cible d’un Flow doivent appartenir à la même Activity.
-
R1040 : Un Activity Parameter Node doit être représenté par un Behavior Parameter appartenant à la même Activity.
-
R1050 : Un Activity Parameter Node doit avoir soit des flux entrants, soit des flux sortants.
-
R1060 : Un Activity Parameter Node sans flux entrant et ayant un ou plusieurs flux sortants doit avoir un Behavior Parameter avec passage de paramètres "Entrée" ou "Entrée/Sortie".
-
R1070 : Un Activity Parameter Node sans flux sortant et ayant un ou plusieurs flux entrants doit avoir un Behavior Parameter avec passage de paramètres "Sortie" ou "Entrée/Sortie".
-
R1080 : Les Partitions de même niveau doivent représenter des Parts appartenant au même Classifier.
-
R1090 : Si une Sub-Partition est non-externe et représente un Classifier alors le Classifier représenté doit être imbriqué dans le Classifier représenté par sa Super-Partition ou être l’extrémité d’une composition avec celui-ci.
-
R1100 : Si une Sub-Partition représente une Part imbriqué dans un Classifier alors sa Super-Partition doit représenter le Classifier ou une instance de celui-ci.
-
R1110 : Les Pins d’un Call Behavior Action doivent correspondre un pour un à des paramètres "in", "out", "inout" ou "return" du Behaviour appelé.
-
R1130 : Le type et la cardinalité maximum du Pin d’un Call Action doivent correspondre au type et à la cardinalité maximum du paramètre représenté.
-
R1140 : Les Pins d’un Call Operation Action doivent correspondre un pour un à des paramètres "in", "inout", "out" ou "return" de l''opération appelée.
-
R1150 : Le Call Operation Action ou le Send Signal Action ne doit pas avoir plus d’un Pin cible.
-
R1160 : Un Pin cible ne peut être contenu que par un Call Operation Action ou un Send Signal Action.
-
R1170 : Le type du Pin cible doit être le propiétaire de l''operation.
-
R1180 : Les Control Flows ne doivent pas avoir d’Object Node à leurs extrémités, sauf dans le cas des Object Nodes de type control.
-
R1190 : Le Decision-Merge Node est à la fois utilisé en tant que noeud de Decision et en tant que noeud de Merge.
-
R1200 : Les flux entrants et sortants d’un Decision-Merge Node doivent être tous des Object Flows ou tous des Control Flows.
-
R1230 : Seuls les Control Flows peuvent avoir des Initial Nodes comme source.
-
R1250 : Si un Fork/Join Node a un Object Flow dans ses flux d’entrée, il doit avoir un Object Flow dans ses flux de sortie et vice versa. (Même chose pour les Control Flows)
-
R1280 : Les Object Flows ne peuvent pas connecter des Actions.
-
R1290 : Les Object Nodes connectés par un Object Flow, avec des Control Nodes intervenants facultatifs, doivent avoir des types compatibles. En particulier, le type de l’Object Node en aval doit être le même ou un super-type du type de l’Object Node en amont.
-
R1300 : Les Object Nodes connectés par un Object Flow, avec des Control Nodes intervenants facultatifs, doivent avoir les mêmes limites supérieures.
-
R1310 : Un flux à poids constant ne peut pas cibler un Object Node ni mener à un Object Node en aval sans action d’intervention et ayant une limite supérieure inférieure au poids.
-
R1320 : Un Object Flow ne doit pas être à la fois multi-cast et multi-receive.
-
R1350 : Si un Object Node a un 'Filtre de séléction' alors l’Object Node doit être ordonné et vice versa.
-
R1360 : Les Input Pins ne peuvent avoir des flux sortants que si les deux conditions suivantes sont remplies : (1) Ils se trouvent sur des Actions qui sont des Structured Nodes, et (2) Ces flux doivent cibler un noeud contenu par le Structured Node.
-
R1370 : Les Output Pins ne peuvent avoir des flux entrants que si les deux conditions suivants sont remplies : (1) Ils se trouvent sur des Actions qui sont des Structured Nodes, et (2) Ces flux doivent partir d’un noeud contenu par le Structured Node.
-
R1380 : Les Pins d’un Send Signal Action doivent correspondre un pour un à des Attributs du Signal envoyé.
-
R1390 : La cardinalité maximum d’un Pin d’argument doit être la même que pour l’Attribut représenté.
-
R1400 : Un Activity Parameter Node doit appartenir à une Activity.
-
R1410 : Sur une Association, seule une des extrémités peut ête de type agregation ou composition.
-
R1420 : Un Acteur ou un UseCase ne peut pas avoir d’associations n-aire.
-
R1430 : Les multiplicités doivent être cohérentes: La multiplicité min ne peut être * et doit être inférieur à la multiplicité max.
-
R1450 : Si une association est une composition, alors la multiplicité max de l’autre extrémité doit être 1.
-
R1460 : Une association publique venant d’un Classifier publique ne peut pas cibler un Classifier privé ou protégé.
-
R1470 : Le nom des qualifieurs d’une association doivent être uniques.
-
R1480 : Un Attribut doit être typé par un type primitif.
-
R1490 : Dans une instance, le type d’un attribute instancié doit être dans la class instantiée ou dans ses classes parentes.
-
R1500 : Dans une instance, le nom d’un attribut instancié doit être le même que l’attribut correspondant.
-
R1520 : Le nom d’une BindableInstance doit être unique dans son Classifier.
-
R1530 : Une association ou un port devrait avoir un nom.
-
R1540 : Une Bindable Instance ne peut se reprèsenter elle même, directement ou indirectement.
-
R1550 : Si une Bindable Instance a un type et représente une Feature, alors le type de l’instance doit être compatible avec cette Feature.
-
R1560 : Les sous classes d’une classe active doivent être actives.
-
R1580 : Les Attributs, les Associations et les Operations ne peuvent pas être à la fois abstraits et de classe.
-
R1590 : Les General Class primitives ne peuvent pas avoir d’associations.
-
R1600 : Une classe primitive ne peut avoir de collaboration.
-
R1610 : Une classe primitive ne peux pas avoir de machine à états.
-
R1620 : Un Classifier non abtsrait ne peut pas avoir de méthodes abstraites.
-
R1640 : Il ne peut y avoir plus d’un ElementImport entre deux NameSpace ou entre une Operation et un NameSPace.
-
R1650 : Une énumération ne peut pas être abstraite.
-
R1660 : Une énumération est toujours primitive.
-
R1670 : Les Enumeration Litteral d’une énumération doivent avoir un nom unique.
-
R1680 : Le champ 'Called operation' doit être défini pour un Event de type Call, tandis que le champ 'Instanciated signal' doit être vide.
-
R1690 : Le champ 'Expression' d’un Event de type Change doit être défini, tandis que les champs 'Called operation' et 'Instanciated signal' doivent être vides.
-
R1700 : Le champ 'Instantiated signal' d’un Event de type Signal doit être défini, tandis que les champs 'Called operation' et 'Expression' doivent être vides.
-
R1710 : Le champ 'Expression' d’un Event de type Time doit être défini, tandis que les champs 'Called operation' et 'Instanciated signal' doivent être vides.
-
R1720 : Un Namespace abstrait devrait seulement hériter d’un autre Namespace abstrait.
-
R1730 : Une généralisation doit être créée entre deux éléments de modèles du même type, sauf dans le cas d’un signal, qui peut spécialiser soit un signal soit une classe.
-
R1740 : Un Information Flow doit convoyer de l’information.
-
R1750 : Les répétitions de noms sont interdites pour les Atrribute Links.
-
R1760 : Il ne peut y avoir d’incohérénce dans les multiplictés d’une instance.
-
R1780 : Le nom d’une instance doit être unique dans son Namespace.
-
R1790 : Une instance doit avoir un nom ou l’association d’instanciation doit être définie.
-
R1800 : Si l’Operator est opt, loop, break, ou neg, il ne peut y avoir plus d’une Operand.
-
R1810 : Une Gate (réelle) sur un InteractionUse doit référencer une Gate (formelle) de l’interaction référencée.
-
R1820 : Une Gate ne peut pas couvrir une lifeline.
-
R1830 : Une PartDecompoistion ne peut pas recevoir de messages de type 'create' ou 'destroy'.
-
R1860 : Sur une Interface, la visibilité des Features doit être publique.
-
R1870 : Une Interface ne peut pas être implémentée deux fois par la même classe ou le même composant.
-
R1910 : Un lien qui instancie une association doit être cohérent avec cette association.
-
R1950 : Les messages de type 'reply' ne peuvent pas invoquer une opération.
-
R1960 : Un Message doit porter le même nom que l’opération qu’il invoque.
-
R1970 : Un TemplateParameterSubsitution doit référencer un TemplateParameter.
-
R1980 : Les noms des attributs et des extrémité d’association d’un Classifier doivent être uniques.
-
R1990 : Les noms des attributs et des rôles hérités par un Classifier doivent être uniques.
-
R2010 : Dans un Dictionaire, le nom de chaque élément doit être unique.
-
R2030 : Dans un PropertyContainer, le nom de chaque EnumeratedPropertyType doit être unique.
-
R2050 : Certains éléments doivent avoir un nom.
-
R2060 : Le nom d’un Namespace doit être unique dans son Namespace.
-
R2080 : Dans un PropertySet, le nom de chaque Property doit être unique.
-
R2100 : Dans un EnumeratedPropertyType, le nom de chaque PropertyEnumerationLiteral doit être unique.
-
R2120 : Dans un PropertyContainer, le nom de chaque PropertySet doit être unique.
-
R2140 : Dans un PropertyContainer, le nom de chaque PropertyType doit être unique.
-
R2160 : Dans un Conteneur Analyste, le nom de chaque élément doit être unique.
-
R2170 : Le nom d’un comportement doit être unique dans son NameSpace.
-
R2180 : Il ne peut y avoir de cycles dans le graphe d’héritage d’un Namespace.
-
R2190 : Il ne peut y avoir qu’une généralisation entre deux Namespaces.
-
R2200 : Un NameSPace ne peut pas dériver et importer un autre Namespace.
-
R2210 : Un Namespace feuille ne peut pas être dérivé.
-
R2220 : Un Namespace feuille ne peut pas être abstrait
-
R2230 : Un Namespace racine ne peut pas hériter d’un autre Namespace.
-
R2240 : Il ne peut y avoir de cycle de dépendance inter-package/inter-component.
-
R2250 : Toutes les opérations d’un Classifier doivent avoir des signatures diffèrentes des opérations publiques et protègèes hèritèes. Sauf en ce qui concerne les constructeurs, les destructeurs, et les opérations dèrivèes.
-
R2260 : Chaque opération d’un Classifier doivent avoir une signature différente.
-
R2270 : Toutes les collaborations d’une opération doivent avoir des noms différents.
-
R2330 : Tous les paramètres d’une opération doivent avoir des noms différents.
-
R2340 : Un opération redéfinie doit appartenir a un parent on a une interface implémentée par le parent de l’opération.
-
R2350 : Une Opération privée ne peut être redéfinie.
-
R2360 : La visibilité d’une opération ne peut être plus grande que la visbilité de l’opération qu’elle redéfinie.
-
R2370 : Une opération de classe (statique) ne peut être redéfinie.
-
R2380 : Une opération abstraite ne peut redéfinir une opération concrete.
-
R2390 : Un constructeur ne peut pas avoir de paramètre de retour.
-
R2400 : Un destructeur ne peux pas avoir de paramètre.
-
R2410 : Une opération ne peut pas avoir les deux stéréotypes 'create' et 'destroy' à la fois.
-
R2420 : Une opération doit avoir la même signature que l’opération qu’elle redéfinie.
-
R2430 : Toutes les machines à états d’une opération doivent avoir des noms différents.
-
R2440 : Une opération ne peut pas appartenir a une énumération
-
R2450 : Un Package ne peut pas avoir de liens d’héritage.
-
R2470 : Un NameSpace ne peut avoir plus d’un lien PackageImport vers un package.
-
R2500 : Un paramètre 'out' ne peut pas avoir de valeur par défaut.
-
R2510 : Il ne peut y avoir de lien direct entre deux ports.
-
R2520 : Si un Port a une delegation vers une part, il doit fournir au moins une interface.
-
R2530 : Si un port reçoit une delegation d’une part, il doit fournir au moins une interface.
-
R2540 : Les Interfaces fournies par un port doivent être implèmentèes par la classe qui type ce port.
-
R2550 : Si un Port est un Behavior Port, les Interfaces qu’il fourni doivent être implèmentèes par la classe auquel il appartient.
-
R2560 : Un Behaviour Port doit fournir au moins une Interface.
-
R2570 : Le type d’un Behavior Port doit être soit la classe auquel il appartient soit non dèfini.
-
R2580 : Une région ne peut pas contenir plus d’un état de type deep history.
-
R2590 : Une région ne peut pas contenir plus d’un état initial.
-
R2600 : Une machine à états ou un état ne peut pas contenir deux états ayant le même nom.
-
R2610 : Seul les états représentant une sous machine peuvent avoir des états de type connection point reference.
-
R2620 : Les états représentant une sous machine ne peuvent avoir d’états de type entry ou exit point définis.
-
R2630 : Une région ne peut pas contenir plus d’un état de type shallow history.
-
R2640 : Le contexte d’une machine à états ne peut pas être une Interface.
-
R2650 : Le contexte d’une machine à états protocolaire doit être un Classifier.
-
R2660 : Un état d’une machine à états protocolaire ne doit pas avoir de 'entry', 'exit', ou 'do' actions d’activité.
-
R2670 : Une machine à états protocolaire ne peut pas avoir d’états historiques.
-
R2680 : Le nombre de paramètres d’une TaggedValue doit être égal au nombr de paramètres définis dans la déclaration de la TaggedValue.
-
R2690 : Un élément ne peut avoir un TemplateBindind vers lui même.
-
R2700 : Un TemplateBinding ne peut substituer un TemplateParameter de l’élément instancié qu’une seule fois.
-
R2720 : Un TemplateBinding doit être entre deux éléments de même type ou entre une Class et un DataType.
-
R2730 : Un TemplateBinding doit substituer tous les TemplateParameters de l’élément instantié, et les TemplateParameterSubstitution doivent être définis dans le même ordre que les TemplateParameters.
-
R2740 : Dans un TemplateBinding, les TemplateParameterSubstitution doivent appartenir à l’élement instancié;
-
R2750 : Une transition ayant pour origine un état de fork ou join ne doit pas avoir de guard ou de trigger.
-
R2760 : Une transition partant d’un fork doit toujours ciblé un état.
-
R2770 : Une transition ciblant un join doit toujour partir d’un état.
-
R2780 : Les transitions ciblant des pseudo états ne peuvent pas avoir de trigger (à l’exception de ceux venant du pseudostate initial).
-
R2790 : Une transiton d’une région à une autre dans le mêmé état n’est pas autorisée.
-
R2800 : Un état initial ne peut pas avoir plus d’une transition sortante.
-
R2810 : Les états historiques ne peuvent pas avoir plus d’une transition sortante.
-
R2820 : La cible d’une transition ne peut pas êtres un état initial.
-
R2830 : La source d’une transition ne peut pas être un état final.
-
R2840 : Une transition ne devrait avoir qu’un des éléments suivants definis: Processed, Effects, or BehaviorEffet.
-
R2850 : Un élément ne peut avoir une dépendence de type usage vers lui-même.
-
R2860 : Il ne peut y avoir qu’une seule relation d’extension/inclusion entre deux Use Cases.
-
R2870 : Il ne peut y avoir de cycle de relation d’extension entre Use Cases.
-
R2880 : Il ne peut y avoir de cycle de relation d’inclusion entre Use Cases.
-
R2890 : Un lien de communication ne peut avoir le même élément pour source et pour cible.
-
R2900 : Une relation d’extension doit référencer au moins un Extension Point.
-
R2910 : Une relation d’extension ne peut référencer que des Extension Points appartenant au Use Case cible.
-
R2920 : Un Extension Point ne peut être référencé que par une relation d’extension.
-
R2930 : Un Message ou CommunicationMessage ne peut pas avoir un Signal et une Opération défini en même temps.
-
R2940 : Toutes les transitions arrivant sur un join doivent venir d’état de différentes régions au sein d’un même état.
-
R2950 : Toutes les transitions sortant d’un fork doivent cibler difrérentes régions au sein d’un même état.
-
R2960 : Les dépendances de type 'synonyme', 'antonyme', 'contexte', et 'type de', doivent relier deux termes.
-
R2970 : Une dépendance de type 'assignation' doit venir d’un acteur,d’une interface, d’un paquet, ou d’un processus, et cibler un objectif.
-
R2980 : Une dépendance de type 'mesure' doit partir d’un élément de modèle et ciblé un objectif.
-
R2990 : Une dépendance de type 'garantie' doit partir d’une exigence et cibler un objectif.
-
R3000 : Une dépendance de type 'influence' doit relier deux objectifs.
-
R3010 : Une dépendance de type 'reference' doit partir d’une règle métier et cibler un terme.
-
R3020 : Une dépendance de type 'relation' doit relier deux règles métier ou deux termes.
-
R3030 : Une dépendance de type 'rafine' doit soit: 1) partir d’un élément de model et cibler une exigence 2) partir d’une règle d’exigence, d’une activité ou d’une opération et cibler un règle métier.
-
R3040 : Une dépendance de type 'implémente' doit partir d’un processus ou d’une classe et cibler une règle métier.
-
R3050 : Une dépendance de type 'partie' doit relier deux exigences ou deux objectifs.
-
R3060 : Une dépendance de type 'satisfait' ou 'vérifie' doit partir d’une élément de modèle et cibler une exigence.
-
R3070 : Une dépendance de type 'derive' doit partir d’un cas d’utilisation ou d’une exigence et cibler une exigence.
-
R3080 : Tout les FlowNodes doivent faire partie d’une séquence commençant par un StartEvent et finissant par un EndEvent.
-
R3090 : Un SequenceFlow ne peut avoir sa source et sa destination dans des Process différents.
-
R3100 : Un SequenceFlow dans un SubProcess doit avoir sa source et sa destination dans ce SubProcess.
-
R3110 : Un SequenceFlow ne peut pas cibler un StartEvent ou venir d’un EndEvent.
-
R3120 : Un LinkThrowEvent doit toujours être relié à un LinkCatchEvent.
-
R3130 : Un MessageFlow ne peut cibler un EndEvent ou un IntermediateThrowEvent, ni venir d’un StartEvent ou d’un IntermediateCatchEvent.
-
R3140 : Un SequenceFlow sortant doit avoir une garde nulle.
-
R3150 : Un MessageFlow ne peut lier deux éléments d’un même Process.
-
R3160 : Un MessageFlow ne peut avoir une Gateway comme source ou comme cible.
-
R3180 : Un FlowElement (et respectivement un BaseElement) ne peut avoir un SequenceFlow (respectivement un MessageFlow) vers lui-même.
-
R3190 : Un DataAssociation ne peut avoir un DataOutput comme source et ne peut cibler un DataInput.
-
R3200 : Un LinkThrowEvent doit avoir le même nom que le LinkCatchEvent auquel il est relié.
-
R3220 : Un SequenceFlow sortant d’un EventBasedGateway doit cibler un IntermediaryCatchEvent.
-
R3230 : Tous les SequenceFlows sortant d’une ExclusiveGateway doivent avoir une garde sauf pour celui par defaut.
-
R3250 : Les Process et SubProcess doivent avoir au moins un StartEvent et un EndEvent.
-
R3260 : Le modèle ne doit pas réferencer d’éléments manquants.
-
R3270 : Le State d’un BpmnItemAwareElement doit appartenir à la GeneralClass qu’il représente.
-
R3300 : Les éléments Analyste ne peuvent pas avoir un nom vide.
-
R3310 : Les dépendances doivent être créées dans le sens recommandé.
-
R3320 : Un MessageFlow doit partir d’un SendTask/ThrowEvent/Participant et arriver sur un ReceiveTask/CatchEvent/Participant.
-
R4000 : Les relations doivent respecter la norme ArchiMate.
-
R4010 : Les relations entrantes et/ou sortantes d’une Jonction doivent être de même type.