0% ont trouvé ce document utile (0 vote)

12 vues474 pages

Guide MBSE avec SysML pour l'ingénierie

Le guide de MBSE avec SysML présente l'approche de Modélisation Basée sur les Systèmes pour la gestion des systèmes complexes, remplaçant les méthodes traditionnelles centrées sur les documents. Il met en avant les fonctionnalités d'Enterprise Architect pour faciliter la collaboration entre divers acteurs du projet, tout en intégrant des outils de simulation et de modélisation. Ce document sert de ressource pour les ingénieurs et les équipes souhaitant optimiser leurs pratiques d'ingénierie à travers des modèles robustes et bien structurés.

Transféré par

Loundou ortega

Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.

Formats disponibles

Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

0% ont trouvé ce document utile (0 vote)

12 vues474 pages

Guide MBSE avec SysML pour l'ingénierie

Transféré par

Loundou ortega

Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.

Formats disponibles

Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

ENTERPRISE ARCHITECT

Série de Guides d'Utilisateur

Guide de MBSE avec SysML

Author: Sparx Systems

Date: 23/11/2023
Version: 16.1

CRÉÉ AVEC
Table des Matières

Guide de MBSE avec SysML 7

Modélisation Paramétriques Equations 9
Présentation Diagrammes Paramétriques 10
Systèmes d'équations utilisant des associations de parties 13
Mesures d'efficacité à l'aide de paramètres 15
Utilisation Propriétés et des pièces pour l'utilisation Modèle Bloc 17
Présentation des Diagrammes Fonctionnels Internes 18
Modélisation et pièces de liaison 20
Collaborer en tant qu'équipe d'ingénierie 23
Référentiel Central Partagé 24
Cloud computing 25
Discussions et chat 27
Ressources Kanban et calendriers 28
Révision de Modèles 29
Partager des ressources dans la Bibliothèque d'Équipe 32
Affichage des modèles sur les appareils mobiles 33
Modélisation de l' Avenir 34
Contrôle de Version et Lignes de base 38
Serveur d'actifs réutilisable 40
Coordonner le comportement avec les activités 43
Actions, les éléments de base Comportementale 45
Présentation Diagrammes d'activités 48
Création de hiérarchies d'activités 51
Spécification d' Séquence Action avec des flux de contrôle 52
Spécification du flux Item avec des flux Object 54
Modélisation Entrées et Sorties avec Paramètres et Pins 56
Visualiser les activités avec des simulations 59
Allocations et autres Relations 61
Interactions comme Séquence de messages 63
Lignes de vie, messages et activations 64
Présentation du Diagramme de Séquence 69
Orchestration de messages avec des fragments 73
Modélisation Changement avec Statemachines 75
States et comportements 78
Présentation Diagrammes Statemachine 79
Déclencheurs et Transitions 82
States et régions composites 86
Pseudo-états - La police de la circulation 89
Tableaux State - Une autre Vue 94
Visualisation et mise en œuvre avec des simulations 97
Visualiser avec des simulations 99
Simulation SysML dans Modelica et Simulink 100
Comment fonctionne Simulation SysML 102
Démarrage avec OpenModelica 104
Création de modèles pour Simulation 109
Décrire les objectifs des utilisateurs avec des cas d'utilisation 116
Exigences et cas d'utilisation 117
Présentation Diagrammes de cas d'utilisation 120
Rencontrez le créateur de scénarios 124
Structurer un Modèle de cas d'utilisation 126
Générer Diagrammes de comportement 127
Rapport de cas d'utilisation 128
Utiliser des blocs pour Modèle une structure et des contraintes 130
Démarrage avec blocs 135
Modélisation des contraintes sous forme de blocs 138
Présentation Diagrammes de définition Bloc 139
Les éléments structurels fondamentaux 145
Modélisation Fonctionnalités Structurelles 146
Modélisation Comportementale Fonctionnalités 152
Autres Relations Bloc 158
Points d'interaction Modélisation 163
Modélisation Quantité à l'aide de types valeur 167
Utiliser Paquetages pour Structurer le Référentiel 169
The Function of Packages 171
Présentation Diagrammes Paquetage 172
Régimes d'organisation Paquetage 177
La fenêtre du Navigateur 180
Accéder au Référentiel à l'aide Modèle Vues 183
Définition et gestion des besoins 184
Exigences en tant que citoyens de première classe 189
Présentation Diagrammes d'exigences 193
Exigences en développement 197
Élicitation 199
Sources des documents 200
Observations des utilisateurs 201
Séminaires des parties prenantes 202
Créer Exigences 205
Exigences externes et internes 206
Catégories d'exigences 207
Propriétés des exigences 209
Spécification 211
Rencontrez le Gestionnaire de Spécification 212
Analyse 215
Prioriser les Exigences 216
Validation 220
Visualiser Exigences 222
Diagrammes Exigences 223
Gestionnaire de Spécification 224
Navigateurs et Vues 225
Matrice de relation 227
Exigences Tableaux 228
Gérer Exigences 229
Traçage des Exigences 230
Exigences de suivi 233
Gérer Exigences changeantes 235
Analyse d'impact des changements 238
Volatilité des exigences 240
Réutilisation des exigences 242
Relations avec les exigences 244
Ajout de raffinement à une exigence 247
Relation de confinement 248
Copier Exigences existantes 250
Dériver une exigence d’une autre 251
S'assurer qu'une exigence est satisfaite 252
Traçabilité aux éléments Modèle 254
Vérifier la relation 255
Visualisation Relations d'exigence 257
Documenter Exigences 263
Glossaire du Projet 264
Spécification logicielle requise 265
Rencontrez les outils Ingénierie des Systèmes 266
Générateur de scénarios 267
Chaîne de valeur 269
Fenêtre de traçabilité 271
Modélisation Consciente du Temps 273
Bibliothèque 276
Carte de Stratégie 278
Gestionnaire de Spécification 280
Feuille de Route Diagramme 282
Diagramme Exigences 284
Matrice de relation 287
Motifs 289
Diagramme Paramétriques 291
Feuilles de calcul d'importation et d'exportation 292
Carte de Chaleur 294
Matrice d'Analyse des Écarts 295
Documentation 297
Diagramme Statemachine 299
Diagramme d'arbre Décision 301
Diagrammes de tableau de bord 303
Interrompre lorsqu'une Variable Change de Valeur 305
Calendrier 306
Diagramme Interne de Bloc 308
Diagramme de cas d'utilisation 310
Audit 313
Diagramme d'activité 315
Une équation à quatre variables 317
La méthode ou le processus d'ingénierie 318
Modélisation comme discipline 321
Démarrage 323
Définir le but d'un Modèle 325
Décider où Démarrer 327
Pièces de connexion du Modèle 328
Assurer la qualité d'un Modèle 329
Le Systems Modeling Language (SysML) 330
Enterprise Architect l'outil Modélisation 331
Plateforme collaborative 334
Gestion de Projet Établi 335
Modèle Référentiel 336
Où nous allons 337
Démarrage 342
Mise en place d'une structure Modèle 344
Adaptation de l'application 345
Définir une perspective 346
Sélection d'un style visuel 348
Sélection d'un espace de travail 349
Définition des préférences 350
Importation de matériel existant 351
Création d'éléments et Relations Diagrammes 355
Visualiser les modèles 360
Synchronisation avec des données externes 362
Exemple Modèle SysML 363
Présentation Paquetage (Structure de l'exemple Modèle ) 364
Diagramme Paquetage - Application du profil SysML 365
Diagramme Paquetage - Affichage de la structure Paquetage du Modèle 366
Définir le contexte (limites et cas d'utilisation) 369
Modèle de domaine opérationnel - Définition du contexte 370
Diagramme de cas d'utilisation – Cas d'utilisation de niveau supérieur 372
Diagramme de cas d'utilisation - Cas d'utilisation opérationnels 374
Élaboration du comportement ( Diagrammes Séquence et Statemachine ) 376
Diagramme de Séquence - Drive Black Box 377
Diagramme Statemachine - States opérationnels HSUV 381
Diagramme de Séquence - Démarrer le véhicule Black Box et White Box 383
Etablir Exigences ( Diagrammes et Tableaux Exigences ) 385
Diagramme des exigences - Hiérarchie des exigences HSUV 386
Diagramme d'exigences - Exigences dérivées 387
Diagramme d'exigence - Relations d'exigence d'accélération 388
Tableau - Exigences Tableau 389
Décomposer les morceaux ( Diagrammes de définition Bloc , Diagrammes Bloc internes) 390
Interrompre lorsqu'une Variable Change de Valeur - Domaine Automobile 391
Interrompre lorsqu'une Variable Change de Valeur - Hybrid SUV 392
Diagramme Interne de Bloc - SUV Hybride 393
Interrompre lorsqu'une Variable Change de Valeur - Power Subsystem 394
Diagramme Interne de Bloc pour le sous-système de puissance 395
Définir les ports et les flux 397
Interrompre lorsqu'une Variable Change de Valeur - ICE Flow Propriétés 398
Diagramme Interne de Bloc - CAN Bus 399
Interrompre lorsqu'une Variable Change de Valeur - Fuel Flow Propriétés 400
Diagramme Paramétriques - Débit De Carburant 402
Analyser les performances ( Diagrammes de contraintes, Diagrammes , Vues ) 403
Interrompre lorsqu'une Variable Change de Valeur - Contexte d'analyse 404
Diagramme Paquetage - Définition Vue de performance 405
Diagramme Paquetage - Définition du point de vue 406
Diagramme Paquetage - Définition Vue 407
Diagramme Paquetage - Hiérarchie Vue 408
Diagramme Paramétriques - Mesures d'Efficacité 409
Diagramme Paramétriques - Economie 410
Diagramme Paramétriques - Dynamique 411
Diagramme de synchronisation (non normatif) - Accélération de 100 ch 412
Définir, décomposer et répartir les activités 413
Diagramme d'activité - Accélération (niveau supérieur) 414
Interrompre lorsqu'une Variable Change de Valeur - Accélération 415
Diagramme d'Activité (EFFBD) - Accélération (détail) 416
Diagramme Interne de Bloc - Power Subsystem Comportementale and Flow Allocation 417
Diagramme Interne de Bloc : Property Specific Values - EPA Fuel Economy Test 418
Apprendre à connaître les Diagrammes SysML 419
Aspects communs des Diagrammes 427
Interrompre lorsqu'une Variable Change de Valeur 437
Diagramme des exigences 440
Diagramme de cas d'utilisation 443
Diagramme Paquetage 445
Diagrammes d'activités 447
Diagramme Interne de Bloc 449
Diagramme Paramétriques 451
Diagramme de Séquence 453
Diagramme Statemachine 456
Présentation Langage Modélisation des Systèmes 458
Architecture du langage 460
Concepts grammaticaux clés 467
Modèles, Diagrammes , éléments et Vues 469
Guide de MBSE avec SysML 2023-11-23

Guide de MBSE avec SysML

Ingénierie Systèmes Modèles Basée (MBSE) s'est imposée comme une approche précieuse pour la gestion et l'ingénierie
de systèmes complexes. Il s'agit d'un abandon de l'approche centrée sur le document et permet de développer et d'utiliser
des modèles à des fins très diverses, notamment la spécification des exigences, la conception, les compromis,
l'architecture, la vérification, la validation, les simulations et support , et bien plus encore.
Les modèles agissent comme une « police d'assurance » contre les erreurs d'ingénierie catastrophiques et contribuent à
réduire le coût élevé des défaillances lors des phases de spécification, de conception, de test, de mise en œuvre et support
.

Lorsque vous utilisez Enterprise Architect pour MBSE, vous ouvrez la porte à une toute nouvelle façon de penser et de
travailler. Enterprise Architect est une plateforme de collaboration rigoureuse qui permet de partager des idées, des
problèmes, des solutions et des implémentations par un large éventail de parties prenantes, notamment :
· Clients
· Cadres
· Responsables de l'ingénierie
· Chefs d’équipe d’ingénierie
· Architectes et designers
· Ingénieurs systèmes
· Ingénieurs logiciels
· Testeurs
· Fournisseurs
· Intégrateurs de systèmes
· Le personnel Support
· Utilisateurs ou leurs substituts
Les modèles sont également disponibles en temps réel pour consultation, contributions, révisions et discussions via une
interface Navigateur sécurisée, utilisant la puissance de la collaboration pour créer des architectures et des conceptions
robustes et bien formées.

Dans ce guide, nous explorerons de nombreuses fonctionnalités d' Enterprise Architect qui peuvent être exploitées pour
amener un ingénieur individuel, une équipe, une organisation ou un segment industriel entier au niveau de pratique et de
performance requis à une époque dominée par l'innovation et changement technique sans précédent. Le guide fournira le
contexte du Langage Modélisation des Systèmes et montrera comment les constructions de langage peuvent être créées
dans Enterprise Architect . Il est destiné à donner à un nouveau venu à la fois le langage et l'outil une exposition à tout ce
qui est possible dans le domaine de Ingénierie des Systèmes en utilisant cette plateforme d'ingénierie et de collaboration.
Selon les mots du célèbre physicien du XVIIe siècle, Sir Isaac Newton :
« Si j'ai vu plus loin que d'autres, c'est parce que je me suis tenu sur les épaules de géants.
Enterprise Architect fournit une plate-forme où cette vision peut se concrétiser, où, grâce aux fonctionnalités et facilités
de collaboration telles que les simulations et l'automatisation, un ingénieur peut voir les opportunités, concevoir des
solutions et concevoir l'avenir.
Enterprise Architect comprend fonctionnalités majeures pour les ingénieurs système, les architectes techniques et autres
personnes souhaitant coupler leur travail modélisation et de simulation dans Enterprise Architect avec MATLAB,
Octave, OpenModelica et plus encore. Les classes « Solveur » et une vaste Bibliothèque mathématique dans le moteur
JavaScript offrent une capacité Simulation considérablement étendue. Pour plus d'informations, consultez la rubrique
d'aide Mathematical Simulations .

Modélisation Paramétriques Equations

Les ingénieurs sont chargés de trouver des solutions aux problèmes et aux opportunités, et utilisent des modèles pour
visualiser les simplifications du système considéré et le contexte mondial dans lequel le système devra fonctionner. Les
modèles d'ingénierie système créés dans Enterprise Architect constituent un outil précieux. pour l'analyse, la conception,
l'architecture, les tests et la visualisation. Cela implique d'être capable de prédire comment un système se comportera
dans un contexte donné, d'équilibrer les exigences concurrentes et les considérations de conception sous la forme de
négociations avec les parties prenantes et d'analyses de compromis. diagrammes Paramétriques sont un outil avancé qui
peut aider l'ingénieur à répondre à ces problèmes dans un modèle et à représenter de manière préventive le comportement
probable d'un système.
Dans une rubrique précédente, nous avons appris comment modéliser des équations à l'aide du diagramme de définition
Bloc , la relation d'association de parties articulant les variables (paramètres) de l'équation. Cela fournit un mécanisme
essentiel de réutilisation. Pour vous rappeler comment nous utilisons un Bloc de contraintes pour modéliser des
équations, référez-vous à ce diagramme , qui utilise une contrainte (qui est un Bloc stéréotypé) pour modéliser le
carburant d'un véhicule. Le débit de carburant est basé sur une équation qui a la pression de carburant (presse) et la
demande de carburant comme variables (paramètres).

N'importe quelle équation ou système d'équations peut être modélisé à l'aide de la contrainte.
Cette contrainte peut potentiellement être réutilisée dans de nombreux contextes différents. C'est sur le diagramme
Paramétriques que l'on voit comment il est utilisé. Pour plus d'informations, consultez la rubrique d'aide Parametric
Diagrams .

Présentation Diagrammes Paramétriques

Un diagramme Paramétriques permet de visualiser les équations et leurs paramètres dans un contexte particulier sous
forme de propriétés de contraintes. Chacune de ces propriétés représente une utilisation d'un ConstraintBlock qui a
généralement été défini sur un diagramme de définition Bloc .
Le cadre d'un diagramme Paramétriques représente le ConstraintBlock propriétaire, il sera donc nommé comme tel et les
éléments qui apparaissent sur le diagramme seront des propriétés de contrainte, qui sont des instances des
ConstraintBlocks dont le Bloc propriétaire est composé, montrant ainsi la composition de la contrainte.

Création Diagrammes Paramétriques

Un diagramme Paramétriques peut être créé à partir de plusieurs endroits dans l' Interface Utilisateur , en utilisant l'une
de ces options :
· Ruban de conception - Icône Ajouter Diagramme dans le panneau Diagramme
· Barre d'outils de la fenêtre Navigateur - Icône Nouveau Diagramme
· Menu contextuel de la fenêtre Navigateur - Ajouter Diagramme
Nous utiliserons l'option du ruban 'Conception' pour créer un diagramme Paramétriques . Tout d'abord, vous sélectionnez
le Paquetage dans la fenêtre Navigateur où vous souhaitez placer le diagramme .
Contrairement à la plupart des autres diagrammes SysML, le diagramme Paramétriques est généralement inséré sous son
Bloc de contraintes propriétaire. Une fois l'emplacement sélectionné dans la fenêtre Navigateur , sélectionnez :
Conception > Diagramme > Ajouter Diagramme

La sélection de cette option ouvre la dialogue « Nouveau Diagramme », vous permettant de nommer le diagramme ; le
nom sera initialement par défaut le nom du Bloc de contraintes propriétaire du diagramme . Une fois la Perspective
SysML choisie et la version de SysML sélectionnée, une liste de diagrammes s'affichera vous permettant de sélectionner
le diagramme Paramétriques . Cliquez sur le bouton OK pour créer un nouveau diagramme Paramétriques à
l'emplacement sélectionné dans la fenêtre Navigateur . Le Diagramme Vue s'ouvrira, vous permettant de commencer à
ajouter des éléments et des connecteurs qui décrivent les équations et les paramètres. Enterprise Architect affichera
également les pages ' Paramétriques ' de la Diagramme Toolbox, qui contiennent les éléments et relations définis par la
spécification SysML pour être applicables à la construction de ce type diagramme . N'importe quel nombre d'autres pages
de la boîte à outils peuvent être ouvertes si nécessaire, en plus des pages « Éléments communs » et « Relations
communes » qui sont affichées par défaut et qui permettent d'ajouter notes diagramme , des légendes et d'autres éléments
communs.

Les éléments et connecteurs les plus importants utilisés avec le diagramme Paramétriques sont :

Éléments
· Propriété de contrainte
· Propriété

Extensions d'éléments
· Fonction objectif
· Mesure de l'efficacité

Connecteurs
· Dépendance
· Flux Item
· Connecteur
· Connecteur de liaison

Des éléments peuvent être ajoutés au diagramme en les faisant glisser et en les déposant depuis la page Boîte à outils
vers le canevas du diagramme .

Systèmes d'équations utilisant des associations de parties

Les problèmes et systèmes d’ingénierie nécessitent généralement une analyse détaillée pour déterminer les performances
d’une solution proposée particulière. L'analyse peut impliquer un certain nombre d'équations qui sont souvent liées les
unes aux autres pour déterminer une valeur particulière. Enterprise Architect permet à un ingénieur de construire des
systèmes d'équations à l'aide d'un diagramme de définition Bloc , puis d'utiliser ces équations dans plusieurs diagrammes
Paramétriques pour décrire les solutions proposées.
Ce diagramme de définition Bloc décrit les paramètres de la dynamique en ligne droite d'un véhicule - le HSUV - et
comprend un certain nombre d'équations qui sont représentées sur le diagramme sous forme de contraintes, qui sont un
type de Bloc .

Le diagramme suivant, un diagramme Paramétriques , montre comment les ConstraintBlocks sont utilisés dans un
contexte particulier, étant représentés sur le diagramme par ConstraintProperties. Nous pouvons visualiser comment le
paramètre de puissance totale est calculé, avec une connexion entre l'équation de puissance et le paramètre équivalent sur
l'équation d'accélération. Des liens peuvent être observés entre l'équation de position et l'équation de vitesse, qui est
finalement reliée à l'équation d'accélération.

Mesures d'efficacité à l'aide de paramètres

Les mesures d'efficacité (MOE) sont un mécanisme d'ingénierie important utilisé pour quantifier la réalisation des
objectifs de la mission ou des résultats souhaités spécifiés. Ils peuvent être modélisés à l'aide du diagramme
Paramétriques , et l'élément Mesure de l'efficacité est disponible sur la page « Paramètres » de la boîte à outils
Diagramme , à partir de laquelle il peut être glissé sur un diagramme et associé aux paramètres des équations
représentées sous la forme de ConstraintProperties.

Les mesures d'efficacité peuvent être réutilisées pour évaluer un certain nombre d'alternatives de conception et permettre
à ces conceptions d'être systématiquement comparées et évaluées. Ce diagramme montre la rentabilité globale d'un SUV
hybride (HSUV) pour une solution proposée intitulée « Alternative One » (alt1) basée sur un certain nombre de MOE,
notamment :
· FuelEconomy - Expression de l'économie de carburant
· QuarterMile - Temps nécessaire pour parcourir 0,25 miles
· Zero60Time - Temps nécessaire pour accélérer à 60/mph
· CargoCapacity - Le volume des espaces de chargement
· UnitCost - Coût du véhicule
Chacun d'eux aurait son propre modèle Paramétriques qui serait capable de déterminer la valeur effective et de contribuer
à l'équation globale, qui est une série de sommes pondérées {CE = Somme (W i*P i)}. Enterprise Architect permet de
définir un nombre illimité d'alternatives et l'ingénieur peut réutiliser les éléments MOE et les ConstraintBlocks utilisés
pour définir les équations contributives.

Enterprise Architect dispose d'une fonctionnalité de recherche utile qui permet de localiser le type sur lequel une
propriété est basée dans la fenêtre Navigateur . Cette fonction est particulièrement utile pour trouver le Bloc propriétaire
ou la contrainte d'un Bloc ou ConstraintProperty trouvé sur diagrammes Paramétriques et Bloc Internes.

Il est possible de configurer un diaporama à l'aide de l'onglet ' Modèle Vues ' de la fenêtre Focus . Pour plus
d’informations, consultez la rubrique d’aide Diagram Slide Show .

Utilisation Propriétés et des pièces pour l'utilisation

Modèle Bloc
Les blocs sont des classificateurs et décrivent les caractéristiques d'un ensemble d'éléments qui représentent la façon dont
le Bloc est utilisé dans un contexte. Lorsque le Bloc a des attributs (propriétés valeur ) définis, ceux-ci reçoivent des
valeurs spécifiques dans les instances du Bloc . En effet, chaque instance Bloc a une identité et se voit généralement
attribuer différentes valeurs qui définissent l'état du Bloc . Enterprise Architect permet de spécifier ces valeurs à l'aide
d'une option Définir State Exécuter disponible dans le menu contextuel.
diagrammes Bloc internes montrent souvent comment les parties d'un Bloc sont connectées entre elles dans un contexte
d'utilisation. Enterprise Architect permet aux blocs d'être glissés de la fenêtre Navigateur vers un diagramme et déposés
en tant que Propriétés de pièce. Ce sont en fait des parties et représentent des instances du classificateur Bloc . Un
ingénieur a la possibilité de les nommer dans le contexte du diagramme . Par exemple, ce diagramme représente un
ensemble de freins qui a été modélisé, qui est indiqué dans le cadre du diagramme sous ce format :
ibd [bloc] Ensemble de frein [Pièces de maître et de cylindre de roue]

· ibd - signifie qu'il s'agit d'un diagramme Bloc interne

· block - signifie le type d'élément dû
· Ensemble de frein - est le nom de l'élément
· Pièces du maître et du cylindre de roue - est le nom du diagramme
L'ingénieur a nommé chacune des pièces du cylindre de roue (Avant gauche, Avant droit, Arrière gauche, Arrière droit)
car celles-ci doivent être identifiées par rapport à leur emplacement dans le véhicule, mais a décidé de ne pas nommer le
maître-cylindre car cela ne donnerait plus de nom. une qualification est requise.

Présentation des Diagrammes Fonctionnels Internes

Un diagramme Bloc interne permet de visualiser la structure interne d'un Bloc , y compris ses Propriétés et ses parties,
ainsi que la manière dont ces parties sont liées les unes aux autres. Le diagramme n'est pas obligé d'afficher toutes les
parties qui composent un Bloc donné et il est courant qu'un ingénieur crée un diagramme qui se concentre sur un aspect
particulier d'un système ou d'un sous-système.
Le cadre d'un diagramme Bloc interne représente le Bloc propriétaire, il sera donc nommé comme tel et les éléments qui
apparaîtront sur le diagramme seront des parties qui sont des instances des blocs dont le Bloc propriétaire est composé.
Ce diagramme Bloc interne montre une instance d'un véhicule dans un contexte donné ; il utilise un certain nombre
d'images à la place des symboles conventionnels du langage SysML afin d'ajouter de l'attrait et de rendre le diagramme
plus convaincant pour un public non-ingénieur. Pour plus d'informations, consultez la rubrique d'aide Internal Block
Diagrams .

Création d'un Diagramme de Principe Interne

Un diagramme Bloc interne peut être créé à partir de plusieurs endroits dans l' Interface Utilisateur , tels que :
· Ruban de conception - Diagramme Icône de diagramme sur le panneau Diagramme
· Barre d'outils de la fenêtre Navigateur - Icône Nouveau Diagramme
· Menu contextuel de la fenêtre Navigateur - Ajouter Diagramme
Nous utiliserons le ruban Conception pour créer un diagramme Bloc interne. Tout d'abord, sélectionnez l'emplacement
dans la fenêtre Navigateur où vous souhaitez que le diagramme soit situé. Contrairement à la plupart des autres
diagrammes SysML, le diagramme Bloc interne est généralement inséré sous son Bloc propriétaire. Une fois
l'emplacement sélectionné dans la fenêtre Navigateur , sélectionnez l'élément du ruban :
Conception > Diagramme > Ajouter Diagramme

La sélection de cette option ouvrira la dialogue Nouveau Diagramme , vous permettant de nommer le diagramme ; le
nom diagramme est par défaut le nom du Bloc qui contient le diagramme . Avec la perspective SysML choisie et la
version de SysML sélectionnée, une liste de types diagramme s'affiche à partir de laquelle vous sélectionnez le

diagramme Bloc interne. Cliquez sur le bouton OK pour créer un nouveau diagramme Bloc interne à l'emplacement
sélectionné dans la fenêtre du Navigateur . Le canevas diagramme s'ouvrira, vous permettant de commencer à ajouter des
éléments et des connecteurs qui décrivent la structure interne du Bloc . Enterprise Architect affichera également la page '
Bloc interne' de la boîte à outils, qui contient les éléments et les relations définis par la spécification SysML pour être
applicables à la construction de ce type diagramme . Un certain nombre d'autres pages de la boîte à outils peuvent être
ouvertes si nécessaire, en plus des pages « Éléments communs » et « Relations communes » qui sont toujours
disponibles.

Modélisation et pièces de liaison

Lorsqu'un Bloc est composé d'un certain nombre d'autres Blocs, il arrive généralement que lorsque le système est
instancié, les Blocs contenus effectueront une grande partie du travail requis du Bloc propriétaire. Le diagramme Bloc
interne fournit un mécanisme de langage pour visualiser comment les parties interagissent, pour montrer la structure des
blocs dans leur contexte et pour fournir le comportement global spécifié par le Bloc propriétaire. Dans un sujet
précédent, nous avons vu un diagramme de définition Bloc du châssis d'un camion, décrivant les blocs qui composent le
châssis en fonction des blocs.

Le diagramme comprend des multiplicités aux extrémités des parties de l'Association montrant combien d'une partie
particulière peut être incluse dans une seule instance du Bloc propriétaire. Ces nombres représentent la cardinalité
exprimée sous forme de limites supérieure et inférieure, qui peuvent être définies dans la fenêtre Propriétés du
connecteur. Cette capture d'écran montre une partie de la fenêtre Propriétés utilisée pour définir les multiplicités et autres
propriétés de la fin de l'association, qui ajoutent toutes une sémantique riche à l'association.

Ce diagramme Bloc interne du châssis montre les pièces qui composent le châssis dans un contexte réel. Le nombre
d'essieux est défini pour l'instance particulière du camion.

Enterprise Architect permet à un ingénieur de créer diagrammes avec des pièces imbriquées à n'importe quel niveau, ce
qui permet de démontrer la structure d'un Bloc et la manière dont les pièces seraient connectées dans un contexte réel.
Ce diagramme montre des pièces imbriquées sur deux niveaux, mais n'importe quel nombre de niveaux est possible et
peut être créé sur un diagramme . Ce type d'expression peut conduire à diagrammes assez volumineux, et Enterprise
Architect supporte des formats de papier allant jusqu'à A0, permettant de créer et d'imprimer de grands diagrammes .

Dans le
diagramme , les ensembles d'essieux arrière primaire et secondaire ont été montrés en détail, où chaque essieu est
composé d'un ensemble de roues droite et gauche, qui eux-mêmes pourraient être représentés comme une structure
imbriquée comprenant l'ensemble de frein, qui dans Le tour pourrait montrer les ensembles de cylindres de roue.
Dans le cas où une pièce est ajoutée au diagramme mais que le modélisateur, pour une raison quelconque, doit modifier
le classificateur Bloc qui tape le Bloc , cela peut être fait à partir du menu contextuel "Pièces" qui offre une option
permettant de modifier le Type de propriété. . Cela peut être pratique lorsqu'un diagramme élaboré a été créé et il est plus
facile de laisser l'élément visuel en place et de simplement mettre à jour le Bloc sur lequel il est basé.

Collaborer en tant qu'équipe d'ingénierie

Une équipe d'ingénierie est multidisciplinaire et se compose de stratèges, de gestionnaires, d'ingénieurs système,
d'ingénieurs logiciels, de testeurs et autres. Les pressions commerciales pour lancer un produit ou fournir une solution
signifient que les équipes doivent travailler de manière plus intelligente et plus cohérente pour garantir les résultats de
l'ingénierie. Enterprise Architect a été conçu dès le départ comme une plate-forme collaborative, non seulement pour les
ingénieurs mais pour toutes les disciplines. Il permet aux individus et aux équipes de travailler ensemble et de partager
des informations, des modèles, des conceptions et des solutions avec une gamme complète d'outils allant des discussions,
révisions , une bibliothèque d'équipe et un chat au Contrôle de Version et Lignes de base .

Référentiel Central Partagé

Enterprise Architect n'est pas seulement un outil de dessin sophistiqué mais une plateforme modélisation qui permet de
valider, simuler, transformer et manipuler des modèles par programme. Ceci est possible car l'outil ne stocke pas les
diagrammes au format raster ou vectoriel, mais les images sont plutôt codées dans une base de données relationnelle avec
toutes les données de référence et autres métadonnées du référentiel. La plate-forme utilise cette base de données
relationnelle pour stocker toutes les informations et métadonnées modélisation , ce qui fournit le stockage principal
auquel accèdent les outils clients et Web. Pour plus d'informations, consultez le Sujet d'aide The Model Repository .
Cette architecture de produit permet aux utilisateurs de partager des modèles, diagrammes et d'autres informations de
référentiel telles que des données de référence, des images dans la Bibliothèque images et des documents dans la
Bibliothèque d'Équipe ainsi que de nombreuses autres fonctionnalités d'outils qui facilitent la collaboration et le travail
ensemble dans un environnement colocalisé ou distribué. équipe. Pour plus d'informations, consultez la rubrique d'aide
The Modeling Team .

Cloud computing
Le référentiel central décrit dans la rubrique précédente est accessible directement à partir du client de bureau Enterprise
Architect , à l'aide des couches de connectivité de base de données (ODBC) appropriées et des pilotes associés. Il existe
cependant un autre moyen plus simple d'accéder à un référentiel hébergé dans un Cloud , à savoir via les services Cloud
utilisant les protocoles http ou https. Le Cloud peut être sur site ou hors site et il existe de nombreuses façons de Cloud
configurer. Il existe également un serveur comprenant un certain nombre de modules pouvant être achetés, appelé Pro
Cloud Server , qui fournit une variété d'outils, facilités et de façons de visualiser les modèles via un navigateur sur un
ordinateur ou un appareil portable, tel qu'une tablette. ou un téléphone intelligent. Pour plus d'informations, consultez la
rubrique Pro Cloud Server Repositories .

Cela fournit une plate-forme pour travailler avec une variété de parties prenantes, des responsables de l'ingénierie aux
ingénieurs-conseils, localisés localement ou répartis dans le monde entier. La puissance de cette façon de travailler peut
être réalisée avec une configuration minimale et l'avantage de voir tous les membres de l'équipe et les parties prenantes
visualiser et contribuer aux mêmes modèles ne peut être sous-estimé.
Des gains de productivité peuvent être obtenus en étant capable d'obtenir des commentaires précieux et opportuns, ou de
discuter d'un diagramme avec un consultant en ingénierie pendant qu'il voyage en train pour se rendre à un salon
professionnel, ou du responsable de l'ingénierie pendant une pause après un symposium - tout cela. en temps réel et au
sein du modèle depuis un smartphone ou une tablette.
Le Pro Cloud Server fournit également une connectivité à une large gamme d'autres outils et plates-formes, couvrant les
systèmes Gestion des Exigences , les outils de gestion de configuration, les systèmes de suivi des problèmes, les
systèmes Gestion de Projet et plus encore.
Cette capture d'écran montre une liste de certaines des intégrations disponibles, bien que cette liste soit régulièrement
ajoutée, il vaut donc la peine de vérifier si des intégrations supplémentaires ont été incluses. Pour plus d’informations,
consultez la rubrique Integrate Data from External Providers .

Discussions et chat
Au cœur de la notion de collaboration se trouve la capacité d'un modélisateur à discuter et à discuter avec des collègues
ou des spécialistes de l'industrie et des normes au sujet d'un problème ou d'une solution. Enterprise Architect permet aux
ingénieurs, aux gestionnaires et autres d'entrer dans des discussions sur les éléments, diagrammes et les connecteurs. Une
publication peut être créée pour démarrer un fil de discussion ou une conversation dans laquelle d'autres modélistes
peuvent ensuite participer en répondant. Les discussions sont conservées séparément des méta-informations sur les
éléments et diagramme , ce qui permet de formuler des commentaires riches et constructifs sans affecter la
documentation ou les rapports générés à partir des modèles. Les discussions et le chat sont deux des options disponibles,
les discussions depuis la fenêtre Discuter & Révision et les chats depuis la fenêtre Chat & Mail.

Le chat est utile pour une communication rapide et réactive avec des collègues ou des experts qui ont été définis comme
faisant partie d'un groupe d'utilisateurs défini par la sécurité. Les discussions ne sont pas liées aux éléments du modèle de
la même manière que les discussions, mais sont plutôt globales et lorsque la fenêtre Chat & Mail est ouverte et qu'un
groupe est sélectionné, les éléments sont répertoriés par ordre date-heure. Pour plus d’informations, consultez la rubrique
d’aide Teams & Collaboration .

Ressources Kanban et calendriers

La technique Kanban a été implémentée dans Enterprise Architect de manière à améliorer considérablement la
productivité de votre équipe et la gestion de projets ou d'ensembles de tâches d'ingénierie logicielle et système. Dans
Enterprise Architect il s'agit d'une fonctionnalité simple à utiliser, vous permettant de gérer les éléments d'un backlog et
de les déplacer vers n'importe quel nombre de voies, ou même vers d'autres tableaux, représentant les étapes d'un
processus. La facilité peut être intégrée dans des processus d'ingénierie ou de développement de logiciels existants ou
nouveaux, ce qui entraîne une efficacité sans précédent.
L'un des grands avantages de l'utilisation de cette fonctionnalité est que les éléments qui participent aux diagrammes
Kanban peuvent être liés à d'autres éléments du référentiel, permettant une traçabilité complète depuis, par exemple, une
exigence jusqu'à une intention stratégique ou jusqu'à un composant d'une conception. et jusqu'à un élément d'un produit
lancé. Kanban peut être utilisé pour visualiser les ressources, les efforts et l'état d'avancement des éléments à mesure
qu'ils se déplacent dans un certain nombre de tableaux Kanban liés. Il s'agit d'un exemple tiré d'un processus de
développement logiciel lié à un projet d'ingénierie de systèmes d'entrepôt.

Pour plus d'informations, consultez les rubriques d'aide Kanban Boards et Resources & Work Items .

Révision de Modèles
Révision de Modèles offre aux parties prenantes du projet la possibilité de collaborer formellement à l'évaluation (
révision ) du contenu du modèle, y compris les éléments et diagrammes . Cet outil de collaboration pratique utilise un
certain nombre de fonctionnalités intégrées - telles que la vue Révision - pour gérer le processus de révision et visualiser
les discussions et les contributions à la révision . Un diagramme révision fournit un mécanisme permettant aux
participants d'ajouter des éléments et diagrammes à la révision . Ce diagramme contient un certain nombre d'éléments
liés au sujet de la révision .

N'importe quel nombre de révisions peut être créé et les modélisateurs peuvent se joindre et participer aux révisions . La
rampe de lancement de la révision facilité est le panneau « Collaborer » du ruban Démarrer .

La sélection de l'option « Révision > Gérer Révisions » ouvrira la vue Révisions , où toutes révisions existantes seront
répertoriées et - avec un clic droit de la souris - de nouvelles révisions pourront être créées. La vue affiche les
métadonnées Révision dans le panneau de gauche (y compris les dates de début et de fin) et les détails révision dans le
panneau de droite, y compris l'élément et diagrammes qui font partie de la révision ainsi que les publications et réponses
pour chaque élément.

Les commentaires révision peuvent être saisis et visualisés dans l'onglet ' Révision ' de la fenêtre Discuter & Révision .
Ceux-ci tiendront un compte courant de tous les messages et réponses annotant le message, ainsi que des réponses avec
l'auteur et la date. De cette manière, des résultats hautement collaboratifs peuvent être obtenus et - grâce au produit
WebEA disponible sur les téléphones intelligents et les tablettes - les parties prenantes telles que les consultants externes
et les experts du secteur pourraient contribuer à la révision sans avoir à utiliser l'application de bureau Enterprise
Architect .

Chacun des éléments de la vue Révision peut avoir un certain nombre de propriétés définies, notamment le statut et la
priorité de l'élément révision ; celles-ci peuvent être vues comme deux petites icônes (un drapeau et une icône de
quantité) à droite de l'article.

Partager des ressources dans la Bibliothèque d'Équipe

Les équipes qui utilisent des processus centrés sur Ingénierie Systèmes Modèles Basée s'appuieront invariablement sur
une vaste gamme de documents sous forme de politiques, méthodes, instructions, descriptions de processus, documents
guidage , normes et autres types de documentation d'ingénierie ou de projet. Certains d'entre eux seront basés sur des
documents et d'autres seront basés sur des ressources et disponibles sur un réseau interne, un système partagé, un Intranet
ou un Extranet ou plus largement l'Internet public.
Quel que soit l'endroit où se trouvent les documents ou les pages, ils peuvent être soit importés dans Enterprise Architect
, soit référencés en tant que ressources externes via une URL. Ils peuvent être inclus sur un diagramme en tant qu'artefact
interne ou externe, mais plus commodément, ils peuvent également être importés ou référencés depuis la Bibliothèque
d'Équipe .

On pourrait également envisager d'importer une partie ou la totalité des éléments de ces documents en tant qu'éléments
de modèle de première classe. Par exemple, une politique pourrait être créée en tant qu'élément de métamodèle et la liste
des politiques pourrait être importée, permettant ainsi de retracer les politiques individuelles jusqu'à des composants
système particuliers. Pour plus d'informations, consultez la The Model Library Rubrique d'aide.

Affichage des modèles sur les appareils mobiles

Le lieu de travail moderne a considérablement changé ces dernières années, les organisations encourageant la flexibilité
sous la forme de bureaux partagés et de travail à domicile, ce qui conduit de plus en plus de personnes à travailler sur des
appareils portables. En outre, le rythme du changement dans notre monde moderne s'accélère chaque année, entraîné par
l'innovation et les perturbations - par exemple, une pandémie affectant tous les pays dans lesquels sont basés des
fournisseurs, des clients ou des collègues, obligeant les gens à s'absenter de leurs bureaux partout et à ne pas pouvoir se
déplacer pour consulter ou livrer une expertise directement. . Les stratèges, les technologues et les ingénieurs doivent
collaborer pour obtenir des résultats d'ingénierie et, dans une main-d'œuvre dispersée, cela signifie généralement qu'ils
doivent contribuer aux modèles à partir d'appareils mobiles, à la fois en déplacement et dans un isolement restreint.
Le contenu du référentiel Enterprise Architect peut être consulté en temps réel via un navigateur sur un appareil mobile
tel qu'une tablette ou un téléphone intelligent. Cela permet aux ingénieurs, aux gestionnaires et à d'autres personnes de
collaborer entre deux réunions, lors d'inspections hors site, dans les transports publics ou partout où ils se trouvent. Cela
n'a jamais été possible auparavant, et maintenant , la vitesse d'un projet n'a plus besoin d'être ralentie en attendant
révisions ou le retour des gens au bureau ; les modèles peuvent être mis à jour à la vitesse d’Internet depuis n’importe où.
Pour plus d'informations, consultez la rubrique d'aide Pro Cloud Server Repositories .

Modélisation de l' Avenir

Le monde est animé par un appétit presque insatiable de changement et d'innovation, ce qui oblige les ingénieurs système
à travailler plus intelligemment et plus rapidement et à trouver des moyens intelligents de résoudre les problèmes.
Modélisation Consciente du Temps est une modélisation facilité unique qui permet aux ingénieurs et autres parties
prenantes de modéliser un nombre illimité d'états futurs. Cette introduction de l'état dans les modèles fournit un
mécanisme permettant de visualiser à quoi pourrait ressembler une solution proposée et permet aux ingénieurs de
comparer un certain nombre de solutions proposées. Une solution donnée peut être analysée et raisonnée et les pièges et
problèmes potentiels peuvent être identifiés dans les modèles. Révisions et des visites guidées peuvent être effectuées par
un certain nombre de parties prenantes et celles-ci peuvent être utilisées pour déterminer laquelle des nombreuses
solutions est appropriée.
Le processus peut être lancé en créant un clone d'un Paquetage pour lequel vous avez besoin d'un modèle d'état futur.
Cela peut être fait à l'aide des options du ruban ou à partir du menu contextuel de la fenêtre Navigateur .

L'outil affichera une prompt permettant à l'ingénieur de spécifier un nom et un numéro de version pour la structure
clonée. Le numéro de version est essentiel au fonctionnement de la fonctionnalité et est utilisé par Enterprise Architect
comme moyen de suivre les éléments et diagrammes qui font partie de cette future version avec le numéro de version
spécifié. L'outil prompt également un emplacement dans le référentiel pour la structure Paquetage clonée. Généralement,
on peut lui attribuer un nom qui inclut sa version et le parent contenu dans le Paquetage cloné ; Cependant, il peut
également être conservé dans une partie distincte du référentiel désignée pour les versions futures.

L'étape qui vient d'être effectuée établit simplement la structure du clonage et ne crée pas elle-même les états futurs de
l'élément ; il fait cependant une copie de tous les diagrammes contenus dans le Paquetage . Cette illustration montre un
Paquetage qui a été cloné, contenant deux diagrammes qui sont des copies des diagrammes du Paquetage d'origine.

Le diagramme reçoit le numéro de version spécifié dans la dialogue de version, défini par l'utilisateur à l'étape
précédente. Le clonage d'éléments individuels se fait en sélectionnant un élément sur un diagramme , mais jusqu'à ce que
cela soit fait, tous les éléments du diagramme seront la version précédente. Enterprise Architect dispose d'une facilité
disponible dans la feuille de propriétés diagramme qui permet au modélisateur de filtrer les éléments du diagramme selon
la version du diagramme .

La définition de cette propriété sur un diagramme nouvellement cloné affichera tous les éléments en échelle de gris car
ils proviennent tous de la version précédente. À partir de ce point, des éléments individuels peuvent être clonés et
Enterprise Architect fera une copie de l'élément sélectionné, créant ainsi des copies de tous ses connecteurs. Ceci est
important car cela permettra à l’élément d’être promu en tant que version actuelle mise à jour une fois la modification
implémentée. Les éléments individuels diagramme peuvent être clonés en sélectionnant l'élément dans le diagramme et
en affichant le menu contextuel, comme le montre cette illustration.

Une fois de plus, le numéro de version vous sera demandé. L'outil sera par défaut celui choisi pour le Paquetage cloné.
Une fois cela accepté, Enterprise Architect créera une copie de l'élément sélectionné et comme le diagramme est toujours
filtré selon la version , cet élément apparaîtra normalement dans le diagramme , les autres éléments étant toujours
affichés en niveaux de gris.

Le Navigateur affichera l'élément nouvellement créé (version 2) qui sera assemblé avec le diagramme . De cette façon, le
Paquetage cloné ne contiendra que des éléments et diagrammes avec le nouveau numéro de version. Pour plus
d'informations voir la Time Aware Modeling Aide sujet.

Contrôle de Version et Lignes de base

Nous vivons et travaillons dans un monde qui évolue à la vitesse d'Internet et, par conséquent, les problèmes et les
opportunités d'ingénierie évoluent à la même vitesse. C'est le défi des ingénieurs d'enregistrer, d'analyser, de créer et de
mettre en œuvre des solutions d'ingénierie dans ce laps de temps. Cela signifie que presque avant qu'un ingénieur ait
décrit complètement un problème, celui-ci aura changé ou le contexte commercial ou technique du problème aura
changé. La plupart du temps, la nouvelle direction ou les changements seront décrits et adoptés, mais d'autres fois, un
ingénieur devra revenir en arrière et revenir à une version précédente du problème, de l'opportunité ou de la solution.
Enterprise Architect dispose d'outils sophistiqués pour effectuer ce back-tracking.
Enterprise Architect dispose de deux outils fondamentaux pour travailler avec des versions antérieures du contenu
modélisation .
· Contrôle de Version - Une fois configuré, n'importe quel point de changement peut être renvoyé ; les utilisateurs
extraient des fragments de modèle, apportent des modifications et archivent les fragments, créant ainsi des versions -
pour plus d'informations, consultez la rubrique d'aide Version Control
· Lignes de base - Créées à des moments clés ou importants dans le développement d'un modèle ; un utilisateur crée
une ligne de base, puis, ultérieurement, le modèle évolué est comparé à la ligne de base à n'importe quel niveau de
granularité, et le contenu antérieur peut être restauré. Pour plus d'informations, consultez la Baselines Rubrique
d'aide.
Il y a une différence importante entre les deux méthodes, à savoir : Lignes de base doivent être créées intentionnellement.
Par exemple, si une équipe d'ingénieurs crée un modèle et qu'il est approuvé par un propriétaire de produit, le travail se
poursuit ensuite avec la phase deux. Si, pour une raison quelconque, l’équipe souhaite revenir en arrière et revenir au
modèle de la première phase, sans une ligne de base en place, cela ne serait pas possible. En revanche, une fois Contrôle
de Version configuré, la même équipe pourrait facilement revenir à la première étape à condition de connaître la date de
son achèvement.

Lignes de base

Lignes de base sont un moyen efficace de garantir qu'une équipe peut revenir en arrière sur un modèle jusqu'à une étape
ou un point significatif dans l'évolution du modèle. Ils fournissent une manière axée sur l'utilisateur de gérer le
changement et donnent aux équipes modélisation un sentiment de confort : si elles dérapent pour une raison ou une
dimension du problème, de l'opportunité ou de la solution, elles changent et doivent revenir à un point antérieur. peut
facilement être fait. Il est important de se rappeler qu'une référence est simplement un instantané d'un Paquetage
(incluant potentiellement des sous-packages) dans le référentiel, mais elle doit être créée intentionnellement et doit être
créée au moment qu'elle représente. Pour plus d’informations, consultez la rubrique d’aide Baseline Tool .

Contrôle de Version

Enterprise Architect permet à une équipe d'ingénierie de gérer les modifications et les révisions des projets en plaçant
Paquetages de modèles individuels, des nœuds de vue ou des nœuds racine sous Contrôle de Version . Contrôle de
Version est configuré dans Enterprise Architect via un certain nombre d'applications tierces de contrôle de code source
qui gèrent l'accès et stockent les révisions des Paquetages contrôlés. Une fois le logiciel Contrôle de Version installé et
configuré, une équipe peut enregistrer un historique des modifications apportées aux Paquetages , afficher et récupérer
les révisions précédentes du travail, extraire et archiver le contenu au fur et à mesure qu'il est en cours de travail et bien
plus encore. Cette facilité permet à une équipe de travailler en collaboration tout en offrant aux ingénieurs un moyen
isolé de travailler sur des parties particulières du modèle. Pour plus d'informations, consultez la rubrique d'aide Version
Control .

Serveur d'actifs réutilisable

Le serveur d'actifs réutilisables (RAS) est une fonctionnalité de productivité d'équipe qui permet aux équipes de stocker
le contenu modélisation dans un emplacement accessible aux groupes distribués de modélisateurs pour réutilisation.
Toute équipe ou organisation peut configurer un RAS, stocker du contenu et – via les paramètres de sécurité – le rendre
disponible. L'unité atomique de stockage est un atout qui peut être à la fois des informations basées sur la modélisation et
des fichiers :
· Paquetages contenus dans un référentiel et visibles dans le Navigateur
· Fichiers dans une gamme de formats de texte, de code et de graphiques, y compris des fichiers .qea
Le Serveur d'Actifs Réutilisable est disponible depuis le ruban 'Publier' en utilisant le panneau ' Échange de Modèles '.
Cela met ce service à votre portée.

Les actifs sont stockés dans le Cloud et nécessitent la spécification d'une connexion à un modèle de Service Pro Cloud
configuré à cet effet. En règle générale, cette tâche est effectuée par la section infrastructure d'un service informatique, et
les détails sur la manière de se connecter sont simplement fournis à l'équipe d'ingénierie. Cette capture d'écran montre les
détails requis pour établir la connexion basée sur le cloud.

Une fois qu'un serveur a été configuré, il est possible d'y ajouter n'importe quel actif. Formellement, le serveur est un
registre et le contenu est configuré pour être enregistré sur le serveur.

Le serveur d'actifs réutilisables peut être utilisé pour stocker des informations et des actifs modélisation entre des projets,
et est particulièrement utile pour stocker des informations à réutiliser entre des projets ou des programmes. Lorsqu'un
projet a apporté sa valeur à l'entreprise, il est assez courant que les artefacts du projet soient archivés et rendus
effectivement inaccessibles aux autres équipes. Le serveur d'actifs réutilisables est un endroit pratique pour stocker ces
artefacts afin qu'ils puissent être réutilisés par d'autres équipes. Par exemple, un projet qui a développé des modèles pour
un hôpital nouveau ou modernisé pourrait stocker ces précieux artefacts modélisation dans le RAS, puis chaque fois
qu'un autre hôpital est en cours de construction, ils pourraient être réutilisés, économisant ainsi potentiellement des
milliers d'heures de travail. Cette image montre les détails d'un Paquetage enregistré dans le RAS, y compris le numéro
de version, l'identifiant global de l'utilisateur et les commentaires qui aideront un ingénieur à rechercher du contenu
réutilisable à trouver les ressources qu'il recherche.

L'un des principaux avantages de l'utilisation de cette fonctionnalité est que le RAS contient les actifs dans une
arborescence de dépendances, permettant à un utilisateur potentiel de l'actif de comprendre les Paquetages dont il

dépend. Il s'agit d'un mécanisme analogue utilisé par les programmes d'installation de logiciels qui déterminent si un
élément logiciel sélectionné pour l'installation dépend d'autres éléments qui ne sont pas présents sur la machine cible et si
ces éléments ont à leur tour d'autres dépendances. Le Service d'Actifs Réutilisables réalise ce travail pour l'ingénieur et
effectue un parcours des graphes de dépendances, permettant à l'utilisateur de comprendre de quoi dépend le bien
recherché. Cette capture d'écran montre comment les dépendances peuvent être gérées dans le RAS.

Pour plus d'informations, consultez la rubrique d'aide du Reuseable Asset Service (RAS) .

Coordonner le comportement avec les activités

Comme indiqué dans une rubrique précédente, le Systems Modeling Language (SysML) présente deux aspects
fondamentaux qui sont analogues à deux catégories grammaticales importantes dans les langues naturelles que les
humains utilisent pour communiquer, à savoir les noms et les verbes . Dans le SysML, il s'agit de constructions
structurelles et Comportementale ; Les constructions structurelles sont analogues aux noms dans nos langues naturelles,
et les constructions Comportementale sont analogues aux verbes.
Nous avons fait référence aux aspects structurels du langage dans les sujets précédents, lorsque nous avons discuté à la
fois Paquetages et des blocs. Nous allons maintenant porter notre attention sur le principal diagramme Comportementale
, à savoir le diagramme d'activité. Il existe un certain nombre d'autres diagrammes de comportement, et en effet, le
comportement est visible dans diagrammes structurels sous forme d'opérations ainsi que dans le comportement qui est
directement affecté à un Bloc .
Même si le nouveau venu dans SysML, visualisant les diagrammes d'activité pour la première fois, peut se souvenir de
l'organigramme, il apprendra bientôt que le diagramme d'activité a une syntaxe et une sémantique qui vont bien au-delà
de l'organigramme. Le diagramme d'activité est formellement basé sur une branche des mathématiques appelée réseaux
de Petri et utilise un système de jetons pour indiquer à la fois la séquence d'actions ainsi que les éléments qui circulent
dans le système. Les éléments qui circulent peuvent être des éléments d'information, des éléments physiques ou encore
des signaux de contrôle. Nous ferons référence à ce système de jetons comme moyen d'éclairer le fonctionnement du
diagramme d'activité.
Ce diagramme , décrivant l'accélération d'un véhicule, montre de nombreux éléments couramment observés sur un
diagramme d'activité. Vous verrez dans les sujets suivants qu’il s’agit d’un diagramme très expressif qui, s’il est rédigé
avec soin, peut transmettre avec rigueur de nombreuses informations.

En fait, la syntaxe du diagramme d'activité est l'une des plus riches de tous les diagrammes SysML, et lorsque vous
ajoutez à cela les mécanismes et outils riches et efficaces qu'Enterprise Enterprise Architect inclut pour travailler avec
ces diagrammes , les opportunités pour un modélisateur d'exprimer en eux-mêmes, cela en fait l’une des parties les plus
polyvalentes mais aussi les plus difficiles de la représentation du système.
Le diagramme d'activité SysML est basé sur le diagramme UML du même nom, mais une sémantique supplémentaire a
été ajoutée dans deux domaines :
· Flux continu , permettant des restrictions sur la vitesse à laquelle les entités circulent le long des bords d'une activité,
et des mécanismes pour garantir que les informations les plus récentes sont disponibles pour les actions
· Probabilité , introduite dans Activités pour inclure la probabilité qu'une valeur soit disponible pour un bord ou une
sortie sur un ensemble de paramètres

Bien que l'on puisse dire que le diagramme est basé sur des mécanismes de sérialisation des verbes (chaînes de verbes
reliées entre elles par des noms) dans notre langage naturel, comme mentionné précédemment, il trouve ses origines
formelles dans une branche des mathématiques appelée réseaux de Petri et flux de jetons. Il est impératif qu'un
modélisateur comprenne l'aspect flux de jetons du langage et puisse apprendre à visualiser ces éléments invisibles qui
circulent à travers les flux Object , sont détenus dans des tampons et sont contrôlés par d'autres mécanismes de langage
qui dirigent la manière dont les éléments découlent des actions. Sans cette compréhension, il est difficile d'interpréter un
diagramme d'activité, y compris la manière dont la séquence d'actions est contrôlée, la manière dont les entrées sont
consommées et la manière dont les sorties sont créées.
La différence significative entre diagrammes d'activité et leurs proches cousins, tels que les organigrammes ou
diagrammes de processus, réside dans la capacité à créer des relations entre ces éléments comportementaux et ces
éléments structurels.
Un aspect fondamental de la discipline de Ingénierie des Systèmes est la capacité à séparer la fonction de la forme, mais
aussi à pouvoir créer une cartographie entre elles qui expose les coutures qui relient ces deux parties intégrantes de
l'architecture et du design. Des preuves empiriques sur des problèmes d’ingénierie de systèmes complexes à grande
échelle ont prouvé que cette approche présente de profonds avantages.
Enterprise Architect fournit une riche boîte à outils pour travailler avec ces relations, y compris la possibilité non
seulement d'attribuer le comportement du système sous la forme d'activités et d'actions aux blocs, mais également de
relier ces éléments aux fonctionnalités comportementales appartenant aux blocs, telles que les opérations.

Actions, les éléments de base Comportementale

Les actions sont les atomes comportementaux qui sont connectés entre eux pour décrire le comportement d'une activité,
d'un sous-système, d'un système ou de l'une de ses parties. En fait, une activité est composée d'un ensemble d'actions qui
fonctionnent ensemble pour convertir les éléments (jetons) entrés dans l'activité en éléments (jetons) générés par
l'activité. La première Action d'une séquence recevra ses entrées de l'un des nœuds de paramètres d'entrée de l'activité
propriétaire et la dernière Action de la séquence placera la sortie sur l'un des nœuds de paramètres de sortie de l'activité.
Les actions elles-mêmes ont des périphériques d'entrée et de sortie appelés Pins - une Action recevra des jetons sur ses
Pins d'entrée, effectuera son travail et placera les jetons résultants sur ses Pins de sortie.

Enterprise Architect dispose d' support riche pour modélisation des actions et de leurs entrées et sorties, et diverses
parties de l'interface utilisateur peuvent être utilisées tout en travaillant avec ces éléments fondamentaux du
comportement. Il existe un certain nombre de types d' Action différents disponibles dans la boîte à outils.

Un ingénieur peut ajouter une Action directement à partir de la boîte à outils, mais il est plus courant de créer des actions
à partir d'activités existantes qui ont été définies dans des hiérarchies, comme décrit dans la rubrique Création de
hiérarchies d'activités . Pour ce faire, une activité doit être glissée NON depuis la boîte à outils mais depuis la fenêtre
Navigateur et déposée sur un diagramme d'activité ouvert en tant qu'invocation - cela a pour effet de créer une Action
basée sur l'activité et de la placer dans le diagramme .

La fenêtre Propriétés intégrée facilite le travail avec les actions et leurs Pins . Un ingénieur peut spécifier une gamme de
propriétés pour l' Action et ses Pins , notamment le nom de la broche, Type , la multiplicité, la direction et bien plus
encore. La fenêtre Propriétés peut être ancrée ou rendue flottante, et même glissée sur un autre moniteur ; au fur et à
mesure que les éléments sont sélectionnés dans la fenêtre Navigateur ou dans un diagramme les propriétés peuvent être
visualisées, créées ou modifiées.

Au fur et à mesure qu'un diagramme est créé, les éléments ajoutés sont automatiquement insérés dans la fenêtre
Navigateur , permettant à un ingénieur de voir une vue structurelle de l'activité, des actions, Pins et d'autres éléments.
Même si le diagramme n'est pas ouvert, les éléments peuvent être sélectionnés dans la fenêtre Navigateur et édités
directement dans la fenêtre Propriétés .

Un certain nombre de ces propriétés seront affichées dans le diagramme de l'étiquette Pin, notamment le nom, le type et
la multiplicité. La multiplicité spécifie à la fois une limite inférieure et une limite supérieure. La limite inférieure
spécifie, pour une exécution donnée de l'action, le nombre autorisé de jetons que la broche peut consommer ou créer, et
la limite supérieure spécifie le nombre maximum de jetons consommés ou créés sur cette broche.

Il existe également un large éventail de fenêtres qui peuvent être utiles lorsque vous travaillez avec les actions,
notamment la fenêtre de traçabilité, qui montre comment les éléments sont liés, quel que soit leur emplacement dans le
référentiel ; il affiche également leurs fonctionnalités structurelles telles que Pins et les paramètres.

Présentation Diagrammes d'activités

Le diagramme d'activité est un diagramme qui peut être utilisé pour montrer la séquence d'actions qui décrivent le
comportement d'un Bloc ou d'un autre élément structurel. Les actions sont séquencées à l'aide de flux de contrôle et
peuvent contenir Pins d'entrée et de sortie qui agissent comme des tampons pour les éléments qui circulent d'une Action à
une autre (ou depuis des nœuds de contrôle ou de tampon). Le travail réalisé par les Actions consomme ou produit ces
objets. Les éléments peuvent être soit matériels, énergétiques ou informatifs, selon le système et l'activité décrite.

Création Diagrammes d'activités

Un diagramme d'Activité peut être créé à partir de plusieurs endroits de l' Interface Utilisateur tels que :
· Ruban de Conception - Icône 'Ajouter' Diagramme sur le panneau ' Diagramme '
· Barre d'outils Navigateur - Nouveau Diagramme ic o n
· Navigateur Menu Contexte - Nouveau Diagramme
Nous utiliserons le Ruban de Conception pour créer un diagramme d'activité. Sélectionnez tout d'abord l'emplacement
dans le Navigateur où vous souhaitez créer le diagramme d'activité. Comme pour tous diagrammes , il peut s'agir soit
d'un Paquetage , soit d'un élément, mais il est courant d'insérer diagrammes d'activité dans un Paquetage . Une fois
l'emplacement Paquetage sélectionné dans le Navigateur , sélectionnez l'option du ruban :
Conception > Diagramme > Ajouter Diagramme

La sélection de cette option ouvrira la dialogue Nouveau Diagramme , vous permettant de changer le nom du diagramme
(qui est par défaut le nom du Paquetage ou de l'élément qui contient le diagramme , tel que sélectionné dans le
Navigateur ). Avec la perspective SysML choisie et la version de SysML sélectionnée, une liste de diagrammes
s'affichera à partir de laquelle vous sélectionnerez le diagramme d'activité. Lorsque vous cliquez sur le bouton OK , un
nouveau diagramme d'activité sera créé à l'emplacement sélectionné dans le Navigateur . Le canevas diagramme
s'ouvrira, vous permettant de commencer à ajouter des éléments et des connecteurs qui décrivent la valeur que le système
fournira à ses utilisateurs. Enterprise Architect affichera également les pages « Activité » de la boîte à outils, qui
contiennent les éléments et les relations définis par la spécification SysML pour être applicables à la construction
diagrammes d'activité. Un certain nombre d'autres pages de la boîte à outils peuvent être ouvertes si nécessaire, en plus
des pages de la boîte à outils Éléments communs et Relations communes qui sont toujours disponibles.

Les éléments et connecteurs les plus importés utilisés avec le diagramme d'activité sont :

Éléments
· Activité
· Action
· Épingle Action
· Cloison
· Paramètre
· Initial
· Final
· Décision
· Fourche et Joindre
· Magasin de données
Connecteurs
· Flux de contrôle
· Flux Object
· Flux d'interruption
Il existe de nombreux autres éléments et connecteurs pouvant être utilisés sur ces diagrammes et qui sont importants pour
modélisation plus avancée ; certains d'entre eux pourraient être nécessaires à mesure que les modélisateurs deviennent
plus expérimentés ou que des parties plus complexes du comportement d'un système sont décrites ou conçues. Il s'agit
notamment du paramètre d'activité, de la fusion, du nœud de tampon central, des régions, Fourche et Joindre , Décision et
de la fusion.

Des éléments peuvent être ajoutés au diagramme en les faisant glisser et en les déposant depuis la boîte à outils vers le
canevas du diagramme . Il est considéré comme une bonne pratique de commencer par un élément Initial et un ou
plusieurs éléments Final , qui sont nommés de manière appropriée pour décrire la façon dont l'activité commence et les
multiples façons dont elle peut se terminer. Laisser le nom de ces éléments vide ou leur donner un nom éculé tel que «
début » ou « fin » n'aidera pas à faire comprendre au lecteur quel système ou quelle partie de système est modélisé et
peut conduire à une mauvaise interprétation. du diagramme . Lorsque ces nœuds ont été ajoutés et placés de manière
appropriée dans le diagramme , des actions et des nœuds Object peuvent être ajoutés au diagramme . Les actions peuvent
être connectées à l'aide de la relation Control Flow, définissant la séquence dans laquelle les actions seront exécutées.
Une fois qu'un diagramme de base a été créé, et à mesure que la connaissance du domaine et des comportements du
système s'accroît, il est possible de structurer ou d'embellir le diagramme en utilisant les éléments et relations
supplémentaires, notamment :
· Structures de contrôle pour les flux Object : fourches et Jointures , nœuds Décision et de fusion
· Structures d'entrée et de sortie d'activité : paramètres d'activité (en streaming et sans streaming)
· Regroupement d'ensembles d'actions : régions et bords interrompus
· Structures de stockage de jetons : magasins de données et tampons centraux
Comme indiqué précédemment, le diagramme d'activité dispose d'un riche ensemble de dispositifs linguistiques et
l'ingénieur est encouragé à utiliser ces dispositifs pour enrichir la description du système, mais une certaine prudence doit
être exercée pour garantir que ces mécanismes linguistiques peuvent être compris par le public visé. .

Création de hiérarchies d'activités

Les nouveaux venus dans le Langage Modélisation des Systèmes et Enterprise Architect pourraient être surpris
d'apprendre que ce ne sont pas des Activités mais des Actions qui sont utilisées sur diagrammes d'Activités. Les activités
qui sont les classificateurs des actions sont généralement visualisées sur diagrammes de définition Bloc . Cela peut
sembler un peu contre-intuitif, mais lorsque vous comprenez que l’ Action est l’atome fondamental du comportement du
système, cela prend plus de sens. Les activités sont des classificateurs et en tant que telles peuvent, comme les éléments
Bloc , participer à un large éventail de relations structurelles, c'est pourquoi les relations telles que les associations
marquées de composition peuvent être utilisées entre activités.

Dans ce diagramme une structure de décomposition a été utilisée dans laquelle une activité est décomposée en un certain
nombre d'activités plus granulaires à l'aide de la relation de composition. Un certain nombre de relations ont été
regroupées pour rendre le diagramme plus attrayant, en utilisant l'un des styles de lignes flexibles disponibles dans le
menu contextuel diagramme .

Spécification d' Séquence Action avec des flux de contrôle

Les actions sont exécutées dans le contexte d'une activité et l'ordre dans lequel les actions sont exécutées est largement
contrôlé par l'utilisation de connecteurs spéciaux appelés flux de contrôle. Ces connecteurs sont des lignes dirigées
tracées entre les actions et agissent essentiellement comme un conduit pour les jetons de contrôle – permettant aux jetons
de circuler d'une Action à la suivante dans le sens de la flèche. Une Action ne peut pas commencer son travail tant que
tous les flux de contrôle entrants n'ont pas reçu un jeton ; une fois qu'ils l'ont fait et que l' Action est exécutée, un jeton
est dit être placé sur le flux de contrôle sortant, ce qui implique qu'il se rendra à l' Action suivante de la séquence. Les
relations de flux de contrôle sont disponibles à partir des pages « Activité » de la boîte à outils Diagramme .

Il existe également des nœuds de contrôle qui peuvent être utilisés avec les flux de contrôle pour orchestrer le
fonctionnement des flux à l'aide de fourches, Jointures , de décisions et de fusions. Il existe trois nœuds spécialisés :
Initial, Final et Flow Final, qui servent respectivement de début et de fin du flux. Le nœud Final (anciennement Activity
Final) est utilisé pour indiquer que lorsqu'un jeton arrive, toute l'activité se termine, tandis que le Flow Final consommera
les jetons entrants mais n'aura aucun effet sur l'activité englobante.

Interrompre le flux normal

Il existe un certain nombre de circonstances lors de l'exécution d'une activité dans lesquelles un modélisateur peut
souhaiter spécifier un moyen d'arrêter le comportement dans une partie d'une activité. Par exemple, dans un scénario réel,
un utilisateur peut arriver à mi-chemin en utilisant une fonction de la machine telle que l'étalonnage d'une centrifugeuse,
puis décider de mettre fin à une partie particulière du processus d'étalonnage. Ce scénario peut être fourni par un bouton
Annuler sur l'interface. Le SysML permet de modéliser cette situation à l’aide d’une Région Interruptible et d’un Edge
Interruptif. La notation permet de dessiner la région Interruptible pour inclure un certain nombre d'éléments tels que des
actions et d'autres nœuds. Généralement, lorsque quelque chose d'inhabituel se produit, un événement est déclenché dans
l'activité et reçu par une Action de signal d'acceptation ; cet élément n'a pas de flux de contrôle entrants et un seul front
d'interruption sortant, qui cible une Action qui réside en dehors de la région.

Dans ce diagramme , un ingénieur a modélisé le processus utilisé pour effectuer un étalonnage de vitesse pour une
centrifugeuse. Le processus d'étalonnage de la centrifugeuse peut être interrompu pour diverses raisons ; par exemple, si
la centrifugeuse est devenue instable ou si l'opérateur est appelé pour effectuer d'autres tâches. Une Action d'acceptation
d'événement est utilisée pour montrer que l'activité dispose d'un mécanisme pour écouter une interruption requise dans
une région spécifiée de l'activité. Le connecteur spécial Interruption de flux cible alors une Action en dehors de la région,
qui est utilisée pour arrêter la centrifugeuse ; finalement, cela conduit à la fin de l'activité d'étalonnage.

Spécification du flux Item avec des flux Object

Les activités et les actions qui les composent fonctionnent généralement en traitant les éléments qui arrivent sur les
nœuds d'entrée et, lorsque le travail est terminé, en plaçant les éléments résultants sur les nœuds de sortie. Comme
indiqué précédemment, modélisation d'activité dans SysML est basée sur une branche des mathématiques appelée Petri
Nets, qui concerne les systèmes d'événements State discrets. Les éléments qui arrivent aux structures d'entrée doivent
traverser le graphique des activités et leurs actions contenues de manière ordonnée et systématique. Le passage est créé
par des flux Object qui agissent comme des conduits pour transporter les jetons d'un nœud à un autre. Les jetons
représentent un certain nombre de types différents de « choses », notamment des informations, des structures ou des
éléments physiques tels que des solides, des liquides et des gaz. Il y a donc deux parties importantes dans la façon dont
les éléments transitent par l'activité : les nœuds qui agissent comme origines et destinations des jetons, et les connecteurs
(conduits) qui transmettent les éléments.
Enterprise Architect prend entièrement support modélisation de ces flux, et lorsqu'un diagramme est créé ou ouvert pour
modification, la boîte à outils contient les nœuds Object comme indiqué :

Il contient également une section qui répertorie les relations de flux Object qui peuvent être utilisées pour connecter les
nœuds, créant ainsi le canal permettant aux jetons de circuler d'un nœud à un autre.

Orchestrer le flux de jetons

Lors de modélisation de systèmes complexes, il est souvent nécessaire de créer des chemins (conduits) plus élaborés
pour le flux de jetons, tels que des chemins de bifurcation et de jonction pour permettre aux jetons d'être envoyés à un
certain nombre de nœuds object afin que le travail puisse être effectué simultanément, ou pour permettre aux jetons d'être
acheminés vers un chemin particulier en fonction de certaines conditions. Ces nœuds de contrôle contrôlent le flux et
sont regroupés sur une page de la boîte à outils Diagramme .

Enterprise Architect permet de manipuler les connecteurs pour créer n'importe quel chemin requis. Cela peut être fait en
utilisant les styles de ligne du menu contextuel d'un connecteur ; le plus flexible d’entre eux est le style de ligne
personnalisé, mais il existe plusieurs autres styles très utiles. Un modélisateur peut également fixer les extrémités du
connecteur à une partie spécifique de l'élément Source ou Cible.

Stockage des jetons en transit

Lors de l'exécution d'une activité, il est parfois nécessaire de stocker des jetons pendant une période plus longue que ce
qui est possible avec les paramètres d'activité et Pins Action , qui agissent simplement comme des périphériques de
stockage temporaires. Une situation courante se produit lorsqu'un certain nombre d'actions nécessitent l'accès à un flux
de jetons : les jetons peuvent être stockés dans un tampon central et mis à la disposition des nœuds qui en ont besoin. Le
Central Buffer accepte tous les jetons sur ses flux entrants, puis met les jetons à la disposition des nœuds en aval ; une
fois acceptés, les jetons sont ensuite supprimés du tampon.
Le Central Buffer peut être créé en faisant glisser l'icône « Central Buffer » de la boîte à outils sur un diagramme
d'activité ouvert ; il peut ensuite être connecté à d'autres nœuds object à l'aide de flux Object .

Ainsi le Central Buffer peut, lors de l'exécution de l'Activité, être rempli de jetons ou vide selon la consommation de
jetons. Un autre type de nœud est le Data Store, une spécialisation du Central Buffer où, à mesure que les jetons sont
consommés par les actions en aval, une copie est effectuée et stockée dans le tampon. Cela a pour effet de donner au
magasin de données l'apparence d'un magasin permanent - mais uniquement pour la durée de vie de l'exécution de
l'activité.
Le Data Store peut être créé en faisant glisser l'icône « Data Store » de la boîte à outils sur un diagramme d'activité
ouvert ; il peut ensuite être connecté à d'autres nœuds object à l'aide de flux Object .

Modélisation Entrées et Sorties avec Paramètres et Pins

Les activités et leurs actions constituantes sont la main-d'œuvre des systèmes ; tandis que les éléments structurels tels que
les blocs et les parties définissent la structure ou l'anatomie d'un système, les activités définissent la physiologie.
Lorsqu'une activité est en cours d'exécution, nous voyons les éléments structurels être appelés à l'action pour accomplir
un certain type de comportement du système. Une grande partie du travail effectué par un système et les comportements
qui définissent ce qu'est le travail dépendent des entrées du système que l'activité en cours d'exécution consomme pour
produire des sorties.

Les entrées et sorties varient considérablement d'un système à l'autre et peuvent inclure des éléments tels que des signaux
de commande, des matériaux, de la lumière, des fluides, de l'énergie, des chiffres et des informations. Les entrées et
sorties sont appelées paramètres, qui peuvent être saisis et peuvent avoir des multiplicités. La saisie garantit que l'activité
spécifie le type (type) de « chose » qu'elle attend. Ainsi, si un distillateur avait un paramètre d'entrée avec un type de
liquide défini ou, plus précisément encore, un liquide-contaminant, alors l'activité serait mal formée s'il recevait un gaz
ou une valeur Integer en entrée sur ce paramètre. Les types peuvent appartenir à un ensemble défini allant d’un simple
Integer à une structure composée. Les entrées et sorties peuvent être saisies par un Bloc , de sorte que vous ayez un
élément structurel bien défini - par exemple, un article d'épicerie qui passe par un système d'auto-analyse à la caisse d'un
supermarché. Il existe une gamme d'autres propriétés qui peuvent être définies pour un paramètre, notamment Streaming
ou Non Streaming, Multiplicités et Direction. Le streaming est utilisé lorsqu'il y a un flux continu dans le paramètre,
comme avec un fluide, ou un signal de communication ou d'information tel qu'un flux audio ou visuel. Les multiplicités
définissent les limites supérieure et inférieure du nombre de jetons consommés par un paramètre d'entrée ou produits par
un paramètre de sortie. While Direction définit si le paramètre reçoit une entrée (in) ou produit une sortie (out) ou une
combinaison des deux (inout).
Lorsque des activités sont placées sur un diagramme d'activité en tant qu'invocations, elles sont représentées par des
actions, et tous les paramètres appartenant à une activité seront modélisés sous forme Pins sur ces actions. Les Pins
reçoivent des jetons sur les flux Object entrants et l' Action propriétaire effectue son travail et place n'importe quel
nombre spécifié de jetons sur les Pins de sortie. Les Pins peuvent avoir un type simple comme un Integer , une Structure
complexe comme une matrice ou encore un Bloc comme un flux vidéo. Les multiplicités spécifient une limite inférieure
et supérieure qui définit le nombre minimum et maximum de jetons autorisés à arriver et à partir d'une broche donnée. Ce
diagramme inachevé montre une Action avec une entrée et une broche de sortie et la transmission des jetons du
paramètre d'entrée de l'activité propriétaire le long du flux Object .

Les paramètres et Pins sont collectivement appelés points d'interaction, ce qui signifie qu'il s'agit d'emplacements où un
élément interagit avec son environnement ; ils peuvent être sélectionnés pour être inclus sur un diagramme en utilisant la
fenêtre multifonction Fonctionnalités .

Enterprise Architect vous permet de créer un diagramme qui montre l'activité propriétaire en tant que conteneur pour les
autres activités incluses dans le diagramme en tant qu'actions. Dans ce diagramme , les paramètres d'activité définis sur
les activités propriétaires sont exprimés sous forme Pins sur les limites des actions qui ont été incluses en tant
qu'invocations des activités. Le diagramme montre une activité avec deux paramètres d'entrée et un seul paramètre de
sortie. Les entrées sous forme de jetons peuvent être retracées à travers le diagramme à mesure qu'elles arrivent à Pins .
Une fois que l' Action a terminé son travail, des jetons sont placés sur les Pins de sortie. Les flux de contrôle montrent le
séquencement des actions incluses. A noter qu'une Fourche et Joindre sont utilisées pour montrer que deux Actions
peuvent être réalisées en parallèle. Notez également qu'un certain nombre d' Pins ont été définies comme un flux, ce qui
est indiqué sur le diagramme par la couleur unie de l'épingle.

Visualiser les activités avec des simulations

N'importe lequel des diagrammes d'activité SysML de vos modèles peut être simulé à l'aide du simulateur de modèle
dynamique intégré. Cela constitue un moyen convaincant de visualiser les diagrammes et est utile pour effectuer des
démonstrations ou des visites guidées avec l'utilisateur et d'autres membres de la communauté des ingénieurs.
À l'aide du Modèle Simulator, vous pouvez simuler l'exécution de conceptions de modèles conceptuels contenant du
comportement. Lorsque vous démarrez une Simulation , le Paquetage de modèle actuel est analysé et un processus
Simulation dynamique est généré pour exécuter le modèle. Comme le simulateur analyse et travaille directement avec les
constructions UML , il n'est pas nécessaire de générer du code intermédiaire ou de compiler des « exécutables » de
simulation. Il en résulte un environnement de simulation très rapide et dynamique dans lequel des changements peuvent
être apportés et testés très rapidement.

Fenêtre Simulation

La fenêtre Simulation fournit l'interface principale pour démarrer, arrêter et parcourir votre Simulation . Pendant
l'exécution, il affiche la sortie relative à l'étape en cours d'exécution et d'autres informations importantes. Voir la rubrique
d'aide Run Model Simulation pour plus d'informations sur les commandes de la barre d'outils.

Note la zone de saisie de texte juste en dessous de la barre d'outils. Il s'agit de la zone de saisie de la console - ici, vous
pouvez saisir des commandes JavaScript simples telles que : this.count = 4 ; pour modifier dynamiquement une variable
Simulation nommée 'count' en 4. De cette façon, vous pouvez influencer dynamiquement la simulation au moment de
l'exécution.

Fenêtre Points d'Arrêt et Événements

Le processus Simulation utilise également l'onglet ' Simulation Points d'Arrêt ' de la fenêtre Points d'Arrêt & Marqueurs (
' Simuler > Simulation Dynamique > Points d'Arrêt '). Ici, vous définissez des points d'arrêt d'exécution sur des éléments
et des messages spécifiques dans une Simulation . Voir les Simulation Breakpoints Aide sujet pour plus de détails.

Fenêtre Simulation Événements

La fenêtre Simulation Événements ('Simulate > Simulation Dynamique > Événements ') fournit des outils pour gérer et
exécuter déclencheurs . Déclencheurs sont utilisés pour contrôler l'exécution des transitions Statemachine .

Allocations et autres Relations

Un aspect ou une discipline fondamentale de Ingénierie des Systèmes est de relier les éléments structurels aux éléments
comportementaux. Ces deux aspects importants d'un modèle s'entremêleront au fur et à mesure du développement du
modèle, mais lorsqu'un certain nombre d'ingénieurs commencent à travailler pour définir le système, il est souvent
difficile de dire exactement comment le comportement et la structure seront liés. La relation d'allocation est
particulièrement utile dans ces situations. Il peut être utilisé comme un moyen de montrer la relation entre les éléments
comportementaux et les éléments structurels qui éclairera la modélisation plus rigoureuse qui sera utilisée à mesure que
les notions décrites dans le modèle deviendront plus sûres.

Enterprise Architect prend également supporte un certain nombre d'autres façons de représenter la relation d'allocation,
notamment en tant que compartiment dans l'élément de comportement ou de structure.

Tout élément autorisant les compartiments peut être configuré pour masquer ou afficher n'importe quel nombre de
compartiments disponibles. La liste des compartiments est spécifique à un élément et est dynamique, ce qui signifie
qu'un compartiment ne sera visible que si l'élément participe à une ou plusieurs relations du type spécifié et que la
relation n'est pas visible sur le diagramme le contenant. Les mêmes options peuvent être utilisées pour afficher une
gamme d'autres aspects structurels ou sémantiques des éléments, comme indiqué ici.

Il est également possible d'afficher la relation dans une notation de légende, où une note est connectée à l'élément et
affiche le nom de la relation et les détails de l'élément associé. Ce diagramme montre la notation d'une activité, montrant
le Bloc auquel elle a été alloué . Pour y parvenir, un ingénieur doit :

1. Assurez-vous que la relation est affichée dans le diagramme .

2. Sélectionnez la relation et affichez le menu contextuel.
3. Choisissez l'option 'Créer Note liée'.
Cette notation de légende peut être utilisée avec tout type d'élément ou de relation SysML et constitue un moyen utile
d'afficher la relation pour certains types d'audience.

Interactions comme Séquence de messages

Les systèmes sont constitués de parties et le comportement global d'un système est assuré par ces parties travaillant
ensemble de manière orchestrée. Communication entre les pièces et la synchronisation de leurs comportements sont
essentielles, tant du point de vue de la conception que du point de vue de la visualisation. Les unités structurelles d'un
système, représentées principalement par les blocs, échangent des messages et des signaux qui déclencheur des
comportements, aboutissant à un comportement système coordonné qui représente les fonctions du système.

Cet échange de messages et de signaux, et les comportements qui en résultent, peuvent être représentés sur un
diagramme Séquence qui montre les messages et signaux séquencés dans le temps entre les instances Bloc qui participent
à une interaction spécifique.

Lignes de vie, messages et activations

Dans un diagramme Séquence , les Blocs qui participent à l'interaction ont une durée de vie représentée par une ligne
pointillée, émanant de la base de l'élément et se poursuivant verticalement pendant toute la durée de vie de l'élément. Les
éléments peuvent être créés ou détruits à tout moment pendant la période représentée par le diagramme Séquence , et la
ligne de vie représente donc leur existence. Les éléments présents en haut du diagramme sont créés au début de
l'interaction. Un échange de messages entre un expéditeur et un destinataire débutera dans une bouée de sauvetage
(l'expéditeur) et se terminera dans une autre (le destinataire).

L'expéditeur appelle ou active effectivement un comportement fourni par la bouée de sauvetage réceptrice. Enterprise
Architect fournit des mécanismes utiles pour utiliser des comportements déjà définis sous forme d'opérations. Cette
illustration montre les propriétés d'un message existant, que le modélisateur peut sélectionner dans une liste déroulante
d'opérations préalablement définies. Alternativement, le modélisateur peut définir une nouvelle opération en
sélectionnant le bouton Opérations.

Formellement, lorsqu'un message cible une bouée de sauvetage, une exécution se produit, ce qui signifie qu'un
comportement est initié ou augmenté. Cette exécution est représentée visuellement par une activation, qui est dessinée
sur le diagramme sous la forme d'une fine superposition rectangulaire sur la ligne de vie, dont la longueur représente la
durée relative du comportement. L'étendue de l'activation du rectangle prend fin lorsqu'un message de réponse est
renvoyé à l'appelant.

Un Bloc (instance) peut être à la fois l'expéditeur et le destinataire d'un message, que l'on peut qualifier de message
réflexif car il commence et se termine sur la même ligne de vie. Dans ce cas, un deuxième rectangle d'activation, plus
court, est superposé à la première activation mais décalé vers la droite.

Messages qui créent et détruisent des blocs

N'importe quel nombre d'instances Bloc peut faire partie d'une interaction, et souvent un ensemble de ces instances sera
présent pendant la durée représentée par le diagramme Séquence . Ces blocs seront positionnés dans une rangée en haut
du diagramme . Il est cependant possible que des Blocs soient créés et détruits au cours du déroulement du diagramme .
Par exemple, un Bloc particulier pourrait n'être nécessaire que pendant une courte période et pourrait donc être instancié,
remplir sa fonction puis être détruit. Enterprise Architect permet à un ingénieur de spécifier qu'un message est un
message de création , ce qui signifie que le Bloc récepteur sera instancié à ce stade de la séquence temporelle du
diagramme . Ceci est réalisé en définissant l'action du message Cycle de vie sur « Nouveau », comme indiqué dans cette
illustration.

La définition de cette propriété a pour effet de déplacer le Bloc ciblé vers une position plus basse dans le diagramme , ce
qui signifie que l'instance Bloc ne sera pas créée avant ce stade dans la séquence temporelle globale du diagramme . Le
style de ligne du message est également modifié en ligne pointillée avec une pointe de flèche ouverte pour indiquer qu'il
s'agit d'un message Créer . Les autres aspects de la sémantique et de l'effet de ce message restent inchangés.

De manière analogue, la durée de vie d'une instance peut être interrompue en envoyant un message Destroy . En pratique,
cela signifie que l'instance a rempli son objectif et n'est plus nécessaire. Ceci peut être réalisé facilement en définissant à
nouveau une propriété de message, mais cette fois nous définissons l'action du message du cycle de vie sur
« Supprimer ».

La définition de cette propriété a pour effet de mettre immédiatement fin à la durée de vie de l'instance ; ceci est
représenté visuellement par la ligne de vie en pointillés arrêtée par une petite croix sur la ligne de vie au moment où le
message arrive.

Lorsqu'un diagramme Séquence représente un système logiciel dont la mémoire disponible est limitée, la destruction de
l'instance ciblée entraînera le retour de la mémoire alloué au pool de mémoire. Dans l'ingénierie des systèmes, la gestion
de la durée de vie des objets électromécaniques peut générer de nombreux autres avantages, tels que la consommation

d'énergie, la surchauffe, la disponibilité ou même des risques tels que la sécurité.

Messages synchrones et asynchrones

Les messages représentent essentiellement l'envoi d'un certain type de demande d'un expéditeur à un destinataire. Il
existe deux manières fondamentales pour l’expéditeur d’un message d’interagir avec le destinataire. Le premier type de
message est appelé message synchrone car les messages se produisent approximativement au même moment. Avec ce
type de message, l'expéditeur attend la réponse du destinataire avant d'envoyer des messages supplémentaires. Le
deuxième type de message est appelé asynchrone car l'expéditeur n'attend pas de réponse du destinataire avant de
poursuivre l'exécution, y compris l'envoi de messages supplémentaires à ce destinataire ou à d'autres.
Enterprise Architect crée par défaut des messages synchrones, mais le type de message peut être modifié en définissant la
propriété « Type de synchronisation » dans la dialogue « Propriétés ». Lorsque le type de message est défini sur
Synchrone (par défaut), le style de ligne est défini sur solide avec une tête de flèche fermée pointant vers l'instance du
destinataire. La ligne peut être annotée avec le nom et les paramètres du message.

Les messages asynchrones représentent des appels à des opérations ou des signaux envoyés aux destinataires ; dans les
deux cas, l'expéditeur n'attend pas de réponse et ne suspend pas son exécution en attendant une réponse. Dans le cas de
l'appel à une opération, l'opération elle-même serait définie comme asynchrone et le système ou la machine représenté
par le diagramme saurait ne pas attendre un retour de message (réponse). Enterprise Architect permet de définir ce type
de message via la propriété « Synch » comme expliqué précédemment. Lorsque le type de message est défini sur
Asynchrone, le style de ligne est défini sur pointillé avec une pointe de flèche ouverte pointant vers l'instance du
destinataire. La ligne peut être annotée avec le nom et les paramètres du message.
Il existe un troisième type de message qui peut éventuellement être utilisé avec un message synchrone, à savoir le
message de réponse . Ce message signifie une opération qui a été invoquée sur le destinataire renvoyant un accusé de
réception indiquant que le comportement a été exécuté et est terminé. L'inclusion de messages de réponse dans un
diagramme est une décision stylistique. Certains ingénieurs et modélisateurs préfèrent les laisser hors diagrammes pour
réduire l'encombrement visuel. Si un type de retour et valeur ont été définis, ils seront renvoyés dans le cadre du message
de réponse.

Les blocs peuvent avoir à la fois des opérations et des réceptions spécifiées dans le cadre de leur définition ; ce
paradigme décrit la relation entre les opérations et les réceptions et les messages et signaux.

· Invocation synchrone d'une opération - Message synchrone

· Invocation asynchrone d'une opération - Message asynchrone
· Réception Réception du signal - Message asynchrone

Présentation du Diagramme de Séquence

Le diagramme Séquence trouve son origine dans le Unified Modeling Language et dans ce langage, il a principalement
été utilisé pour représenter les interactions entre les composants de systèmes centrés sur les logiciels. Son utilisation a été
élargie dans le contexte de Ingénierie des Systèmes , où il est utilisé de manière plus générique pour représenter
l'échange séquencé dans le temps de messages et de signaux entre les unités structurelles d'un système ou d'une partie
d'un système.
Le diagramme Séquence comporte deux axes ; par convention, l'axe horizontal (x) représente les Bloc (instances) qui
participent à l'interaction et l'axe vertical (y) représente le temps. Il n'est pas nécessaire que les blocs soient ordonnés
d'une manière prescrite, mais un modélisateur les placera généralement dans l'ordre le plus illustratif et cet ordre est
souvent basé sur le moment où ils sont utilisés dans l'interaction. Le temps ne exécuter pas sur une échelle linéaire et
l'échelle de temps entre deux diagrammes peut être très différente. Par exemple, l'échelle de temps d' diagramme
Séquence représentant un système photographique à grande vitesse serait très différente de l'échelle d'un diagramme
représentant une caisse d'épicerie. Ce diagramme montre l'emplacement de deux diagrammes Séquence (« Démarrer
Vehicle Black Box » et « Démarrer Vehicle White Box ») qui sont des nœuds enfants d'un cas d'utilisation nommé «
Démarrer le véhicule ».

L'arborescence agit comme une aide à la navigation et en double-cliquant sur l'élément dans la fenêtre Navigateur , vous
ouvrirez le diagramme à partir de cette vue.

Dans le deuxième diagramme nous voyons un diagramme Séquence simple qui représente la séquence de messages
impliqués dans le démarrage d'un véhicule. Le diagramme montre qu'il existe deux blocs (instances) qui font partie de
l'interaction, et que des messages sont échangés entre les deux blocs et l'initiateur de l'interaction, et finalement le cas
d'utilisation.

Création Diagrammes Séquence

Un diagramme Séquence peut être créé à partir de plusieurs endroits de l' Interface Utilisateur en utilisant :
· Ruban de conception - Ajouter Icône Diagramme sur le Panneau de Diagramme
· Barre d'outils de la fenêtre Navigateur - Nouveau Diagramme Icône
· Fenêtre Navigateur Menu Contexte - Ajouter Diagramme
Nous utiliserons le ruban Conception pour créer un diagramme Séquence . Tout d'abord, vous devrez sélectionner
l'emplacement dans la fenêtre Navigateur où vous souhaitez créer le diagramme Séquence . Comme pour tous
diagrammes , il peut s'agir soit d'un Paquetage , soit d'un élément, mais il est courant d'ajouter diagrammes Séquence à
un Paquetage car cela implique généralement un certain nombre d'objets dans le Paquetage . Une fois l'emplacement
Paquetage sélectionné dans la fenêtre Navigateur , sélectionnez :
Ruban : Conception > Diagramme > Ajouter

La sélection de cette option ouvrira la dialogue ' Nouveau Diagramme ' vous permettant de nommer le diagramme ;
initialement, le nom sera par défaut le nom du Paquetage ou de l'élément qui contient le diagramme . Avec la perspective
SysML choisie et la version de SysML sélectionnée, une liste de diagrammes sera affichée, permettant la sélection du
diagramme Séquence . Une fois le bouton OK sélectionné, un nouveau diagramme Séquence sera créé à l'emplacement
sélectionné dans la fenêtre Navigateur . Le canevas diagramme s'ouvrira, vous permettant de commencer à ajouter des
éléments et des connecteurs qui décrivent les interactions importantes entre les objets. Enterprise Architect affichera

également les pages de la boîte à outils diagramme Séquence qui contiennent les éléments et les relations définis par la
spécification SysML applicables à la construction Séquence diagrammes . Un certain nombre d'autres pages de la boîte à
outils peuvent être ouvertes si nécessaire, en plus des pages Éléments communs et Relations communes qui seront
toujours disponibles.

Les éléments et connecteurs les plus importants utilisés avec le diagramme Séquence sont :

Éléments
· Interaction
· Séquence
· Fragment
· Point de terminaison
· Porte Diagramme
· State /Suite
Connecteurs
· Message
· Message personnel
· Récursivité
· Appel depuis la récursion

Des éléments peuvent être ajoutés au diagramme en les faisant glisser et en les déposant depuis le Navigateur ou depuis
la Boîte à outils sur le canevas du diagramme . Le processus typique consiste à réutiliser des éléments existants tels que
des blocs, qui ont des comportements sous forme d'opérations qui peuvent être sélectionnées comme base pour les
messages échangés entre les lignes de vie. Les éléments peuvent être ajoutés au diagramme sous forme de lien, mais le
plus souvent, ils sont ajoutés comme bouée de sauvetage.
Une fois qu'un diagramme de base a été créé, et à mesure que la connaissance du domaine et des interactions du système
est révélée, il est possible d'ajouter des fragments, des points de terminaison, des portes Diagramme et des éléments State
/continuation.

Orchestration de messages avec des fragments

De nombreux systèmes sont intrinsèquement complexes et, bien que de simples diagrammes Séquence soient utiles pour
donner une image globale d'un logiciel ou d'un dispositif électromécanique, ils doivent être augmentés pour permettre la
création de modèles sophistiqués de ces systèmes plus complexes. L'une des options de modélisation de la complexité
dans les flux de messages est le fragment combiné. Ceux-ci peuvent être utilisés pour séquencer les messages
différemment, notamment en étant capables de sélectionner des messages particuliers dans certaines circonstances ou
d'exécuter un message plusieurs fois. Il existe un ensemble de fragments combinés qui peuvent être utilisés et leur
opérateur détermine le type de fragment. Enterprise Architect supporte tous les opérateurs, permettant aux ingénieurs de
créer diagrammes capables de décrire de manière adéquate les systèmes d'ingénierie complexes modélisés. Des
fragments peuvent être ajoutés à un diagramme directement à partir de la page de la boîte à outils Interactions et peuvent
être positionnés pour superposer le groupe de messages approprié.

L'élément placé sur le diagramme est un Fragment générique et devra avoir son opérateur défini. Ceci peut être réalisé en
sélectionnant une valeur pour le type dans la feuille de propriétés Fragment combiné.

Cela changera le fragment en type approprié et permettra, par exemple avec le type alt , de définir un certain nombre de
conditions alternatives qui détermineront quel message sera déclenché.

Modélisation Changement avec Statemachines

Notre monde est en constante évolution à mesure que les « choses » changent ou évoluent, passant d'un état à un autre.
L'eau gèle, les glaciers se déforment et coulent, la glace fond, les feux de circulation alternent entre le vert, l'orange et le
rouge, les avions décollent, montent, croisent, descendent et atterrissent. La Statemachine SysML est utilisée pour décrire
comment la structure, sous forme de blocs, change d'état dans un cycle de vie limité dans le temps. Notre préoccupation
ne concerne pas la structure de l'instance Bloc mais son comportement, qui peut à son tour avoir un impact sur sa
structure. Nous ne nous intéressons pas à chaque état dans lequel une « chose » peut se trouver, mais plutôt aux états
significatifs. Ainsi, les états importants pour les molécules d’eau peuvent être solides , liquides ou gazeux , mais nous ne
nous intéressons normalement pas à l’eau liquide à une température de 67 degrés centigrades. Si nous regardions une
bobine de film sur la durée de vie d'un object , une Statemachine sélectionnerait les images significatives où des
changements importants et pertinents se sont produits.
Décider de ce qui est pertinent est la prérogative et le privilège de l'ingénieur modélisation , et le même Bloc peut avoir
n'importe quel nombre de Statemachines définies par les mêmes ingénieurs ou par des ingénieurs différents. L'état d'un
avion peut être modélisé du point de vue de l'embarquement et du débarquement des passagers, du point de vue de son
programme de maintenance, du point de vue du transport, ou de toute autre perspectives .
Ce diagramme Statemachine décrit les états opérationnels d’un véhicule automobile SUV. Le diagramme utilise States
composites, qui imbriquent States dans d'autres States . Il existe trois States de haut niveau : Off, Operate et l' State final
sans nom. L' State de fonctionnement comporte un certain nombre de sous-états, à savoir le ralenti, l'accélération/la
croisière et le freinage. Avec les transitions, cela décrit les états du véhicule lorsqu'il Démarre , accélère, freine, s'arrête et
enfin lorsque le contact est coupé.

À l'aide Enterprise Architect un ingénieur peut créer Statemachines et définir les transitions d'un état à un autre, y
compris Événements qui déclencheur le changement d'état et les actions qui sont déclenchées. En plus de ces
représentations modélisation standard, l'outil dispose d'une gamme de fonctionnalités qui peuvent aider à visualiser et à
raisonner sur cet important mécanisme linguistique qui relie la structure et le comportement. L'une de ces facilités - que
nous examinerons dans cette rubrique - est Statemachines Exécutables , disponible à partir du ruban Simulate.

Statemachines peuvent être définies à n'importe quel niveau de granularité car elles sont une expression du
comportement d'un Bloc . De nombreux nouveaux arrivants dans SysML sont confus sur ce point. Parce qu'un Bloc peut
représenter quelque chose de très simple - comme un interrupteur sur un panneau de commande d'un sous-marin - ou
quelque chose de complexe comme le sous-marin lui-même, une Statemachine peut également représenter les états à la
fois de l'interrupteur et du sous-marin. Les deux modèles Statemachine pourraient avoir la même complexité, même si les
éléments modélisés se situent eux-mêmes clairement à l’une ou l’autre extrémité du spectre en termes de complexité.
diagrammes Statemachine peuvent paraître assez simplistes au modélisateur inexpérimenté, mais ils constituent des
outils très efficaces pour la description et l’analyse de problèmes complexes qui ne peuvent être résolus autrement. Cela
nécessite un état d'esprit et une approche différents, et souvent le noyau du problème se concentre sur la sélection du
niveau de Bloc , son contexte et la perspective de la Statemachine , plutôt que sur les détails du diagramme . Souvent, les
meilleurs résultats sont obtenus de manière heuristique par un certain nombre d’ingénieurs travaillant ensemble. Cela
peut être accompli en utilisant fonctionnalités de collaboration d' Enterprise Architect , permettant aux ingénieurs
dispersés géographiquement de communiquer au sein du modèle, soit par courrier, discussions, chats et révisions
formelles via le client de bureau, soit dans un Navigateur sur un téléphone intelligent, une tablette ou un ordinateur
portable.

La Statemachine a son origine dans des comportements discrets pilotés par des événements, utilisant une Statemachine
finie basée sur une variante orientée objet du formalisme StateCharts de David Harel.

States et comportements
Un State est créé dans le contexte d'un Statemachine et est utilisé pour modéliser la condition significative définie par
l'ingénieur du Bloc propriétaire. Il est important de se rappeler que la Statemachine décrit la vie du Bloc dans une
perspective particulière, et les States doivent être définis de ce point de vue - pas tous States , mais les plus importants
tels que On/Off, Ouvert/Fermé, Vert/Ambre/Rouge ou Glace/Eau/Vapeur. Formellement, un State modélise une situation
dans l'exécution d'un comportement Statemachine où une condition invariante est valable pendant une durée particulière.
Un Bloc passe généralement du temps dans un State donné, ce qui peut durer des nanosecondes ou des jours selon le
contexte ; cet aspect temporel n'est généralement pas codifié dans les modèles mais peut être défini dans une simulation.
Il existe trois comportements (appelés Actions) qui peuvent être définis par rapport à un State donné :
· Entrée - Déclenché lorsqu'un State est entré
· Do - Lancé après le comportement d'entrée et avant le comportement de sortie
· Quitter – Licencié avant la sortie de l' State
Ce diagramme montre comment ces States sont représentés dans un diagramme Statemachine . Enterprise Architect peut
afficher de manière conditionnelle ces compartiments et d'autres au niveau d'un élément individuel, ou collectivement
pour tous les éléments du diagramme .

Il est également important de note que le nœud Final est formellement aussi un State , mais il n'a pas la même
sémantique de comportement que les States représentés sur diagrammes sous forme de rectangles aux coins arrondis.
Il existe trois types fondamentaux de State , chacun étant important pour modélisation d'une classe différente de
problèmes :
· State simple - ne contient pas States internes
· State composite : contient au moins une région qui possède States
· State de la sous-machine - représente une Statemachine entière imbriquée dans l' State propriétaire
Enterprise Architect vous permet de modéliser chacun de ces types State , et un modélisateur peut les utiliser de manière
productive dans diagrammes Statemachine pour exprimer des problèmes et des solutions d'ingénierie du monde réel.

Présentation Diagrammes Statemachine

Le diagramme Statemachine est l'un des neuf principaux types diagramme SysML ; il est utilisé pour créer et visualiser
le comportement des blocs lorsqu'ils changent d'état. Les éléments clés du diagramme sont States , les transitions et les
pseudo-états. Les States représentent une période significative de la vie du Bloc d'un point de vue particulier, les
Transitions représentent le mouvement d'un State à un autre et les Pseudo-États, comme nous le verrons, agissent comme
des contrôleurs de la circulation qui influencent la manière dont les transitions fonctionnent.
Enterprise Architect aide un modélisateur à créer n'importe quel nombre de diagrammes Statemachine , et chaque
diagramme peut avoir n'importe quel nombre d' States , de transitions et de pseudo-états. Chacun de ces éléments et
connecteurs diagramme peut à son tour recevoir d'autres informations ajoutées qui embelliront les diagrammes avec plus
de détails. L'application dispose d'un outil de productivité de bibliothèque motif qui est très utile pour les nouveaux
arrivants et bienvenu également pour les modélistes expérimentés. Cette capture d'écran montre la liste des motifs de
modèle pouvant être utilisés pour créer diagrammes Statemachine .

Le motif peut être utilisé pour créer un certain nombre de Statemachines différentes ; dans cet exemple, nous créons un
diagramme simple (une seule région) dans lequel tous les détails appropriés sont ajoutés aux States et aux Transitions.
Un modélisateur peut créer ce diagramme à l'emplacement approprié dans le référentiel, puis modifier les States , les
transitions et diagramme pour l'adapter à son propre contexte modélisation . Le diagramme Statemachine initial créé à
partir du motif ressemblera à ceci :

Cette fonctionnalité pratique prompts les ingénieurs à compléter des détails tels que les conditions Déclencheur et de
garde sur une transition, ou les actions d'entrée et de sortie sur un State , dont ils n'auraient peut-être pas eu connaissance
autrement - le résultat étant diagrammes alignés sur les meilleures pratiques d'ingénierie. , produisant de meilleurs
résultats pour les clients.

Création Diagrammes Statemachine

Un diagramme Statemachine peut être créé à partir de plusieurs endroits dans l' Interface Utilisateur en utilisant :
· Ruban de conception - Icône 'Ajouter Diagramme ' sur le panneau ' Diagramme '
· Barre d'outils de la fenêtre Navigateur - Icône ' Nouveau Diagramme '
· Menu contextuel de la fenêtre Navigateur - option ' Ajouter Diagramme '
Nous utiliserons le ruban Conception pour créer un diagramme Statemachine . Tout d'abord, vous sélectionnez
l'emplacement dans la fenêtre Navigateur où vous souhaitez que le diagramme Statemachine soit situé. Comme pour tous
diagrammes , il peut s'agir soit d'un Paquetage , soit d'un élément, mais il est courant d'insérer diagrammes Statemachine
dans un élément tel qu'un Bloc pour décrire les phases importantes de la vie d'un Bloc . Une fois l'emplacement
sélectionné dans la fenêtre Navigateur puis sélectionnez :
Ruban : Conception > Diagramme > Ajouter Diagramme

La sélection de cette option ouvrira la dialogue Nouveau Diagramme , vous permettant de nommer le diagramme ; le
nom sera par défaut le nom du Paquetage ou de l'élément qui contient le diagramme , mais vous pouvez le modifier. Avec
la perspective SysML choisie et la version de SysML sélectionnée, une liste de diagrammes s'affichera à partir de
laquelle vous pourrez sélectionner le diagramme Statemachine . Une fois le bouton OK sélectionné, un nouveau
diagramme Statemachine sera créé à l'emplacement sélectionné dans le Navigateur . Le canevas diagramme s'ouvrira,
vous permettant de commencer à ajouter des éléments et des connecteurs qui décrivent les phases importantes de la vie
du sujet. Enterprise Architect affichera également les pages Statemachine de la boîte à outils Diagramme , qui
contiennent les éléments et les relations définis par la spécification SysML pour être applicables à la construction
diagrammes Statemachine . Un certain nombre d'autres pages de la boîte à outils peuvent être ouvertes si nécessaire, en
plus des pages communes (éléments) et Relations communes qui sont toujours disponibles.

Les éléments et connecteurs les plus importants utilisés avec le diagramme Statemachine sont :

Éléments
· State - définit une phase importante dans la vie d'une entité
· Statemachine - définit un ensemble d' States

· Initiale : définit le point d'entrée dans une région

· Final - définit le dernier State qu'une entité aura
· Histoire - agit comme un souvenir ou un signet lorsqu'un State est quitté et rentré
Connecteurs
· Transition - représente le mouvement d'un State à un autre

Des éléments peuvent être ajoutés au diagramme en les faisant glisser et en les déposant depuis les pages de la boîte à
outils vers le canevas du diagramme . Il est considéré comme une bonne pratique de commencer par un élément Initial et
un ou plusieurs éléments Final State , qui doivent être nommés de manière appropriée pour décrire la façon dont la
Statemachine démarre et les multiples manières potentielles dont elle peut se terminer. Laisser le nom vide ou lui donner
un nom éculé tel que « début » ou « fin » n'aidera pas à faire comprendre au lecteur quel système ou quelle partie de
système est modélisé et peut conduire à une mauvaise interprétation du diagramme . . Avec ces nœuds ajoutés et placés
de manière appropriée dans le diagramme , States et des transitions peuvent être ajoutés, définissant ainsi les phases
importantes de la durée de vie de l'entité modélisée.
Une fois qu'un diagramme de base a été créé, et au fur et à mesure que la connaissance du domaine et des comportements
du système se développe, il est possible d'ajouter Déclencheurs , Événements et des Gardes aux Transitions, et des
comportements d'Entrée, de Faire et de Sortie aux States . Le nouveau venu peut souvent percevoir ces diagrammes
comme triviaux, mais ils peuvent révéler des idées profondes qu’il ne serait pas possible de voir autrement.

Déclencheurs et Transitions
La majorité des connecteurs que vous voyez sur un Diagramme Statemachine seront des transitions ; ce sont les lignes
qui relient un State à un autre, indiquant les manières autorisées dont le Bloc (instance) propriétaire peut changer. L'ordre
dans lequel ils changeront et les comportements qui seront exécutés dépendront des conditions et du contexte réel du
Bloc . Par exemple, un feu de circulation peut clignoter en orange jusqu'à ce que le technicien de maintenance ait corrigé
un défaut, ou un avion peut maintenir un motif d'attente jusqu'à ce que la tour de contrôle de l'aéroport de destination
donne l'autorisation d'atterrir. Ce diagramme montre deux transitions orientées dans des directions différentes, créant
effectivement la possibilité d'un cycle entre les deux States .

Les transitions proviennent toujours d’un State et en visent un autre, y compris le cas particulier d’une auto-transition où
l’origine et la cible ne font qu’un. Les lignes du diagramme ont une étiquette qui peut afficher un certain nombre
d'options différentes : Déclencheur , Guard et Effect . Nous discuterons de ces options en détail car elles expriment une
sémantique importante sur les transitions, notamment si la transition sera exécutée ou non. Une transition peut se faire
sous trois conditions :
· Atteint - l' State d'origine (ou sommet) est actif et prêt à terminer ses comportements
· Traversé : la transition est en cours d'exécution (y compris tous les comportements d'effet définis)
· Terminé - l'état cible a été atteint et est prêt à exécuter des comportements d'entrée
Ces termes seront utiles aux ingénieurs système et autres lorsqu'ils travaillent en collaboration, discutant de l'exécution
d'une Statemachine et de sa description du comportement du Bloc propriétaire.

Déclencheurs

Déclencheurs sont les initiateurs d'une transition et sont mappés à des événements censés déclencheur des occurrences
d'événements. Ce sont ces déclencheurs et leurs événements associés qui aboutissent à l'exécution d'une transition (tir) et
au passage du Bloc propriétaire d'un état à un autre. Lorsqu'un état est actif, il attend effectivement d'être déclenché par
un événement, et tant que son action d'entrée est terminée - indépendamment de tout autre facteur - il est prêt à recevoir
et à répondre aux événements.
Cette capture d'écran montre comment le Déclencheur , la Garde et l'Effet peuvent être saisis et visualisés dans
Enterprise Architect .

Ce diagramme illustre la façon dont le Déclencheur , la Garde et l'Effet sont affichés sur un diagramme . L'Effet dans ce
cas a été défini comme un comportement et a été lié à une Opération définie sur le Bloc .

Gardes

Les gardes sont les « gardiens » d'une transition et ce n'est que lorsque l'expression du garde est évaluée à True que la
transition se déclenche. Si l'expression est fausse, l'événement sera consommé et il n'y aura aucun changement
observable dans l'état du Bloc résultant du déclencheur .
L'expression d'une garde peut être définie en anglais simple, mais elle est généralement écrite sous la forme d'une
contrainte en utilisant un langage de contraintes formel tel que le langage de contraintes Object . Lorsque vous travaillez
avec des simulations ou Statemachines Exécutables la condition est exprimée dans la syntaxe du langage de code dans
lequel elle doit être générée, par exemple JavaScript ou C++. Cela s'applique également aux effets. Dans ce diagramme
nous pouvons voir une expression mathématique qui peut être évaluée par un humain ou une machine.

Effets

Outre le déplacement du Bloc propriétaire d'un état à un autre, l'importance de la relation de transition est qu'elle peut
exécuter un comportement qui pourrait être une activité ou une opération sur le Bloc propriétaire ou sur tout autre Bloc .
Ce comportement s'ajoute au comportement Exit qui aurait pu être défini sur l' State source et au comportement Entry sur
l'état cible. Cela garantit qu'il existe un mécanisme pour modifier le comportement pendant l'exécution de la transition.

Courbes de Bézier

Enterprise Architect dispose d'une large gamme d'outils et facilités pour travailler avec diagrammes , y compris
diagrammes Statemachine , et ceux-ci peuvent être utilisés pour aider à créer et visualiser les informations codifiées dans
les Statemachines . La possibilité d'acheminer des connecteurs qui contribuent à rendre le diagramme plus attrayant est
particulièrement utile lorsque vous travaillez avec des transitions. Le style de ligne du connecteur dans ce diagramme a
été défini sur une courbe de Bézier, donnant à la transition une apparence moins rigide.

La forme de la courbe peut être modifiée en faisant glisser le point de construction vers un nouvel emplacement.
N'importe lequel des nombreux styles de lignes peut être utilisé, fournissant ainsi au modélisateur une boîte à outils
d'options pour la présentation diagramme . Ce menu contextuel peut être sélectionné et le style de ligne défini pour
chaque connecteur individuellement. La couleur et l'épaisseur de la ligne peuvent également être définies à partir du
ruban Disposition .

States et régions composites

La modélisation des états doit être hiérarchique pour faire face à la complexité des systèmes d'ingénierie ; le SysML
propose deux mécanismes pour modélisation cette hiérarchie dans une Statemachine :
· Régions - qui sont des parties distinctes d'une Statemachine
· States composites - qui sont States contenant d'autres States
Les systèmes et les objets qu'ils contiennent présentent souvent un comportement concurrent dans lequel deux choses
peuvent se produire en même temps ; souvent, ces comportements distincts interagissent les uns avec les autres pour
créer un comportement complexe basé sur un état. Ces comportements sont généralement représentés dans le Bloc décrit
par la Statemachine et peuvent impliquer des parties qui ont des durées de vie différentes. Ces situations peuvent être
modélisées à l'aide de régions ; une Statemachine peut contenir n'importe quel nombre de régions, chacune avec son
propre ensemble d' States , de pseudo-états et les transitions qui les relient.
Un State lui-même peut avoir besoin d'être hiérarchique, un State unique pouvant être décomposé en un certain nombre
de sous-États représentant les États qui font partie de l' State composite. Par exemple, un robot peut avoir States de
fonctionnement et de maintenance ; l' State de maintenance peut être décomposé en un certain nombre de sous-états tels
que la recharge de la batterie, la mise à jour de l'environnement et la mise à jour des modules logiciels. Chacun de ces
States pourrait à son tour être décomposé en un certain nombre d'autres States .
Enterprise Architect fournit un point de départ utile pour modélisation du comportement d'états complexes, en
fournissant une série de motifs de modèle qui peuvent être utilisés pour modéliser tous les aspects des Statemachines , y
compris modélisation States et des régions composites.
States composites sont indiqués par le symbole oo (« infini ») et font référence à un diagramme enfant. Le diagramme
enfant peut être prévisualisé en cliquant sur l'icône . Un double-clic sur l'élément ou sur l'aperçu diagramme
ouvrira le diagramme pour l'éditer.

Ces motifs sont accessibles via l' Assistant de Modèle (onglet Page Démarrage 'Créer à partir d' Motif ').

Cette image montre un diagramme créé à partir du motif State avec régions , qui a été simplement injecté dans le modèle
et sert de point de départ au modélisateur. Le modélisateur peut personnaliser le diagramme en remplaçant les noms des
States et des Transitions et en ajoutant ou supprimant des régions selon les besoins.

Les régions de State B fournissent un flux parallèle de processus dans la région un et la région deux.

Pseudo-états - La police de la circulation

Les relations de transition qui relient States dans un diagramme Statemachine doivent être orchestrées pour garantir que
la Statemachine est représentative des libertés dont dispose un Bloc pour changer son état dans le monde physique. Les
pseudo-états sont des nœuds utilisés pour diriger le flux le long des transitions. Les nœuds peuvent apparaître au début,
le long du chemin d'une transition ou à la fin. Les types de pseudo-états comprennent :
· Initial - utilisé pour lancer une Statemachine
· Fourche et Joindre - utilisé pour diviser et réunir une Transition
· Terminer - utilisé pour mettre fin à une Statemachine
· Rejoindre - utilisé pour réunir un certain nombre de transitions
· Jonction - utilisé pour diviser une transition
· Point d'entrée et de sortie - utilisé à la bordure d'un State de sous-machine
· Histoire profonde et superficielle - utilisée comme souvenirs lors de la sortie d'un State composite
Nous examinerons chacun d'eux plus en détail et montrerons comment Enterprise Architect peut être utilisé pour créer et
gérer ces nœuds importants. il est important de comprendre que l’ State final – qui possède une icône analogue au
pseudo-État initial – est en fait un State à part entière.

Initial

Le pseudo-état initial est le plus largement utilisé de tous les nœuds et représente le point de déclaration d'une région. Il
ne peut y avoir qu'une seule initiale dans une région et une seule transition est autorisée à émerger du pseudo-état initial.
Parce que c'est le point de départ, cela n'aurait aucun sens d'avoir un déclencheur ou une garde - le pseudo-état devient
simplement actif lorsque la région est entrée, un modélisateur peut cependant définir un effet. Certains ingénieurs
système laisseront ce pseudo-état très important hors diagrammes , estimant que sa position est implicite, mais il est
considéré comme une bonne pratique de les inclure car formellement, le point de départ n'est pas défini sans eux. Il est
cependant courant de laisser le pseudo-état initial sans nom.
Enterprise Architect s'appuiera également sur la bonne formation des Statemachines et sur le fait que chaque région a un
pseudo-état initial défini, lorsqu'un modélisateur travaille avec Statemachines Exécutables ou exécute des simulations
pour visualiser les States une instance Bloc passera au cours de sa vie.

Fourche et Joindre

Lorsque des régions sont utilisées dans diagrammes Statemachine , il est souvent nécessaire de diviser une transition qui
cible l' State en plusieurs transitions de telle sorte que chaque transition sortante cible un State donné dans chaque région
orthogonale. Les transitions sortantes d'un pseudo-état Fork sont restreintes et ne peuvent pas avoir de garde ou de
déclencheur défini mais un effet peut être défini. Cela garantit que plusieurs régions peuvent avoir simultanément des
états actifs.

Jointures fonctionnent de manière analogue mais opposée pour unir les transitions entrantes provenant de plusieurs
régions. La restriction inverse s'applique de telle sorte que les transitions entrantes ne peuvent pas avoir de garde ou de
déclencheur défini mais qu'un effet peut être défini. Les effets de toutes les transitions entrantes doivent être terminés
avant que la transition sortante puisse se déclencher.

Mettre fin

Le pseudo-état Terminate est un nœud utile pour garantir qu’une Statemachine entière est arrêtée. Quel que soit le niveau
dans la hiérarchie State où se trouve le nœud, toutes les régions et tous les niveaux de la hiérarchie prendront fin. Il s'agit
d'un nœud final dans le sens où la Statemachine propriétaire cessera immédiatement de s'exécuter. La résiliation n'est pas
« gracieuse » et tous les comportements en cours d'exécution cesseront simplement ; aucun comportement de sortie ne
sera exécuté. Ce diagramme montre un State composite avec une seule région ; s'il y a une fuite de pression , le
fonctionnement de l'autoclave doit être immédiatement interrompu, il y a donc une transition de l'état de fonctionnement
au pseudo-état de fin de cycle interrompu.

Enterprise Architect permet à ce nœud d'être placé à n'importe quel niveau et dans n'importe quelle région et honorera sa
sémantique dans les simulations Statemachine Exécutable .

Jonction

Le pseudo-état de jonction est utilisé pour modéliser les transitions avec des chemins composés. Il existe des transitions
entrantes et sortantes qui sont connectées à une jonction, mais pendant l'exécution de la Statemachine , une seule des
transitions entrantes et sortantes se déclenchera. Les transitions sortantes sont protégées par des gardes et seule la
transition avec un garde dont l'expression est d'abord évaluée comme booléenne vraie se déclenchera et transportera le
jeton sortant.

Point d'entrée et de sortie

Les pseudo-états de point d'entrée et de point de sortie sont utilisés pour permettre à une Statemachine d'être réutilisée
comme State de sous-machine dans plusieurs contextes ; ils peuvent également être utilisés sur un State composite. Ces
pseudo-états apparaissent comme de petits cercles qui chevauchent la bordure d'un State composite ou d'un State
sous-machine ; le point d'entrée est vide alors que le point de sortie a un petit x à l'intérieur du cercle.

Leur position sur la bordure est significative car, d'un point de vue syntaxique visuel, ils permettent de faire passer des
messages entre l'intérieur et l'extérieur de l'élément.

Histoire profonde et superficielle

Le pseudo-état History est comme un signet ou un souvenir pour un Composite State et stocke simplement le nom du
sous-état qui était actif lorsque la région a été quittée. Lorsque la région est ensuite réintégrée, la Statemachine reprend
ses transitions à partir du sous-état spécifié par l'historique. Il est possible que, pour une raison quelconque, une région
puisse être réintégrée et que l'Histoire ne soit pas en mesure de fournir le dernier State ; cette situation peut être gérée par
un modélisateur créant de manière préventive une transition du pseudo-état d'historique vers un sous-état cible par
défaut ; la Transition ne serait utilisée que dans le cas où l'Histoire serait incapable de fournir le souvenir.
Dans cet exemple de centrifugeuse tubulaire, un ingénieur système a placé un State d'historique peu profond dans l' State
composite de fonctionnement, indiquant que si ce démarrage est quitté alors qu'un State donné est actif, puis que l' State
est ensuite réintégré, l'exécution sera reprendre au sous-état actif. La transition qui sort de l'Historique indique que, dans
le cas où l'on rentre dans l' State propriétaire et que la machine ne sait pas quel State activer, on sélectionnera le Rinçage
.

Les States d'histoire peu profonde et profonde fonctionnent de la même manière, sauf qu'un pseudo-état d'histoire peu
profonde ne se souvient que des sous-états actifs dans la région propriétaire, une histoire profonde peut se souvenir
jusqu'à n'importe quel niveau dans la hiérarchie des sous-états. L'Histoire approfondie est indiquée visuellement par un
astérisque placé après le H*.

Tableaux State - Une autre Vue

Une Statemachine peut être visualisée de différentes manières. Nous avons déjà examiné une vue diagramme de la
Statemachine , mais Enterprise Architect dispose d'un outil utile qui permet de visualiser la Statemachine dans un tableau
. Il existe trois variantes de visualisation du tableau :

· State Next State Vue - où les States et sous-états sont organisés en lignes et en colonnes et les cellules représentent
les transitions
· State Déclencheur Vue - où les déclencheurs sont organisés en colonnes et les états en lignes et les cellules
représentent les Transitions
· Déclencheur State Vue - où les déclencheurs sont organisés en lignes et les déclencheurs en colonnes et les cellules
représentent les transitions.
Ce diagramme des changements d'un feu tricolore, comme tout diagramme Statemachine , peut être converti en un State
Tableau .

Cette vue sera attrayante et plus naturelle pour certains publics, et l'ingénieur pourra simplement basculer d'une vue à
l'autre. Les States et leurs sous-États sont représentés à la fois sur les lignes et les colonnes du tableau , et les transitions
(représentant les chemins entre States ) sont représentées dans les cellules.

Les deux autres vues tableau , telles que décrites précédemment, permettent de situer les States face aux Déclencheurs
qui les initient. Ce sont des vues utiles lorsque l'ingénieur est plus intéressé par l'analyse causale et souhaite voir ou
analyser comment les événements et déclencheurs aboutissent au comportement de l' State du Bloc propriétaire. Ce
diagramme montre la même machine de feux de circulation représentée sous la forme d'un tableau de déclencheurs et
States .

Enterprise Architect permet également d'exporter ces tableaux afin qu'ils puissent être analysés à l'aide d'une feuille de
calcul. Il s'agit d'un mécanisme utile, en particulier lorsque la Statemachine est complexe et qu'il existe un grand nombre
de transitions.

Visualisation et mise en œuvre avec des simulations

Enterprise Architect n'est pas seulement une plate-forme de création et de gestion diagrammes Statemachine , il fournit
également facilités Simulation sophistiquées permettant aux ingénieurs et autres parties prenantes de visualiser les
Statemachines . Cela donne vie aux modèles et fournit un outil de visualisation, non seulement pour l'ingénieur qui
développe les modèles, mais également pour les autres publics, techniques et non techniques, qui ont besoin de
comprendre ce que dit le modèle. C'est un peu comme un auteur lisant à haute voix un passage de texte nouvellement
écrit, et cela peut aider l'ingénieur à trouver des erreurs dans les modèles ou des aspects des modèles qui devraient être
corrigés ou retravaillés. Cela est particulièrement utile à mesure que les modèles deviennent plus complexes, avec des
sous-états imbriqués, Déclencheurs et des gardes complexes, et des pseudo-états tels que des fourches et Jointures qui
divisent et réunissent les transitions.
Avec une support étendue des Déclencheurs , Déclencheur Ensembles , States imbriqués, States concurrents, des effets
dynamiques et d'autres capacités de simulation avancées, la fonctionnalité fournit un environnement sophistiqué dans
lequel créer des modèles interactifs et fonctionnels qui aident à explorer, tester et tracer visuellement des entreprises, des
logiciels et des logiciels complexes. comportement du système. Il existe un ruban dédié à la simulation, qui fournit une
gamme d'éléments pouvant être utilisés pour les simulations dynamiques et exécutables de Statemachines . Cette image
montre les outils de base pour travailler avec des simulations dynamiques.

La deuxième image montre les autres outils avancés, y compris le Statemachine Exécutable , qui peuvent être utilisés
pour créer des exécutions du Statemachine afin de produire du code de programmation entièrement implémentable et
compilable directement à partir des Statemachines simulées. L'image montre également un certain nombre d'autres
facilités , notamment Modelica et Simulink, qui sont des outils sophistiqués permettant d'exécuter des simulations
paramétriques complexes.

Ce diagramme montre une simulation dynamique simple du système de feux de signalisation que nous avons examiné
dans l'exercice précédent. Il montre la simulation dynamique en action.

Visualiser avec des simulations

Au fil des siècles, les humains ont élargi leur connaissance du monde grâce à l’étude des mathématiques et de la
physique et à l’application de systèmes de pensée et d’équations à des problèmes du monde réel. Grâce à ces
connaissances, nous avons construit des voitures et des avions, envoyé des humains sur la Lune, divisé l’atome et résolu
d’innombrables autres problèmes complexes. Ce savoir, dans l'Antiquité, était transmis de bouche à oreille, de tablettes
d'argile et de rouleaux de papyrus, puis de livres laborieusement créés par les scribes. Puis, avec l’avènement de
l’imprimerie, les connaissances ont été écrites sous forme d’articles, de revues et de livres et largement diffusées. Quatre
cents ans s'écouleraient avant l'arrivée d'Internet et une grande partie des connaissances existantes seraient transférées
vers du matériel en ligne sous la forme de documents, de pages et de sites dédiés à ces disciplines, les rendant ainsi
accessibles à un grand nombre de personnes aux quatre coins du monde. . Aujourd'hui, une nouvelle ère est arrivée où les
connaissances peuvent être utilisées pour construire des modèles qui nous permettent de visualiser ces équations en
mouvement et en contexte, avec des paramètres spécifiques à notre domaine et aux problèmes que nous essayons de
comprendre et de résoudre.

Simulation SysML dans Modelica et Simulink

Enterprise Architect , en tant qu'outil leader Ingénierie des Systèmes , permet de construire des modèles à l'aide de
techniques et de langages modélisation conformes à l'industrie pour la représentation de systèmes cybermécaniques. Ces
modèles servent de dispositifs de communication entre les ingénieurs collaborateurs, les équipes de consultants et autres,
mais peuvent également être utilisés pour générer des visualisations avancées à l'aide des langages modélisation standard
utilisés par OpenModelica et Simulink de MATLAB.
Cet exemple montre la puissance d' Enterprise Architect pour exploiter les normes ouvertes existantes pour visualiser des
solutions. Le diagramme représente deux réservoirs reliés entre eux et une source d'eau qui remplit le premier réservoir.
Deux contrôleurs continus sont utilisés pour réguler le débit d’eau du premier réservoir au second, ainsi que le débit du
deuxième réservoir.

Un ensemble de diagrammes est créé dans Enterprise Architect qui modélise les aspects physiques des réservoirs et les
équations (écrites dans le langage Modelica/MATLAB) qui caractérisent les flux entre les réservoirs. Une fois la
simulation configurée et le bouton Résoudre sélectionné, le résultat ressemble à ce diagramme :

Nous discuterons des détails de la modélisation des contraintes et paramétriques dans une section ultérieure de cette
rubrique, et verrons comment les modèles que nous créons sont simplement des définitions Bloc et diagrammes

paramétriques que nous avons découverts dans une section précédente du guide. Ce diagramme Paramétriques montre un
exemple de modélisation du problème à deux réservoirs, utilisant des propriétés de contrainte et des connecteurs qui lient
les paramètres dans un système d'équations. D'autres diagrammes sont nécessaires pour produire le résultat mais celui-ci
est le diagramme principal qui montre la masse, les débits et le capteur déterminant le niveau dans le réservoir.

Comment fonctionne Simulation SysML

Enterprise Architect a été construit sur des normes ouvertes et les équipes produit sont toujours conscientes de la
puissance et de l'efficacité de l'utilisation des solutions existantes et non de réinventer la roue. L'outil utilise ces normes
pour permettre la visualisation :
· Systems Modeling Language (SysML) - géré par l' Object Management Group (OMG)
· OpenModelica - géré par l'Open Source Modelica Consortium (OSMC)
· Modelica - géré par l'association Modelica
Nous avons consacré beaucoup de temps à formation de sujets précédents sur SysML ; en fait, nous avons déjà appris la
plupart de ce dont nous avons besoin pour créer les exemples de définition Bloc et Paramétriques pour ces visualisations.
De plus, nous apprendrons comment ajouter des informations supplémentaires dont OpenModelica a besoin ; cela sera
discuté dans la section suivante.
Modelica est un langage ouvert et orienté objet basé sur des équations, permettant la modélisation de systèmes
cyber-mécaniques utilisant des sous-composants. Comme ses cousins mathématiques, Modelica est un langage
inter-domaines qui a une grande variété d'applications, notamment dans les domaines mécanique, électrique,
électronique, hydraulique, thermique, de contrôle, d'énergie électrique et orienté processus, pour nommer les
sous-composants possibles de un modèle Modelica et les types de systèmes pouvant être modélisés à l'aide de l'outil.
Enterprise Architect est capable d'effectuer des simulations de base pour diagrammes de processus et Statemachines ,
mais pour modélisation de systèmes cybermécaniques complexes, il utilise la puissance d'OpenModelica, soutenue par le
langage Modelica lui-même pour faire le gros du travail. Enterprise Architect permet à ces modèles cybermécaniques
d'être liés à un large éventail d'autres systèmes et artefacts d'ingénierie logicielle, notamment les missions, les exigences
des parties prenantes, Statemachines , le code de programmation, Tableaux Décision , les architectures, l'analyse des
compromis et bien plus encore.

Un aperçu de son fonctionnement peut être mieux fourni au moyen d’un exemple simplifié. Créer une visualisation
simple de la deuxième loi de Newton : « Le taux de changement de quantité de mouvement est proportionnel à la force
agissant et s'effectue dans la direction de cette force. » (F = m*a), un ingénieur utilisant Enterprise Architect :
1. Créez un diagramme Bloc décrivant les équations à l'aide de contraintes et de valeurs.

2. Configurez l'artefact de configuration SysMLSim (utilisé pour définir les informations nécessaires à OpenModelica).

3. Exécuter la Simulation en sélectionnant le bouton Résoudre de la fenêtre.

Un graphique sera tracé avec f = 98,1 (qui est le produit de la masse (10) et de l'accélération (9,81) exprimée dans
l'équation [f = m * a] avec la valeur en place 98,1 = 10 * 9,81). Il s'agit d'un exemple simpliste visant à montrer les
ingrédients fondamentaux pour créer la visualisation ; nous examinerons des exemples plus avancés dans les sections
suivantes montrant l'utilisation des Propriétés de contrainte et Ensembles de données définis par l'utilisateur.

Démarrage avec OpenModelica

Un moyen simple de démarrer avec les machines d'OpenModelica et Enterprise Architect pour produire des simulations
Paramétriques est de visualiser quelques exemples existants. Il s'agit d'un outil formation utile pour toute fonctionnalité
d' Enterprise Architect , mais il est particulièrement pertinent lors formation de la puissance d'OpenModelica car il y a un
certain nombre de nouvelles choses à apprendre et il est préférable de le faire avec certaines aides formation . Nous
commencerons par examiner un exemplaire entièrement fonctionnel tiré du modèle Exemple, qui est distribué avec
chaque installation d' Enterprise Architect et est disponible à partir de l' Item d'aide du ruban Démarrer .
L'exemple que nous allons explorer est l'exemple Pendulum, mais nous devons d'abord ouvrir l'exemple de modèle, ce
que nous faisons en sélectionnant l'option du ruban :
Démarrer > Aide > Aide > Ressources > Ouvrir un exemple Modèle
Les fonctionnalités d'OpenModelica sont regroupées de manière pratique en un seul emplacement avec d'autres capacités
de simulation, et peuvent être lancées à l'aide du menu Modelica/Simulink disponible depuis le panneau « Comportement
du Système » du ruban « Simuler ». L'OpenModelica facilité tient compagnie à d'autres outils de simulation tels que
Statemachine Exécutable , Décision Modélisation Notation et BPSim.

Une fois le modèle chargé, nous pouvons utiliser les fonctionnalités d'OpenModelica dans Enterprise Architect pour
localiser le Pendulum. exemple dans le modèle. Il est courant qu'un modèle d'un système complexe soit très volumineux
et qu'un certain nombre de simulations existantes puissent être configurées. Enterprise Architect fournit donc un
mécanisme pour rechercher ces simulations.

La sélection de cette option renverra une liste d'artefacts de configuration de simulation SysML, qui sont les éléments
dans lesquels les détails d'OpenModelica sont spécifiés. Dans cette liste, nous pouvons sélectionner l'exemple Pendulum,
qui lancera une fenêtre pouvant être utilisée pour configurer et résoudre le problème codifié dans l'exemple. Pour pouvoir
exécuter la simulation, une version d'OpenModelica doit être installée sur la machine qui exécute Enterprise Architect .
Les détails sur la façon d'installer OpenModelica sont contenus dans la section suivante.

La fenêtre comporte deux sections :

· Le panneau de configuration (à gauche) définit les types de valeur, les blocs et Propriétés de contrainte, qui sont tous
définis dans le référentiel et - comme nous le verrons plus tard - peuvent être visualisés dans la fenêtre Navigateur et
dans diagrammes .

· Le panneau de simulation (à droite) est utilisé pour sélectionner et spécifier les options qui affecteront la simulation,
telles que l'ensemble de données, le temps d'attente et la durée de la simulation, les types de fichiers de sortie, etc.

Les informations dans la fenêtre sont automatiquement renseignées à partir du modèle visible dans la fenêtre Navigateur ,
et l'emplacement des éléments - y compris les types de valeur, les blocs et Propriétés de contrainte - peut être trouvé à
l'aide de l'option ' Rechercher dans Projet Navigateur ' du contexte. menu. Il existe également une option analogue pour
rechercher l'élément sélectionné dans les diagrammes dans lesquels il apparaît.

Installation d'OpenModelica

Enterprise Architect utilise la puissance de la plate-forme OpenModelica. Ainsi, lorsque vous exécuter une simulation à
partir de la fenêtre Simulation , il appelle effectivement OpenModelica (installé sur la même machine) pour faire le gros
du travail et renvoyer les résultats de la simulation. Cela garantit qu'Enterprise Enterprise Architect exploite la puissance
de cet outil ouvert et tous les esprits brillants qui ont contribué à son excellence. Il existe des versions Windows et Linux
d'OpenModelica et vous devrez installer celle adaptée à votre environnement. Les étapes sont résumées ici.
1. Téléchargez le logiciel OpenModelica ( Windows ou Linux).
2. Installez le logiciel.
3. Vérifiez l'installation.
4. Configurez le Solveur en spécifiant le chemin dans Enterprise Architect .

Tous les détails sur l'installation et la configuration sont disponibles dans la rubrique d'aide OpenModelica Integration .

Simulation avec Ensembles de données

Simulation constitue un aspect important de l'analyse technique et constitue un moyen utile et rentable d'analyser le
comportement d'un système. Le système peut avoir déjà été construit ou son développement peut être planifié ; Dans tous
les cas, la simulation peut être utilisée pour visualiser les considérations de conception de composants ou de systèmes,
l'optimisation des performances, l'ingénierie de sécurité et bien plus encore. Pour fournir cette fonctionnalité, il est
important de pouvoir exécuter une simulation en utilisant différentes valeurs de variables et de constantes. Par exemple,
dans notre exemple de pendule, nous pourrions vouloir analyser les performances du système sur différentes planètes,
pour examiner, disons :
· L'effet de la force gravitationnelle terrestre par rapport à la force gravitationnelle lunaire (ou d'une autre planète)
· L'effet de différentes longueurs string
· L'effet de différentes masses
· L'effet d'un point de départ différent
· Toute combinaison de ce qui précède
Enterprise Architect fournit un ensemble de données facilité pour les simulations qui peuvent être appliquées au niveau
Bloc . En utilisant l'onglet ' Simulation ' (panneau de droite) de la fenêtre de configuration SysMLSim, nous pouvons
sélectionner des ensembles de données prédéfinis.

N'importe quel nombre d'ensembles de données peut être défini et ajouté au Bloc approprié dans le panneau «
Configuration » (à gauche) de la fenêtre Simulation . Ceux-ci sont disponibles sous forme de nœuds sous chaque Bloc et
il existe une option pour afficher et modifier les valeurs des données dans une fenêtre en utilisant le bouton Parcourir [...]
sur la ligne des ensembles de données.

Une fois sélectionnée, la fenêtre Configurer les données Simulation s'ouvrira, permettant aux valeurs d'être visualisées et
modifiées, importées ou exportées. Ce mécanisme signifie que les machines de simulation peuvent être réutilisées dans
de nombreux contextes différents, et que les organisations d'ingénierie qui se concentrent sur des types particuliers de
problèmes peuvent créer des bibliothèques de simulations qui pourraient être réutilisées dans une multitude de contextes
et de types de problèmes d'ingénierie. La fenêtre illustrée ici montre un ensemble de données qui contient des valeurs
relatives aux deux problèmes de pendule que nous avons examinés et nous pouvons voir à titre d'exemple que
l'accélération due à la gravité lunaire a été définie comme une approximation de 1,6 m/s2, soit environ 16,6 % de la
valeur à la surface de la terre. Cette simulation pourrait être réutilisée avec différents ensembles de données applicables à
Mars ou Jupiter ou dans un exemple plus terrestre avec une masse ou une longueur de string différente.

Création de modèles pour Simulation

L'exemple que nous avons examiné dans la section Comment ça marche de ce guide était délibérément trivial ; dans cette
section, nous examinerons ces étapes plus en détail, y compris les options de configuration des modèles. Enterprise
Architect offre une grande flexibilité et permet de définir des modèles uniques triviaux ou de créer des modèles
polyvalents sophistiqués basés sur une bibliothèque qui peuvent être réutilisés dans plusieurs projets et domaines en
utilisant différents ensembles de données et contextes. Dans cette rubrique, nous explorerons certaines de ces options
pour configurer les modèles afin qu'ils soient adaptés à leur objectif et génèrent les résultats d'ingénierie requis.

Création d'un Paquetage Modèle de Simulation

Un Paquetage Modèle peut être configuré à n'importe quel endroit de la fenêtre Navigateur , mais il est généralement
considéré comme une bonne pratique de configurer un Paquetage de simulations pour chaque projet ou initiative.
Celui-ci pourrait alors contenir des sous-packages pour chaque simulation. Il est prévu que pour un projet donné, un
certain nombre de simulations différentes soient nécessaires. Il est également probable, comme indiqué dans la section
Ensembles de données, qu'une organisation souhaite réutiliser certaines simulations sur plusieurs projets. Ces simulations
pourraient être mises en place dans le Project Navigateur et définies à un niveau supra-projet - par exemple au niveau
d'une entreprise, d'une organisation ou d'un service d'ingénierie. Elles pourraient ensuite être incluses dans un diagramme
au niveau du projet, indiquant qu'elles sont applicables. à un contexte de projet ou de problème donné. Il est également
probable qu'une équipe d'ingénierie souhaite réutiliser les types de valeur et leurs bibliothèques de quantités et d'unités
concomitantes entre les projets, et ceux-ci, comme indiqué dans un sujet précédent du guide, sont mieux définis et
modélisés au niveau supra-projet.
Enterprise Architect utilise le mécanisme d'importation SysML Paquetage pour garantir que les types de valeurs définis
au niveau de l'entreprise peuvent être inclus et réutilisés à chaque niveau Paquetage Simulation . La structure contiendrait
généralement ces Paquetages :

1. Types de valeur (spécifiques à ce projet)

2. Blocs
3. Propriétés de contrainte

Dans la section suivante, nous apprendrons comment créer et configurer l'artefact Simulation SysML, stéréotypé comme
« SysMLSimConfiguration >>.

Création des éléments Simulation

Le principal effort de préparation d'une simulation réside dans la définition des éléments du modèle, en utilisant le
SySML avec le niveau de précision approprié pour permettre à la plateforme OpenModelica d' exécuter la simulation. Il
existe un certain nombre de façons de définir les modèles, et dans ce guide, nous nous concentrerons sur la méthode la
plus robuste et la plus flexible, car c'est celle qui sera utilisée par la plupart des ingénieurs et des équipes en exercice.
À ce stade, il convient d'examiner le sujet de la simulation pour nous assurer que nous comprenons sa pertinence et sa
connexion avec d'autres parties du modèle, ainsi que la manière dont les éléments de simulation peuvent être connectés à

d'autres éléments du modèle tels que Exigences , les cas Test , etc. En règle générale, les simulations sont utilisées pour
étudier un problème cyber-physique sans qu'il soit nécessaire de construire un modèle physique long et souvent coûteux.
La simulation peut faire partie d'une analyse de problème, d'une analyse de compromis, d'une analyse de performance ou
d'un certain nombre d'autres enquêtes. Les Blocs définis dans le cadre de la simulation pourront être alloué à des
éléments comportementaux et in fine à Exigences .
Les premiers éléments à créer sont les Blocs, qui sont les éléments structurels fondamentaux de la solution. Nous avons
appris comment procéder dans un exemple précédent ; ce diagramme montre un certain nombre de compartiments qui
comportent des éléments, à savoir les propriétés.

En préparation à la définition des équations qui définissent le comportement du système pendulaire, nous définirons les
types valeur requis pour garantir la précision du modèle et vérifierons que les paramètres de simulation sont correctement
spécifiés. Cela se fait à l'aide d'un diagramme de définition Bloc (bdd), en utilisant l'élément Value Type disponible dans
la boîte à outils Diagramme .

L'étape suivante consiste à définir les contraintes à l'aide de ConstraintBlocks. C'est dans ces éléments que nous
définirons les équations Modelica qui régiront le comportement du système modélisé - dans notre cas, un pendule.
Comme décrit précédemment dans ce guide, les ConstraintBlocks sont définis sur un diagramme de définition Bloc et ont
une série de paramètres définis et une contrainte qui exprime ces paramètres dans une équation écrite dans Modelica. Par
exemple, l’équation qui contraint l’aspect vertical du pendule s’écrit :
m * der(vy) = -(y/L) * F - m * g
Notez les mots-clés Modelica tels que «der» signifiant une dérivée du premier ordre. L est la longueur (paramètre) du
pendule, g est l'accélération due à la gravité (constante), m est la masse (paramètre) du pendule, x et y sont les
coordonnées dans l'espace bidimensionnel et F est la force. . Notez que Modelica utilise :

L'étape suivante consiste à créer les diagrammes Paramétriques qui relient les équations entre elles. Comme indiqué
précédemment dans le Guide, ces diagrammes constituent un type spécialisé de diagramme Bloc internes et contiennent
des instances de ConstraintBlocks appelées ConstraintProperties qui exposent leurs paramètres, qui sont liés par des
connecteurs aux paramètres d'autres ConstraintProperties.

Spécification d'un artefact de configuration

L'artefact Simulation SysML est l'élément qui lie les éléments du modèle à la plateforme OpenModelica. Les éléments du
modèle exprimés dans SysML sous la forme de Blocks, ConstraintBlocks et leurs ConstraintProperties associés liés entre
eux sur diagrammes Paramétriques apparaissent dans la fenêtre Simulation et peuvent être configurés avec d'autres
paramètres pour piloter la simulation.
La première étape de la configuration de cette facilité consiste à créer un élément de configuration SysMLSim,
disponible à partir de la page Boîte à outils « Artifact », comme indiqué dans cette capture d'écran.

Enterprise Architect fait l'essentiel du gros du travail en ce qui concerne le remplissage de la fenêtre Configurer
Simulation SysML. L'ingénieur doit simplement sélectionner le Paquetage à l'aide de l'icône du panneau «
Configuration » de la fenêtre Simulation Artifact.

Enterprise Architect affichera la fenêtre de sélection Paquetage , et une fois le Paquetage sélectionné, le panneau «
Configuration » sera rempli avec les blocs, les blocs de contraintes et les types de valeur du modèle. À partir de ce point,
les valeurs peuvent être saisies pour divers paramètres ou des ensembles de données peuvent être définis. Les paramètres
de configuration de la simulation peuvent être saisis et la simulation est prête à exécuter .

Une fois les données saisies pour la simulation, y compris les valeurs Démarrer et d'arrêt et les formats de sortie, la
Simulation peut être exécuter en sélectionnant le bouton Résoudre comme indiqué sur cette illustration d'écran.

Décrire les objectifs des utilisateurs avec des cas

d'utilisation
Les cas d'utilisation ont été initialement conçus par Ivar Jacobson, un ingénieur électricien suédois qui a également été
un partisan important du développement du Unified Modeling Language (UML) . Les cas d'utilisation sont utilisés
comme méthode pour représenter les exigences fonctionnelles du point de vue des utilisateurs. On dit qu'ils sont axés sur
les objectifs, car le cas d'utilisation définit l'objectif que l'utilisateur tente d'atteindre lorsqu'il interagit avec le système.
Enterprise Architect prend entièrement supporte le développement de diagrammes de cas d'utilisation, mais prend
également entièrement supporte la modélisation et la gestion du texte de cas d'utilisation ; il dispose d'un outil unique et
hautement productif pour travailler avec des cas d'utilisation, appelé Scenario Builder.
Cet outil innovant permet non seulement de modéliser les cas d'utilisation à n'importe quel niveau de détail, mais crée
également automatiquement des modèles comportementaux qui permettent de visualiser et de relier les étapes détaillées
d'un cas d'utilisation et l'interaction entre l'acteur et le système à d'autres parties de le modèle.
Le cas d'utilisation est un proche cousin de la User Story, qui est utilisée dans un certain nombre de techniques de
développement de logiciels Agile. Le terme inventé à l’origine en suédois est plus naturellement traduit par Scénario
d’utilisation, qui fournit une explication plus convaincante de la méthode.

Exigences et cas d'utilisation

La technique du cas d'utilisation est fondamentalement très simple et a été conçue à l'origine pour garantir que les
exigences fonctionnelles soient rédigées du point de vue de l'utilisateur. Ce point de vue a contribué à garantir que les
systèmes déployés seraient adaptés à leur objectif et seraient acceptés par la diversité de la communauté d'utilisateurs. Il
existe cependant une grande quantité de littérature contradictoire et un tout aussi grand nombre de styles pour définir les
cas d’utilisation. Cela a conduit à la confusion et à l'incertitude et a eu tendance à atténuer la valeur que l'on peut tirer de
cette technique simple et efficace.
En génie logiciel, de nombreuses méthodes prescrivent l'utilisation de cas d'utilisation comme alternative au
développement Exigences , car le Unified Modeling Language (UML) n'inclut pas d'élément d'exigence formel. En
revanche, la plupart des méthodes Ingénierie Systèmes Modèles Basée utilisant SysML combinent l'application de Cas
d'Utilisation et Exigences . Cela est dû au fait que SysML définit à la fois un cas d'utilisation et un élément d'exigence
afin que ces deux éléments puissent être liés l'un à l'autre et compléter la spécification du système pour apporter de la
clarté et de la précision à la discipline importante de l'ingénierie et de la gestion des exigences.

Dans ces deux diagrammes le modélisateur a utilisé la relation « affiner » pour indiquer que le cas d'utilisation de
décélération de voiture affine ou ajoute des explications supplémentaires pour clarifier l'exigence d'efficacité du
maître-cylindre . Cela fournit un mécanisme permettant de retracer les composants au niveau de la mise en œuvre qui
sont connectés au cas d'utilisation jusqu'à l'exigence et, finalement, jusqu'à la partie prenante.

La fenêtre Traçabilité peut également être utilisée pour visualiser les connexions entre les éléments du modèle à
différents niveaux d'abstraction et pour voir la connexion d'un Bloc qui fait partie d'un assemblage de sous-système à
l'exigence qui a spécifié la fonctionnalité.

Les cas d'utilisation sont généralement utilisés pour affiner les exigences de haut niveau et pour exprimer la
communication et l'interaction entre l'utilisateur et le système.

Présentation Diagrammes de cas d'utilisation

Le diagramme de cas d'utilisation est un diagramme simple qui décrit visuellement les objectifs des utilisateurs
concernant le système ou une partie du système. Cela pourrait être paraphrasé par « la valeur que le système apporte aux
acteurs ». diagrammes de cas d'utilisation semblent assez simplistes, avec un petit nombre d'éléments :
· Sujet
· Acteurs
· Cas d'utilisation
Ceux-ci sont reliés par une série de relations.

Le Sujet ( bordure ) fournit un contexte pour la définition et représente un système ou une partie d'un système ; les
Acteurs se situent par définition en dehors du Sujet et les Cas d’Utilisation à l’intérieur. La relation Chemin
Communication traverse par définition le périmètre du Sujet car elle relie un Acteur à un Cas d’Utilisation. Encore une
fois, le nombre de relations est assez limité, mais chacune a une signification spécifique dans le diagramme .
· Voie Communication
· Prolonger (également avec Condition)
· Inclure
· Généralisation
Comme pour tous les éléments SysML, les éléments comportent à la fois un aspect graphique et textuel, et dans la
description des cas d'utilisation, l'accent est généralement mis davantage sur l'aspect textuel ou narratif.

N'importe quel nombre de diagrammes de cas d'utilisation peut être créé pour représenter l'interaction des utilisateurs
avec le système ou une partie d'un système. Il est important de comprendre que les cas d'utilisation sont destinés à décrire
la valeur que le système apporte à ses utilisateurs et qu'ils ne sont pas destinés à être décomposés par décomposition
fonctionnelle. Il s’agit sans aucun doute de l’erreur la plus courante commise par les modélistes débutants, ce qui
entraîne une atténuation des bénéfices profonds que l’on peut tirer de cette technique.
Le modèle de cas d'utilisation peut être agrémenté d'un mécanisme appelé 'structuration du Modèle de cas d'utilisation',
qui élimine les textes répétitifs, classe les acteurs et les cas d'utilisation et précise les points d'extension. Ce mécanisme
sera discuté plus loin dans ce chapitre. Pour plus d’informations, consultez la rubrique d’aide SysML Use Case Models .

Création d'un Diagramme de cas d'utilisation

Un diagramme de cas d'utilisation peut être créé à partir de plusieurs endroits de l' Interface Utilisateur en sélectionnant :
· Ruban de conception - Icône Ajouter Diagramme dans le panneau Diagramme
· Barre d'outils de la fenêtre Navigateur - Icône Nouveau Diagramme
· Menu contextuel de la fenêtre Navigateur - Ajouter Diagramme
Nous utiliserons le ruban Conception pour créer un diagramme de cas d'utilisation. Tout d'abord, sélectionnez
l'emplacement dans la fenêtre Navigateur où vous souhaitez que le diagramme de cas d'utilisation soit situé. Comme pour
tous diagrammes , il peut s'agir soit d'un Paquetage , soit d'un élément, mais il est courant d'insérer diagrammes de cas
d'utilisation dans un Paquetage . Une fois l'emplacement Paquetage sélectionné dans la fenêtre Navigateur , sélectionnez
:
Conception > Diagramme > Ajouter Diagramme

La sélection de cette option ouvrira la dialogue Nouveau Diagramme , vous permettant de nommer le diagramme ; le
nom est initialement par défaut le nom du Paquetage ou de l'élément qui contient le diagramme . Avec la perspective
SysML choisie et la version de SysML sélectionnée, une liste de diagrammes s'affichera vous permettant de choisir le
diagramme de cas d'utilisation. Cliquez sur le bouton OK pour créer un nouveau diagramme de cas d'utilisation à
l'emplacement sélectionné dans la fenêtre Navigateur . Le Diagramme Vue s'ouvrira, vous permettant de commencer à
ajouter des éléments et des connecteurs qui décrivent la valeur que le système fournira à ses utilisateurs. Enterprise
Architect affichera également les pages « Cas d'utilisation » de la boîte à outils Diagramme qui contiennent les éléments
et les relations définis par la spécification SysML pour être applicables à la construction de diagrammes de cas
d'utilisation. N'importe quel nombre d'autres pages de la boîte à outils peuvent être ouvertes, si nécessaire, en plus des
pages de la boîte à outils Éléments communs et Relations communes qui seront toujours disponibles.

Les éléments et connecteurs les plus importants utilisés avec le diagramme de cas d'utilisation sont :

Éléments
· Acteur - utilisé pour décrire le rôle qu'un utilisateur joue par rapport au système
· Cas d'utilisation - utilisé pour décrire la valeur qu'un système fournit à ses utilisateurs
· Bordure - utilisé pour montrer la portée des systèmes (généralement un par diagramme )

Connecteurs
· Chemin Communication – utilisé pour relier les acteurs aux cas d’utilisation
· Généraliser - utilisé entre deux acteurs ou entre deux cas d'utilisation
· Inclure - utilisé entre le cas d'utilisation pour réutiliser les étapes du scénario
· Étendre - utilisé pour embellir un cas d'utilisation avec des détails supplémentaires

Des éléments peuvent être ajoutés au diagramme en les faisant glisser et en les déposant depuis la boîte à outils vers le
Diagramme Vue . Il est considéré comme une bonne pratique de commencer par un élément Bordure , qui doit être
nommé de manière appropriée pour décrire le système, le sous-système ou l'entité modélisé par le diagramme de cas
d'utilisation. Laisser le nom vide ou lui donner un nom qui n'indique pas clairement au lecteur quel système ou partie de
système est modélisé peut conduire à une mauvaise interprétation du diagramme . Avec la Bordure ajoutée et
correctement dimensionnée dans le diagramme , des acteurs et des cas d'utilisation peuvent être ajoutés - Des acteurs
positionnés à l'extérieur de la Bordure et des cas d'utilisation à l'intérieur. L'étape suivante consiste à ajouter des relations
de chemin Communication entre les acteurs et les cas d'utilisation, définissant ainsi la valeur que les acteurs tirent du
système.
Une fois qu'un diagramme de base a été créé, et à mesure que la connaissance du domaine et des comportements du
système est révélée, il est possible de structurer ou d'embellir le diagramme en utilisant les relations supplémentaires
Inclure, Étendre et Généraliser. Le nouveau venu est mis en garde contre une utilisation trop libérale de ces relations, et
toute tentative de recourir à la décomposition fonctionnelle atténuerait la valeur du modèle de cas d'utilisation,
volontairement large dans sa description pour permettre aux parties prenantes d'avoir une vue d'ensemble des services
fournis par l'entreprise. système, sous-système ou entité modélisé.

Rencontrez le créateur de scénarios

Il existe une large gamme d'outils pour travailler avec des cas d'utilisation, mais aucun n'est plus important et utile que
Scenario Builder. Cet outil unique comble le fossé entre ce qui se faisait traditionnellement au sein des traitements de
texte ou des outils isolés qui séparent le diagramme de cas d'utilisation avec ses acteurs et cas d'utilisation, et les étapes
des scénarios.

Le générateur de scénarios fournit également un mécanisme permettant de générer automatiquement des modèles
comportementaux directement à partir des étapes du scénario, permettant ainsi aux éléments de l'architecture et de la
conception d'être liés aux étapes individuelles.

L'outil fournit toute une gamme d'options qui conviendront à tout processus de cas d'utilisation ou Exigences , allant de
ce que l'on appelle communément un processus de base dans lequel l'acteur et les cas d'utilisation sont nommés et le cas
d'utilisation reçoit une description, à un processus partiellement- processus habillé où le flux de base est terminé. Un
processus complet détaillera généralement toutes les étapes du flux de base et définira et détaillera les étapes des
scénarios alternatifs et d’exception. Pour plus d’informations, consultez la rubrique Scenario Builder .
De plus, un certain nombre de contraintes peuvent être ajoutées, telles que des pré-conditions, des post-conditions et des
invariants.

Structurer un Modèle de cas d'utilisation

Bien que le modèle de cas d'utilisation offre un haut niveau de visualisation et qu'un ingénieur système soit mis en garde
contre l'application d'une décomposition fonctionnelle, SysML fournit un certain nombre de mécanismes qui peuvent
aider à structurer un modèle de cas d'utilisation afin de garantir que des éléments discrets de fonctionnalités peuvent être
réutilisés. Ces mécanismes consistent en la relation de dépendance « include », de dépendance « extend » et de
généralisation.

Générer Diagrammes de comportement

Enterprise Architect dispose d'un outil de productivité utile qui permet de générer automatiquement diagrammes de
comportement à partir des spécifications de cas d'utilisation définies dans Scenario Builder. Cela fournit un moyen de
visualiser ces descriptions autrement textuelles. Il permet également d'établir des relations entre les étapes d'une
description de cas d'utilisation et d'autres éléments modélisation .

Rapport de cas d'utilisation

La création de la documentation des cas d'utilisation est traditionnellement un processus manuel et, comme les
documents de nombreux projets comptent des centaines de pages, leur production consomme de précieuses ressources de
projet. Ces documents fabriqués à la main deviennent difficiles à maintenir et restent isolés des autres parties du projet
telles que Exigences , Règles Métier et les Composants de la solution. Enterprise Architect dispose d'un outil
multifonctions appelé Scenario Builder qui permet au modélisateur de spécifier des cas d'utilisation et des scénarios à
l'intérieur du modèle et ceux-ci peuvent être automatiquement générés dans une documentation de haute qualité à l'aide
de gabarits intégrés. Il existe deux gabarits intégrés qui peuvent être utilisés pour générer un rapport de cas d'utilisation :
l'un documente le cas d'utilisation à un niveau récapitulatif et l'autre à un niveau détaillé.

Exemple de contenu d'un Rapport de cas d'utilisation

Le rapport détaillé du cas d'utilisation répertorie tous les détails du cas d'utilisation et les étapes détaillées, y compris les
chemins de base, les scénarios alternatifs et d'exception. D'autres informations, y compris Exigences internes, les
conditions préalables et postérieures et d'autres contraintes, seront également incluses dans le rapport. Si un diagramme
Comportementale tel qu'un diagramme d'activité a été créé automatiquement, ce diagramme sera également affiché dans
le rapport.

Utiliser des blocs pour Modèle une structure et des

contraintes
Les constructions et expressions du langage dans SysML, comme dans nos langages naturels, peuvent être divisées en
types structurels et comportementaux. Dans des langues comme l'anglais, l'allemand ou le japonais, les noms décrivent la
structure et les verbes décrivent le comportement. Les phrases contiennent généralement une combinaison de noms et de
verbes qui mettent en lumière certains aspects du monde du locuteur. Le SysML a une division similaire, avec des
éléments qui décrivent la structure et d'autres éléments qui décrivent le comportement. Dans SysML, les éléments
structurels (noms) sont décrits à l'aide d'un Bloc . Lorsque les ingénieurs créent diagrammes , ils comportent souvent un
mélange d'éléments de comportement ou de structure et décrivent un aspect particulier d'un système, mettant ainsi en
lumière certains aspects du système modélisé.
Le Bloc est l'unité fondamentale de la structure du système ; il peut être utilisé pour décrire un système entier, un
sous-système, un composant, un élément qui traverse un système, une contrainte ou des entités qui résident en dehors
d'un système. De la même manière que nos langages naturels, un Bloc peut représenter quelque chose d'abstrait, de
logique ou de physique. Il s'agit d'un concept important, et les rédacteurs et les lecteurs de SysML doivent être clairs
quant à l'intention de la représentation. Par exemple, dans une architecture logique, il existe généralement des blocs
représentant des idées ou des conceptions conceptuelles qui, au moment de la conception détaillée et de la construction,
peuvent être réalisées par des composants physiques et tangibles. Un architecte système peut définir un Bloc appelé
sous-système de détection de collision qui est l'expression d'un composant logique du système qui pourrait, lors de la
phase de conception détaillée, être en partie réalisé par un ensemble d'émetteurs radar et laser, de détecteurs et de
caméras.

Un certain nombre de nos langues naturelles ont un terme grammatical appelé classificateurs, qui regroupe les éléments
(noms) d'un lexique en classes d'éléments partageant des caractéristiques et des comportements communs. Ce même
principe s'applique aux blocs, qui sont essentiellement un type de classificateur qui regroupe une collection d'instances
partageant les mêmes fonctionnalités structurelles et comportementales. Les instances d'un Bloc peuvent être modélisées
de manière générique ou se voir attribuer des valeurs précises, comme le volume d'essence contenu dans un réservoir de
carburant à un moment particulier d'un trajet ou au moment d'un accident.

Dans le diagramme du réservoir de carburant, la voiture est modélisée comme un niveau de classificateur ( Bloc ), où le
modèle décrit un véhicule générique et représente le fait qu'un véhicule peut avoir un, ou un maximum de deux,
réservoirs de carburant. Ce diagramme d'instances de réservoir de carburant décrit cependant un véhicule particulier doté
de deux réservoirs de carburant ayant des capacités et des volumes de réserve différents.

Un Bloc définit une collection (ou un ensemble) de fonctionnalités utilisées pour décrire un système, un sous-système, un
composant ou tout autre élément d'intérêt. Ces fonctionnalités peuvent inclure fonctionnalités à la fois structurelles et
comportementales, telles que des propriétés, des opérations et des réceptions, pour représenter l'état du système et le
comportement que le système est capable de présenter.
Enterprise Architect dispose d'un ensemble d'outils qui aident l'ingénieur système à travailler avec des blocs et à
visualiser la structure et le comportement de ces éléments très importants dans la définition d'un système. Ces facilités
comprennent :
· Interrompre lorsqu'une Variable Change de Valeur , qui décrit les Blocs, leurs fonctionnalités , les points
d'interaction et les relations structurelles
· Diagramme Interne de Bloc , qui capture la structure interne d'un Bloc en termes de propriétés et de connecteurs
entre propriétés
Ce Diagramme Interne de Bloc montre comment un certain nombre de sous-systèmes coopèrent pour créer la structure
du véhicule. Par exemple, le sous-système d'éclairage a une connexion avec le sous-système intérieur qui à son tour a une
connexion avec le sous-système carrosserie.

Certaines relations ont été supprimées dans le diagramme ; par exemple, le sous-système d'alimentation aurait
généralement une connexion au sous-système d'éclairage. Ce point est important, car les nouveaux venus dans SysML et
Enterprise Architect pensent souvent que chaque relation définie doit être affichée dans un diagramme . Bien que cette
affirmation semble vraie, il est important de se rappeler qu'un modéliste, comme un caricaturiste créant une caricature,
laisse souvent des détails en dehors des illustrations pour concentrer l'attention du spectateur sur d'autres éléments et
connecteurs subjectivement plus importants.
Cette capture d'écran montre comment un ingénieur peut définir les relations visibles pour un diagramme .

Si un connecteur n'est pas coché dans cette dialogue , il ne sera pas affiché dans le diagramme courant. Il peut cependant
être visible dans d'autres diagrammes où les éléments connectés sont affichés. Cela peut être défini à partir de l'option de
ruban ' Disposition > Diagramme > Apparence > Visibilité > Définir Relations visibles '.
Quels que soient les connecteurs affichés dans un diagramme , un modélisateur peut toujours afficher tous les
connecteurs d'un élément en sélectionnant l'élément dans le diagramme et en affichant la fenêtre Traçabilité. Dans cette
capture d'écran, le sous-système d'alimentation a été sélectionné, et même si le connecteur entre le sous-système
d'alimentation et le sous-système d'éclairage a été défini sur « non visible » dans le diagramme , la relation est visible
dans la fenêtre Traçabilité.

Les fonctionnalités d'un Bloc sont soit structurelles, soit comportementales.

Les fonctionnalités structurelles sont de trois sortes :
· Parties - qui décrivent la composition d'un Bloc ; par exemple, le châssis d'un véhicule est composé de deux essieux
et de quatre ensembles de roues
· Références - qui décrivent la relation du Bloc avec d'autres Blocs (y compris lui-même) ; par exemple, qu'un train
métropolitain a une relation avec une gare et un système de câblage aérien
· Valeurs - qui décrivent les aspects quantifiables d'un Bloc ; par exemple, des éléments tels que les dimensions, la
température et la luminosité
Les fonctionnalités Comportementale incluent :
· Opérations - représentant généralement des requêtes synchrones
· Réceptions - représentant les requêtes asynchrones à partir d'un signal

Démarrage avec blocs

Les concepteurs d' Enterprise Architect ont créé une grande flexibilité pour les ingénieurs système et d'autres disciplines,
reconnaissant que les membres de l'équipe remplissent souvent divers rôles et doivent efficacement changer de chapeau
plusieurs fois au cours d'un projet, voire au cours d'une même journée. Perspectives et les espaces de travail offrent à un
ingénieur système un moyen pratique et efficace de changer efficacement de rôle sans avoir besoin de lancer un autre
outil.

Définir la perspective et l'espace de travail

Les ingénieurs système qui travaillent avec l'outil depuis un certain temps auront sélectionné une perspective dans
l'ensemble de perspectives de l' Ingénierie des Systèmes ; il peut généralement s'agir de la perspective SysML, leur
donnant accès à tous les motifs et pages de la boîte à outils pour créer l'un des diagrammes SysML, y compris les
diagrammes de définition Bloc et Bloc interne.

Comme expliqué dans la rubrique d'introduction, les espaces de travail peuvent être définis pour faciliter modélisation
d'un type particulier ; dans le cas des diagrammes de définition Bloc , n'importe lequel des espaces de travail contenus
dans l'ensemble d'espaces de travail de base sera utile pour modélisation , notamment :
· Diagramme de base
· Modélisation de base
· Défaut
Un ingénieur qui travaille au niveau d'un projet peut également trouver utiles certains espaces de travail de construction,
notamment :
· Feuilles de Route
· Kanban
· Publication de documents
· Révisions et discussions

Création d'une définition Bloc ou Diagrammes Bloc internes

Il existe deux diagrammes que vous créerez généralement lorsque vous travaillez avec des blocs :
· diagramme de définition Bloc (BDD) - utilisé pour montrer les relations structurelles entre les blocs, y compris les
hiérarchies des parties et du type, et les connexions de référence avec d'autres blocs.
· diagramme Bloc interne (IBD) - utilisé pour montrer comment les propriétés de la pièce sont connectées directement
ou via des points d'interaction tels que les ports et les interfaces
Nous discuterons du diagramme de définition Bloc dans ce chapitre du guide ; dans le chapitre suivant, nous discuterons
du diagramme Bloc interne, qui démontrera comment les blocs peuvent être utilisés dans un contexte donné.

Diagramme Interne de Bloc - Setting Context

L'un des diagrammes les plus importants à créer au début d'une initiative est un diagramme de contexte, qui décrit le
produit ou le service modélisé dans le contexte de son environnement ou de son domaine. Cela aide un visualiseur de
modèle à avoir une image claire et à comprendre comment le produit se situe dans un ou plusieurs environnements dans
lesquels il devra fonctionner. Cela donne également une indication précoce de ce qui est dans la portée et hors de la
portée du projet. Les éléments du diagramme ont été marqués « Externes » (en utilisant un stéréotype), indiquant qu'ils
font partie de l'environnement ou du contexte du produit ou du service.
Des images ont été utilisées pour adoucir le diagramme , le rendant plus attrayant pour un large éventail de parties
prenantes, y compris un public commercial et non technique.
Ce diagramme Bloc interne montre le SUV hybride dans le contexte d'un environnement urbain typique. Il est envisagé
de créer au moins un autre diagramme montrant un environnement hors route où les routes seraient remplacées par des
chemins de terre et des rivières, et les bâtiments par des montagnes et des arbres.

Modélisation des contraintes sous forme de blocs

L'analyse technique exige que l'ingénieur exécute diverses fonctions, notamment la construction de modèles de
performance et de fiabilité, l'analyse des compromis, l'analyse des alternatives et les études commerciales. Ces analyses
nécessitent souvent l'utilisation d'expressions et d'équations mathématiques utilisées pour contraindre les éléments d'une
analyse. SysML fournit un mécanisme de langage sous la forme d'un ConstraintBlock utilisé pour modéliser
graphiquement les équations. Il s'agit d'un mécanisme utile qui permet d'articuler l'expression avec ses paramètres et
leurs types. Les équations modélisées peuvent ensuite être réutilisées dans un certain nombre de contextes différents,
permettant à un ingénieur de définir la formule de la deuxième loi du mouvement de Newton {F=m*a} ou la définition
de Carnot, aboutissant à un théorème fondamental de la thermodynamique {p= W/ t = (mg)h/t}. L'un des résultats utiles
de modélisation graphique de ces équations est qu'elles peuvent être liées à d'autres éléments du modèle tels que
Exigences d'une partie prenante, les objectifs de mission et les éléments de niveau inférieur tels que les blocs et les
artefacts de mise en œuvre.
Enterprise Architect permet de modéliser ces ConstraintBlocks puis de les réutiliser comme Constraint Propriétés sur
diagrammes Paramétriques . Les définitions de contraintes peuvent être regroupées dans des bibliothèques et non
seulement utilisées dans l'initiative actuelle, mais réutilisées dans plusieurs projets et initiatives. Dans un sujet ultérieur,
nous verrons comment les contraintes peuvent être intégrées dans un réseau d'équations et utilisées sur diagrammes
Paramétriques pour évaluer des alternatives et effectuer des analyses de compromis et d'alternatives. La précision et
l'excellence technique de l'outil garantiront que les équations ainsi définies pourront être créées, maintenues et utilisées
avec rigueur.

Présentation Diagrammes de définition Bloc

Les blocs fournissent un concept unificateur pour décrire la structure d'un élément ou d'un système, notamment :

· Systèmes
· Matériel
· Logiciel
· Données
· Procédures
· Facilités
· Personnes
Les blocs peuvent avoir plusieurs compartiments standards qui peuvent être rendus visibles sur diagrammes pour décrire
les caractéristiques du Bloc , notamment :

· Propriétés (pièces, références, valeurs, ports)

· Opérations
· Contraintes
· Allocations depuis/vers d'autres éléments du modèle (tels que les activités)
· Exigences que le Bloc satisfait
· Compartiments définis par l'utilisateur
N'importe lequel des compartiments peut être supprimé. Aucune ligne de séparation n'est tracée pour un compartiment
manquant. Si un compartiment est supprimé, aucune déduction ne peut être tirée sur la présence ou l’absence d’éléments
à l’intérieur. Dans ce diagramme un pendule a été modélisé et un certain nombre de compartiments ont été rendus
visibles en vue de créer une simulation paramétrique.

Des compartiments supplémentaires peuvent être fournis en tant qu'extension d'outil pour afficher d'autres propriétés de
modèle prédéfinies ou définies par l'utilisateur (par exemple, pour afficher les règles métier, les responsabilités, les
variations, les événements gérés, déclenchés, etc.).
Chaque Bloc doit avoir un nom non nul et unique dans son espace de noms. La portée d'un nom est son Paquetage
contenant et les autres Paquetages qui peuvent voir le Paquetage contenant .

Création d'un Interrompre lorsqu'une Variable Change de Valeur

Un diagramme de définition Bloc peut être créé à partir de plusieurs endroits dans l' Interface Utilisateur en utilisant l'une
de ces options :
· Ruban de conception - Icône Ajouter Diagramme sur le panneau Diagramme
· Barre d'outils de la fenêtre Navigateur - Icône Nouveau Diagramme
· Fenêtre Navigateur Menu Contexte - Ajouter Diagramme
Nous utiliserons le ruban Conception pour créer un diagramme de définition Bloc . Tout d'abord, sélectionnez
l'emplacement dans la fenêtre Navigateur où vous souhaitez que le diagramme de définition Bloc soit situé. Comme pour
tous diagrammes , cela peut se trouver sous un Paquetage ou un élément, mais il est courant d'insérer diagrammes de
définition Bloc dans un Paquetage . Une fois l'emplacement sélectionné dans la fenêtre Navigateur , sélectionnez l'option
du ruban :
Conception > Diagramme > Ajouter Diagramme

La sélection de cette option ouvrira la dialogue « Nouveau Diagramme », vous permettant de nommer le diagramme . Le
nom par défaut est initialement le nom du Paquetage ou de l'élément qui contient le diagramme . Avec la perspective
SysML choisie et la version de SysML sélectionnée, une liste de diagrammes sera affichée ; sélectionnez le diagramme

de définition Bloc et cliquez sur le bouton OK . Un nouveau diagramme de définition Bloc sera créé à l'emplacement
sélectionné dans la fenêtre Navigateur . Le Diagramme Vue s'ouvrira, vous permettant de commencer à ajouter des
éléments et des connecteurs qui décrivent les blocs et d'autres éléments structurels importants tels que les ports, les
interfaces et les types de valeur. Enterprise Architect affichera également les pages « Définition Bloc » de la boîte à
outils Diagramme , qui contiennent les éléments et les relations définis par la spécification SysML applicables à la
construction diagrammes de définition Bloc . N'importe quel nombre d'autres pages de la boîte à outils peuvent être
ouvertes si nécessaire, en plus des pages « Éléments communs » et « Relations communes » qui seront toujours
disponibles.

Les éléments et connecteurs les plus importants utilisés avec le diagramme de définition Bloc sont :

Éléments
· Bloc
· Bloc de contraintes
· Type de valeur
· Propriété
· Unité
· Quantité Type
· Port proxy
· Port complet
Connecteurs
· Association de référence
· Association de pièces
· Association partagée
· Généralisation
· Dépendance
· Flux Item

Des éléments peuvent être ajoutés au diagramme en les glissant-déposant depuis la boîte à outils vers le Diagramme Vue
. Pour plus d'informations, consultez l' Block Definition Diagrams (BDDs) Rubrique d'aide.

Création d'un élément Bloc

Les éléments Bloc , comme tout autre type d'élément, peuvent être créés à l'aide de l'option "Ajouter un élément" dans le
menu contextuel Paquetage , ou en utilisant la page "Définition Bloc SysML" de la boîte à outils Diagramme pour placer
un Bloc sur un diagramme de définition Bloc . (BDD).

Il est courant que des blocs apparaissent sur plusieurs BDD, où chaque diagramme est conçu pour répondre aux
préoccupations d'une partie prenante ou d'un groupe de parties prenantes particulier. Enterprise Architect dispose d'un
large éventail d'options d'affichage à la fois au niveau des blocs individuels (ou de n'importe quel élément) ou au niveau
du diagramme . Ceux-ci peuvent être utilisés pour décider, par exemple, quels compartiments afficher ou même quelles
fonctionnalités afficher pour des éléments individuels. Il existe également une large gamme de paramètres génériques
d'éléments et diagramme pour styliser à la fois l'élément et le diagramme . Par exemple, il est possible de définir les
couleurs des éléments, y compris le remplissage, les bordures et le texte, ou de modifier l'apparence d'un élément en
appliquant une image graphique qui traduit mieux la fonction du Bloc . Dans cet exemple, un modéliste a décidé
d'utiliser une image alternative pour un robot de soudage par points afin de transmettre plus clairement l'automatisation
en cours sur la ligne de production.

Les éléments structurels fondamentaux

Les blocs sont les unités modulaires fondamentales et discrètes de la description du système. Un Bloc définit un
ensemble de fonctionnalités utilisées pour définir un aspect d'un système ou d'un système lui-même. Les fonctionnalités
sont de deux types fondamentaux : fonctionnalités structurelles (en quoi consiste un Bloc ) et comportementales (ce qu'il
fait). Les relations d'un Bloc avec d'autres Blocs (y compris lui-même) et avec des éléments d'autres types aident à
décrire la structure d'un système, d'un sous-système ou d'un composant.
Les modélisateurs de systèmes utilisent Diagrammes de définition Bloc (BDD) pour définir la structure des blocs et
Diagrammes Bloc internes (IBD) pour décrire leur utilisation.
Ces diagrammes peuvent être créés à partir de la dialogue ' Nouveau Diagramme ', accessible depuis la barre d'outils de
la fenêtre Navigateur .

Modélisation Fonctionnalités Structurelles

Les blocs sont généralement définis à l'aide d'une série de fonctionnalités structurelles. Ce sont les propriétés du Bloc et
définissent la nature du Bloc . Par exemple, une locomotive de train (matériel roulant) aura des propriétés telles que la
classe de moteur, le numéro d'identification, le nombre d'ensembles de roues, la force motrice, les moteurs et une gamme
d'autres propriétés. Un point important à retenir est que le Bloc est un classificateur qui décrit un ensemble de Moteurs.
La locomotive à l'avant du train dans lequel vous montez à bord pour vos vacances d'été est une instance de locomotive
et elle aura une classe particulière, par exemple la classe OSE 660, et un identifiant SM-09873, et 8 ensembles de roues.
Enterprise Architect supporte trois types de fonctionnalité structurelles de base et chacune est importante pour
modélisation de différents aspects de la structure d'un Bloc . Nous examinerons chacun d’eux dans ces sections.
· Pièces - un bloc est composé de pièces
· Références - se référer aux fonctionnalités d'autres blocs
· Valeurs - décrire les quantités
Ce diagramme montre les trois types de fonctionnalité structurelles.

Le système de freinage est composé d'un certain nombre de pièces, dont deux sont représentées sur ce diagramme .
L'association des pièces a été utilisée pour indiquer que le maître-cylindre et les cylindres de roue sont des constituants
fondamentaux du système de freinage. Une association de référence a été utilisée pour montrer à la fois une relation entre
les deux types de cylindres et également entre les cylindres et le liquide de frein. Les valeurs qui ont été saisies en tant
qu'attributs sont affichées avec les types de valeur qui les accompagnent ; par exemple, Volume a un Type de valeur L,
qui est le symbole de la dimension du volume dont l'unité SI est le litre.

Blocs composés de pièces

Une partie est une Fonctionnalité structurelle d'un Bloc et forme l'une des relations les plus fortes entre un Bloc et ses
propriétés. Il est important de comprendre qu'une instance d'un Bloc peut avoir plusieurs instances d'une partie ; par
exemple, un camion peut avoir plusieurs ensembles de roues et - selon la taille et le type du camion - ce nombre peut être
aussi bas que 2 ou aussi élevé que 10. Ces configurations possibles peuvent être spécifiées dans la définition du Bloc et
de ses parties, qui sont formellement connus sous le nom de multiplicités - le nombre inférieur est appelé limite
inférieure et le nombre supérieur comme limite supérieure. Une Part sera généralement typée par un autre Bloc , ainsi
dans l'exemple le type de la Part sera un autre Bloc nommé 'Wheel Assembly', qui comprendra généralement lui-même
un essieu et deux ensembles de roues. Ainsi chaque Partie sera définie dans le Bloc avec un nom, un type et une
multiplicité. L'outil permet de créer la relation de composition des pièces de plusieurs manières, mais la méthode la plus
immédiate consiste peut-être à faire glisser à la fois le Bloc de châssis (l'ensemble) et le Bloc d'assemblage de roues (la
pièce) sur le diagramme , puis à utiliser le Quick Linker pour faire glisser de la pièce ( Whe Assembly ) vers l'ensemble (
Chassis ).

Faire glisser de l' object source vers la cible affichera un menu de connecteurs possibles, et l'ingénieur choisira le
connecteur Composition vers l'ensemble . Le résultat sera une relation avec le marqueur en forme de diamant à
l'extrémité du châssis de la ligne, indiquant qu'il s'agit du tout et que l'élément à l'extrémité de l' assemblage de roues est
la pièce.

Les propriétés du connecteur vous permettront de définir le rôle source et les multiplicités qui, comme indiqué, précisent
le nom et le nombre possible de pièces pour chaque instance d'un châssis .

Dans le diagramme le modélisateur a expressément défini les parties en utilisant l'association de parties, disponible dans
la boîte à outils SysML Bloc Definition.
Dans ce diagramme le modélisateur a utilisé le compartiment Pièces du Bloc propriétaire pour afficher les pièces
appartenant au Bloc châssis.

Le compartiment Pièces s'affichera par défaut, mais sa visibilité peut être contrôlée au niveau diagramme à l'aide des
Propriétés diagramme , ou au niveau d'un élément individuel à l'aide de l'option « Visibilité du compartiment » de
l'élément dans le menu contextuel de l'élément. La définition de la visibilité au niveau du diagramme aura pour
conséquence que tous les éléments du diagramme seront conformes à la visibilité spécifiée - affichés ou non comme

spécifié - tandis que la définition au niveau de l'élément n'affectera que l'élément sélectionné.

Les éléments du référentiel seront mis à jour qu'ils soient édités dans le diagramme ou dans le Navigateur ou dans toute
autre fenêtre. Dans l'exemple, l'ingénieur a créé les pièces dans le diagramme en faisant glisser une association de pièces
depuis la boîte à outils ; en réponse à cela, Enterprise Architect crée trois nouvelles pièces, qui sont placées sous le nœud
Châssis dans le Navigateur , comme indiqué dans cette capture d'écran.

L'association partielle est le type de relation d'association le plus fort - le continuum de force du plus faible au plus fort
étant :
1. Association de référence
2. Association partagée
3. Association de pièces
Nous explorerons les autres relations dans les sections suivantes de ce guide.

Références à d'autres blocs

Comme indiqué précédemment, l'association de parties est le type de relation le plus fort dans le SysML et implique un
sentiment de responsabilité de la part de l'ensemble :

· Il est responsable de la durée de vie des pièces qui le composent.

· Une pièce ne peut participer à une composition de pièce qu'avec un seul bloc
La deuxième condition signifie que la multiplicité à la fin d'une composition de partie est toujours 1..1, ce qui peut être
abrégé en 1.

Il existe cependant une autre relation, l'association de référence (ou référence en abrégé) qui peut être utilisée pour
spécifier des relations entre des blocs indépendamment de la composition ou de la notion selon laquelle un bloc fait
partie d'un autre. Cela constitue un mécanisme très utile pour créer des relations entre des blocs faisant partie de
différentes hiérarchies de pièces ou entre deux blocs quelconques liés l'un à l'autre. Par exemple, le maître-cylindre et les
cylindres de roue ont tous deux une relation avec le liquide de frein utilisé pour remplir leurs réservoirs. Le cylindre de
roue pourrait à son tour avoir une relation avec un mécanicien qui vérifie périodiquement le cylindre pour déceler des
fuites susceptibles de compromettre l'efficacité du système de freinage. `

Valeurs utilisées pour décrire les quantités

Les blocs peuvent avoir des propriétés avec un certain type de valeur quantifiable ; par exemple, un moteur a une
puissance, un réservoir a un volume, une automobile a une couleur, un wagon a un certain nombre de bogies. Les types
peuvent être un type primitif défini comme Number, Integer , Real, Complex, Boolean ou String , comme illustré dans ce
diagramme .

Un ingénieur, une équipe ou une communauté de pratique peut également définir un certain nombre de types de valeur
qui peuvent être simples ou structurés. Ceux-ci peuvent être basés sur n'importe quel nombre de systèmes d'unités, tels
que le Système international d'unités (SI). Un ingénieur automobile qui conçoit un système de freinage peut se retrouver
à utiliser un certain nombre de types de valeurs SI standard et un certain nombre de types dérivés, ainsi que d'autres

valeurs non définies dans le cadre de cette norme. Ce diagramme illustre comment ces valeurs peuvent être définies, à
l'aide de l'élément Value Type disponible dans la boîte à outils de définition Bloc SysML.

Le Type de valeur a deux propriétés définies : la quantitéKind et l'unité. Ceux-ci peuvent également être modélisés dans
Enterprise Architect et donner de la rigueur à l'application du Value Type . Un ingénieur saura que le type est basé sur
une quantité (dimension) et une unité définie. Ce diagramme montre ces éléments pour le Type de valeur (viscosité).

Modélisation Comportementale Fonctionnalités

Lorsqu'un système est en fonctionnement, les instances des blocs qui ont été définis dans le cadre de l'architecture et de
la conception détaillée sont instanciées. À ce moment-là, si un Bloc a un comportement de classificateur défini, ce
comportement commencera généralement et continuera à fonctionner jusqu'à ce que le Bloc soit détruit. Ainsi, dans
l'exemple de notre système de parking, lorsque le système aura été activé, le lecteur de carte commencera à fonctionner
et son comportement principal entrera en vigueur. De plus, un Bloc (bien que fondamentalement de nature structurelle)
possède fonctionnalités comportementales qui seront appelées à réaliser des travaux. En résumé, il existe deux
définitions fondamentales du comportement qui sont définies dans le contexte d'un Bloc , à savoir :
· Comportement du classificateur - le comportement natif qui est initié lorsqu'un Bloc est instancié
· Fonctionnalités de comportement - ce sont les opérations et les réceptions (et leurs signaux associés)
Nous examinerons ces différents comportements dans les prochaines sections du Guide, mais il est important de
comprendre qu'ils fonctionneront à l'unisson, coordonnés par des interactions système qui garantiront que les opérations
sont appelées en séquence et que les signaux sont reçus et exécutés. par les Réceptions.

Comportement du classificateur de blocs

Un Bloc a le potentiel de faire du travail, mais en soi, il est une entité quelque peu latente et doit être mis en action par un
certain type d'appel à ses opérations ou par la réception d'un signal, d'un changement d'état ou d'un autre déclencheur
comportemental. Un Bloc a un concept de son comportement natif ou classificateur, comme on l'appelle formellement.
Ce diagramme montre un Bloc dans la fenêtre Navigateur qui a une Activity imbriquée qui sera définie comme le
comportement du classificateur pour le Bloc .

Pour sélectionner ce comportement pour le comportement du classificateur, ouvrez la fenêtre Propriétés et modifiez la
propriété Comportement du classificateur en sélectionnant l'icône [...] et en localisant le comportement (activité)
approprié comme indiqué dans cette illustration.

Les opérations comme Fonctionnalités Comportementale

Les blocs peuvent définir les opérations essentiellement comme les « muscles » du Bloc , car ce sont les opérations qui

effectuent la majeure partie du travail requis du système. Dans Enterprise Architect un ingénieur peut accéder aux
opérations à partir d'un certain nombre de points dans l'interface utilisateur, mais tous ces points ouvriront la fenêtre
Fonctionnalités , qui répertorie les opérations sur l'onglet 'Opérations' comme indiqué ici :

La fenêtre Fonctionnalités est utile comme résumé de toutes les fonctionnalités structurelles et comportementales, y
compris les pièces et les points d'interaction appartenant au Bloc . Le moyen le plus simple de créer une opération est de
sélectionner le Bloc dans un diagramme ou dans la fenêtre Navigateur et de cliquer sur l'élément du ruban :
Conception > Elément > Editeur > Fonctionnalités > Opérations

Les opérations sont simplement créées en sélectionnant l'onglet « Opérations » et en ajoutant le nom et d'autres détails
dans une ligne de la fenêtre. N'importe quel nombre d'opérations peut être créé, et chaque opération peut définir
n'importe quel nombre de paramètres, qui spécifient les entrées et sorties de l'opération. Leur importance sera discutée
plus loin dans cette section lorsque nous décrirons la relation entre les paramètres d'activité et Pins Action . Les
opérations peuvent également être affichées dans un diagramme , seules ou avec d'autres fonctionnalités , dont chaque
type est affiché dans un compartiment séparé de l'élément parent.

Il existe un large éventail d'options qui régissent la façon dont les opérations sont affichées, y compris la possibilité de ne

pas afficher l'intégralité du compartiment ou d'afficher uniquement des opérations particulières en supprimant les autres
de l'affichage.

Cela entraînera le masquage des opérations sélectionnées sur le diagramme , ce qui est un dispositif de présentation très
utile car il aide un ingénieur à créer un diagramme axé sur un aspect particulier du Bloc , en supprimant ou en cachant le
contenu non pertinent et distrayant. Ce fragment diagramme montre le résultat des opérations de suppression :

La même chose peut être faite pour les attributs au niveau d'un élément, et une fonction similaire est disponible pour
supprimer des opérations, des attributs et Valeur Étiquetés particuliers au niveau d'un diagramme . Un ingénieur peut
utiliser la fonction au niveau du diagramme lorsqu'une opération particulière apparaît sur plusieurs blocs et qu'il souhaite
la supprimer pour chaque élément du diagramme .

Les opérations peuvent être invoquées dans deux modes, de manière synchrone ou asynchrone, et peuvent être lancées de
différentes manières en fonction du type de comportement qui orchestre le comportement du système, notamment :
· Une Action d’Opération d’Appel (invocation d’une Activité)

· Un message dans le cadre d'une interaction ( diagramme Séquence )

· Une Statemachine
Cela signifie que l'opération peut être visualisée dans une gamme de diagrammes SysML et apparaîtra différemment
selon les contextes. Par exemple, dans un diagramme Séquence où les messages sont envoyés entre des instances de
Blocks ou d'autres classificateurs, l'opération apparaîtra comme une annotation à l'un des messages entrants du Bloc pour
montrer que l'opération sera initialisée à la suite du message. Enterprise Architect permet à un ingénieur d'accéder à la
liste des opérations du Bloc directement à partir de ce diagramme et permettra également de créer des opérations
directement à partir du diagramme .

Dans le cas de l' Action d'opération d'appel, les Pins de l'élément doivent être alignées par type et par nom sur les
paramètres de l'opération appelée ; Enterprise Architect vous aide à visualiser cette cartographie sur un diagramme , en
utilisant la facilité 'Lien vers Fonctionnalité '.

Les réceptions comme Fonctionnalités Comportementale

Les réceptions sont une autre fonctionnalité comportementale d'un Bloc mais, contrairement à une opération, les
réceptions ne peuvent être appelées que de manière asynchrone. Les réceptions fonctionnent également différemment des
opérations dans la mesure où un appel d'opération identifie spécifiquement une opération à invoquer, tandis que la
réception d'une instance d'un signal est considérée comme une demande de réception de l' object récepteur faisant
référence à ce signal ou à tout signal direct ou indirect. sa généralisation. De cette manière, il existe un niveau
d'indirection entre l'élément appelant et la réception. Une Réception possède des paramètres correspondant aux attributs
du Signal référencé par la Réception, et ceux-ci sont considérés comme des paramètres 'in' de la Réception.
La manière la plus simple de créer une Réception est de cliquer sur le Bloc dans un diagramme ou dans la fenêtre
Navigateur et de sélectionner l'élément du ruban 'Conception > Elément > Editeur > Réceptions'.

Pour créer une nouvelle réception, vous devez d'abord avoir créé le signal approprié auquel associer la réception.
Lorsque vous créez la réception, vous serez invité à localiser le signal approprié dans la fenêtre Navigateur , comme
indiqué ici :

Les réceptions, comme les opérations, peuvent être affichées dans un compartiment spécialisé dans un Bloc sur un
diagramme . Il est possible de personnaliser l'affichage et de supprimer toutes les réceptions ou de configurer quelles
réceptions particulières sont affichées. Dans cette capture d'écran, l'ingénieur a décidé de rendre visibles toutes les
réceptions, mais chaque diagramme et chaque Bloc au sein d'un diagramme peuvent être configurés différemment.

Autres Relations Bloc

Les blocs sont les éléments structurels clés du SysML et peuvent participer à diverses relations, dont certaines ont été
abordées dans les sections précédentes du Guide alors que nous parlions des associations. Il existe un certain nombre
d'autres relations qui peuvent être utilisées lors de la définition des blocs.

Généralisation d'une relation familiale

Dans une section précédente, nous avons parlé de l'association partielle comme étant le type de relation d'association le
plus fort, mais il existe une autre relation - la généralisation - qui est également très forte et est essentiellement utilisée
pour modéliser le fait que les blocs (et autres classificateurs) appartiennent au même famille. Le mot « classificateur »
vient de nos langues naturelles, comme le chinois et le thaï, qui ont une manière abstraite de classer ou de regrouper des
classes de noms ayant des caractéristiques similaires ; par exemple, une ceinture et une route sont des objets longs et
minces, alors qu'une baie et une balle sont des objets round . De même avec SysML, la relation de généralisation est
utilisée pour classer les choses et la structure peut avoir une profondeur arbitraire. À bien des égards, il est plus naturel
pour les ingénieurs d’interpréter la relation à l’envers et de dire que quelque chose est une version spécialisée de quelque
chose.

Enterprise Architect permet à un ingénieur de créer ces hiérarchies de classification pour les blocs, les types de valeur,
les signaux, les interfaces, les activités et plus encore. Un diagramme contient généralement une seule famille.

La relation peut être établie en sélectionnant d'abord l'icône « Généralisation » dans la boîte à outils, puis en effectuant

un glisser-déposer de l'élément le plus spécialisé vers l'élément le plus généralisé. Alternativement, cela peut être fait en
utilisant Quick Linker .

Lorsqu'un Bloc participe à une hiérarchie de généralisation et possède un certain nombre de spécialisations, les
connecteurs émanant du Bloc peuvent devenir désordonnés. Enterprise Architect fournit un mécanisme permettant de
modifier le style de ligne en l'un des nombreux styles, mais le style le plus utile est probablement le style Arbre orienté
verticalement, qui regroupe les têtes de la relation et permet d'aligner leurs queues en parallèle. .

L'un des mécanismes linguistiques utiles résultant de la généralisation est que les éléments spécialisés héritent des
fonctionnalités structurelles et comportementales de l'élément généralisé. Jusqu'à présent, dans les exemples diagrammes
l'ingénieur a choisi de ne pas afficher ces fonctionnalités héritées, mais elles peuvent être configurées pour être affichées
à l'aide des sections compartiments de la feuille de propriétés de l'élément.

Le résultat sera que les Blocs spécialisés afficheront les attributs et opérations hérités du Bloc parent. Ceux-ci seront
affichés regroupés par nom du Bloc parent. Ce mécanisme est largement utilisé en génie logiciel mais est également utile
pour l'ingénieur système où le Bloc spécialisé hérite automatiquement des fonctionnalités de son parent du fait qu'il est
un « membre de la famille ». Tout comme dans une famille humaine, un Bloc (enfant) spécialisé peut outrepasser les
fonctionnalités structurelles ou comportementales héritées d'un parent.

Les blocs appartiennent à des familles sur la base de certains critères, et cela peut être modélisé à l'aide de l'ensemble de

généralisation, qui est un mécanisme utilisé pour définir la base d'appartenance à une famille.

Dépendance

La dépendance est une relation utile mais sémantiquement faible. Il s'agit du « pion » de la boîte à outils des ingénieurs
en matière de relations, souvent utilisé au début du processus modélisation lorsque les détails des relations entre les
éléments du système n'ont pas été analysés ou ne sont tout simplement pas connus. Il modélise le fait que l'élément
(Client) à la fin de la relation s'appuie d'une manière ou d'une autre sur l'élément (Fournisseur) à l'extrémité de la flèche
de la relation. On peut pardonner aux modélistes débutants d’établir cette relation dans le sens inverse, car on pense
souvent que, de manière anecdotique, le matériau passe du fournisseur au client. Une fois que la sémantique de la
relation est comprise et que l’on se rend compte que la relation ne dit rien sur la direction du flux, l’erreur ne sera pas
commise.
Il existe un certain nombre de types de dépendances, tous pris en charge par Enterprise Architect . Le connecteur peut
être créé en sélectionnant l'icône « Dépendance » dans la page « Relations Bloc SysML » de la boîte à outils, puis en
cliquant sur l'élément client (extrémité arrière) et en faisant glisser le curseur sur l'élément fournisseur (extrémité pointe
de flèche). Le connecteur peut également être créé à l'aide de la flèche Quick Linker située dans le coin supérieur droit
d'un élément diagramme sélectionné. Une fois la relation créée, un stéréotype peut être choisi dans la fenêtre Propriétés
du connecteur pour rendre la dépendance plus spécifique. Cette capture d'écran montre tous les stéréotypes disponibles,
dont certains sont utilisés entre différents types d'éléments autres que les blocs ; par exemple, Paquetages et Exigences .

Répartition entre les blocs et les activités

La relation d'Allocation peut être utilisée dans diverses circonstances mais elle est particulièrement utile pour exprimer
une relation fondamentale entre les deux éléments Comportementale et Structurel les plus canoniques, à savoir l'Activité

et le Bloc . Ceci est similaire à nos langues naturelles, où un verbe n'a aucun sens sans la présence d'un nom qui exécute
l'action décrite par le verbe. Ce type d'allocation est appelé allocation fonctionnelle, et l'ingénieur comble le fossé entre
ces deux aspects d'un système en trouvant un Bloc capable d'exécuter le comportement décrit par une activité.

Dans ce diagramme l'ingénieur a créé deux relations d'allocation fonctionnelle qui décrivent comment le travail spécifié
dans l'Activity Verify Entrant sera effectué. Une relation cible le système de caméra utilisé pour capturer la plaque
d'immatriculation du véhicule afin de déterminer si l'entrée du véhicule particulier a été autorisée. L'autre relation cible le
Bloc lecteur de carte qui est utilisé pour déterminer que le propriétaire de la carte a une relation avec la station de
stationnement.

Points d'interaction Modélisation

Les blocs - et les parties saisies par les blocs - résident dans un environnement et interagiront avec cet environnement et
les autres éléments qu'il contient. En termes généraux, SysML fournit une construction de langage appelée points
d'interaction, qui sont des emplacements sur la bordure d'un élément qui servent de points d'entrée et de sortie pour la
communication avec l'élément propriétaire. Les ports sont un type de point d'interaction et fournissent un mécanisme
permettant au Bloc d'exposer ses comportements - soit ceux qu'il possède de manière innée, soit ceux qui sont fournis par
ses parties. Le Port est représenté par un petit rectangle (généralement un carré) monté sur la bordure d'un Bloc ou d'une
Partie. SysML prend actuellement supporte deux types de ports destinés à remplacer à terme les concepts antérieurs de
Flow Port et de Standard Port :
· Port proxy - Agit comme un relais pour exposer les fonctionnalités comportementales fournies par le Bloc
propriétaire et est typé par une interface qui décrit ces services
· Port complet - Agit comme une partie et est typé par un Bloc , ce qui signifie qu'il peut lui-même contenir des
parties
Enterprise Architect prend entièrement en support ces deux types de ports et offre une compatibilité descendante avec les
anciens ports Standard et Flow (qui sont toujours disponibles mais seront obsolètes dans les versions ultérieures de la
norme).
Une fois qu'un diagramme de définition Bloc a été créé et qu'un Bloc a été placé sur le diagramme , les ports peuvent être
créés soit :
· Glissez-déposez le port approprié de la boîte à outils sur le Bloc - ce diagramme montre la section de la boîte à outils
de définition Bloc qui répertorie les ports.

· En sélectionnant l'option 'Nouvel élément enfant' dans le menu contextuel du Bloc et sélectionnez le type de port
approprié, comme indiqué :

Quelle que soit la méthode choisie, le Port sera alors automatiquement placé sur la bordure du Bloc et pourra être déplacé
à la position souhaitée et nommé. Note également que le port peut être ajouté depuis le panneau « Élément » du ruban «
Conception ». Cette image d'écran représente une section d' diagramme montrant deux ports avec des indicateurs de
direction à l'intérieur de l'élément Port. Les ports ont été nommés respectivement « entrée » et « sortie » et ont été saisis
par « Fluid », qui indique le type d'élément arrivant au port.

Les ports peuvent contenir des interfaces ainsi que des ports imbriqués ; Enterprise Architect fournit une fonctionnalité
utile qui permet à l'ingénieur de personnaliser la taille du port, en transformant efficacement les petits carrés en petits
rectangles.

Interfaces et ports

Une interface est un moyen utile d'encapsuler un groupe de services fournis par un Bloc , fournissant un moyen simple
d'exposer ces services aux clients. L'Interface a la même apparence qu'un Bloc et peut avoir des opérations et des
Réceptions définies, mais aucun attribut ( Propriétés ).

Une interface peut être créée en faisant simplement glisser l'icône « Interface » depuis la page Boîte à outils.
fonctionnalités Comportementale peuvent être ajoutées en sélectionnant la Fonctionnalité appropriée dans le menu
contextuel de l'interface.

Un autre moyen simple de créer les opérations d'une interface est de sélectionner le Bloc dans un diagramme ou dans la
fenêtre Navigateur et de cliquer sur l'élément du ruban :
Conception > Elément > Editeur > Fonctionnalités > Opérations

Les opérations sont simplement créées en sélectionnant l'onglet « Opérations » et en ajoutant le nom et d'autres détails
dans une ligne de la fenêtre. N'importe quel nombre d'opérations peut être créé, et chaque opération peut définir
n'importe quel nombre de paramètres qui spécifient les entrées et sorties de l'opération. Les réceptions - l'autre
fonctionnalité comportementale - peuvent être ajoutées de la même manière en utilisant l'onglet « Réceptions ».
N'importe lequel de ces éléments peut être réorganisé à l'aide des touches du clavier <Ctrl>+ flèches vers le haut et vers
le bas.
Des interfaces peuvent être ajoutées aux ports, qui constituent un mécanisme courant dans le Unified Modeling
Language et fournissent un moyen de publier les services disponibles sur un port. Les interfaces sont de deux types
fondamentaux :

· Fourni - disponible pour utilisation

· Obligatoire - requis pour l'utilisation
Avec un Port sélectionné en bordure d'un Bloc dans un diagramme , une Interface peut être ajoutée comme pour tout
autre élément structurel - à partir des éléments du menu contextuel du Port :

· Nouvel élément enfant | Fourni

· Nouvel élément enfant | Requis
Les interfaces ainsi ajoutées doivent être typées par une Interface proprement dite (un élément stéréotypé comme
« interface »). Ceci peut être réalisé en sélectionnant d'abord l'interface dans le diagramme , puis en sélectionnant la
fenêtre Propriétés dans le menu contextuel de l'interface. Vous pouvez ensuite nommer l'interface et utiliser l'icône [...]
pour naviguer ou rechercher l'élément Interface. Ce diagramme montre l'étape d'une interface d'enregistrement de signal.

Modélisation Quantité à l'aide de types valeur

Un Bloc peut avoir des propriétés simples appelées Value Propriétés , qui définissent les attributs d'un Bloc qui
représentent une quantité scalaire ou vectorielle. Les valeurs sont utilisées pour exprimer des informations sur un Bloc et
fournir un emplacement pour une valeur réelle à saisir dans une instance d'un Bloc . Par exemple, un réservoir peut avoir
des propriétés de diamètre, de hauteur et de volume définies. Les types valeur permettent à un ingénieur de créer une
manière universelle de quantifier une propriété ; Par exemple:

· Une centrifugeuse a une vitesse maximale spécifiée en tours par minute (rpm)
· Un wagon de train a un poids spécifié en kilogrammes (kg)
· Un réservoir a un volume spécifié en litres (l)
· Une source lumineuse a une intensité lumineuse spécifiée en Candela (cd)
· Un appareil de dialyse a un débit sanguin spécifié en millilitres par minute (ml/min)
Ce diagramme montre un certain nombre de types de valeur différents qui peuvent être définis dans Enterprise Architect ,
puis appliqués à n'importe quel nombre d'attributs définis dans les blocs.

L'objectif du Type de valeur est de permettre à un ingénieur, une équipe ou une industrie de définir des types standard qui
peuvent être réutilisés pour caractériser les propriétés valeur définies pour un nombre quelconque de blocs. Par exemple,
le type de valeur « Kilogramme » pourrait être appliqué à une propriété valeur spécifiant le poids d'un train ou le poids
d'un bus ou le nombre de sièges de l'un ou l'autre.

Ces types valeur , comme leur nom l'indique, ont une valeur qui décrit la quantité de la propriété ; ils peuvent être définis
à l'aide de l'onglet 'Attributs' de la fenêtre Fonctionnalités , comme illustré ici.

Par exemple, deux blocs représentant un train et un bus pourraient avoir une propriété de « Poids » définie qui est saisie
par le type de valeur « Kilogramme ». Si un attribut tel que « Capacité en sièges » a un type simple tel que « Integer »,
celui-ci peut être directement sélectionné dans la liste déroulante « Type », mais si « Type » est basé sur un Type de
valeur, cela peut être sélectionné à l'aide du bouton « Sélectionner ». tapez ..' dans la liste déroulante.
Les instances de blocs qui ont un attribut (propriété de valeur) défini dans Enterprise Architect peuvent avoir une valeur
réelle spécifiée pour l'attribut. Par exemple, chaque instance de bus et de train avec, disons, un numéro de modèle
particulier pourrait avoir un poids différent défini. D'autres propriétés telles que « Capacité en sièges » pourraient avoir
un type primitif de « Integer » défini, et celles-ci pourraient également être définies pour des instances particulières de «
Transport ».
Enterprise Architect permet à un ingénieur de définir les valeurs de chacun des attributs définis en utilisant l'option 'Set
Exécuter State ' du sous-menu ' Fonctionnalités ' pour une instance Bloc .

Les valeurs d'attribut (emplacements) peuvent être affichées sur un diagramme , permettant à un ingénieur de créer des
exemples convaincants ou des catalogues d'instances Bloc , comme indiqué ici.

Utiliser Paquetages pour Structurer le Référentiel

Le Paquetage est l'un des éléments les plus fondamentaux et les plus importants du SysML. Il fonctionne comme un
conteneur et, vu simplement, il ressemble à un dossier dans votre logiciel d'exploration de fichiers préféré pour votre
ordinateur. Donc, de cette façon, c'est d'abord un conteneur qui regroupe d'autres éléments, y compris d'autres
Paquetages , mais nous apprendrons dans cette rubrique qu'il a aussi d'autres fonctions importantes dans Enterprise
Architect .

Dans un sens plus profond, un Paquetage est un espace de noms qui fournit un moyen d'identifier de manière unique tout
élément d'un référentiel, de la même manière que fonctionne une URL. Le chemin indiqué ici a été extrait
automatiquement d' Enterprise Architect ; il vous permet de visualiser l'espace de noms.
Exemple SysML.HSUV Modèle .Cas d'utilisation HSUV.Cas d'utilisation.Conduire le véhicule
La mise en place de la structure Paquetage est une tâche importante et souvent redoutée, mais heureusement Enterprise
Architect enlève une grande partie de l'angoisse que ressentent les nouveaux arrivants (et les modélisateurs
expérimentés) lorsqu'ils abordent cette tâche.
Les prochains sujets vous présenteront les meilleures pratiques de mise en place d'une structure Paquetage , ainsi que
certains des outils et facilités supplémentaires qui faciliteront grandement le travail avec Paquetages .

The Function of Packages

En plus de la discussion précédente, Paquetages sont un élément important dans l'utilisation d' Enterprise Architect car ils
sont utilisés comme base pour un certain nombre de facilités dans l'outil, notamment :

· Conteneur pour éléments,

· Définition Namespace ,
· Sécurité,
· Contrôle de Version ,
· Lignes de base ,
· Importation et exportation,
· Documentation,
· Audit,
· Modélisation Consciente du Temps , et bien plus encore.
Ces éléments doivent tous être pris en compte au moment de décider de la structure des Paquetages . Le conteneur et
l'espace de noms sont les plus critiques, mais toutes les autres fonctions doivent être gardées à l'esprit lors du choix d'une
structure de modèle initiale ou lorsque la structure du modèle est refactorisée. Il arrive souvent que certaines
fonctionnalités ne soient pas utilisées initialement et ne soient mises en œuvre que lorsque le référentiel a acquis une
certaine maturité. C'est souvent un déclencheur de réorganisation du référentiel, mais heureusement - en raison de la
facilité du glisser-déposer - cela peut être fait facilement et efficacement et ne prend pas beaucoup de temps.

Présentation Diagrammes Paquetage

Le diagramme Paquetage est un diagramme simple qui décrit visuellement la structure du référentiel, y compris les
relations entre Paquetages et d'autres Paquetages et éléments. diagrammes Paquetage semblent assez simplistes avec un
petit nombre d'éléments :

· Modèle
· Bibliothèque d'Équipe
· Paquetage
· Vue
· Point Vue
· Partie prenante
Ceux-ci sont reliés par une série de relations.

Encore une fois, le nombre de relations est assez limité, mais chacune a une signification spécifique dans le diagramme .

· Se conformer
· Dépendance
· Importer
· Endiguement
· La concrétisation
· Affiner
· Exposer
Comme pour tous les éléments SysML, les éléments ont à la fois un aspect graphique et textuel, notes peuvent être
ajoutées à chacun des Paquetages et aux relations pour clarifier le but de l'élément ou du connecteur. Le diagramme
Paquetage peut contenir tout type d'élément de modèle, mais il contient généralement Paquetages . Enterprise Architect
étend la spécification SysML en fournissant un certain nombre de façons différentes et innovantes de visualiser
Paquetages et leur contenu sur un diagramme Paquetage . Ces options sont visibles dans le menu qui s'affiche lorsqu'un

Paquetage est glissé de la fenêtre Navigateur vers un diagramme .

Dans ce diagramme nous pouvons voir que le modélisateur a choisi l'option « Élément Paquetage » et a défini la
visibilité du compartiment de l' object diagramme Paquetage pour afficher le contenu du Paquetage . Les options de
visibilité des compartiments sont disponibles dans le menu contextuel d'un object diagramme pour n'importe quel
élément, et Enterprise Architect modifie dynamiquement les options en fonction du type d'élément et des compartiments
disponibles.

Dans le diagramme suivant, l'ingénieur a choisi l'option « Paquetage as List », qui s'appuie sur du code SQL généré
automatiquement mais configurable par l'utilisateur pour créer une liste dynamique d'éléments basée sur n'importe quelle
métadonnée de l'élément Paquetage . Ici, nous voyons la même liste d'exigences mais cette fois, un certain nombre de
propriétés sont également affichées.

N'importe quel nombre de diagrammes Paquetage peut être créé pour définir ou aider à visualiser la structure du
référentiel. Pour plus d’informations, consultez la rubrique d’aide Package Diagram .

Création Diagrammes Paquetage

Un diagramme Paquetage peut être créé à partir de plusieurs endroits de l' Interface Utilisateur , en sélectionnant :
· Ruban de conception - Ajouter une icône dans le panneau Diagramme
· Barre d'outils de la fenêtre Navigateur - Icône Nouveau Diagramme
· Menu contextuel de la fenêtre Navigateur - Ajouter Diagramme
Les options d'accès afficheront toutes la même dialogue , ce sont simplement des points d'entrée différents vers les
mêmes fonctionnalités de l'outil. Nous utiliserons le ruban Conception pour créer un diagramme Paquetage .
Sélectionnez d'abord l'emplacement dans la fenêtre Navigateur où vous souhaitez que le diagramme Paquetage se trouve.
Il peut s'agir soit d'un Paquetage , soit d'un élément, mais il est courant d'insérer diagrammes Paquetage dans un
Paquetage . Une fois l'emplacement Paquetage sélectionné dans la fenêtre Navigateur , sélectionnez l'option du ruban :
Conception > Diagramme > Ajouter Diagramme

La sélection de cette option ouvrira la dialogue Nouveau Diagramme , sur laquelle vous nommerez le diagramme ; le
nom est initialement par défaut le nom du Paquetage ou de l'élément qui contient le diagramme . Avec la perspective
SysML choisie et la version de SysML sélectionnée, une liste de diagrammes s'affichera à partir de laquelle vous
sélectionnerez le diagramme Paquetage . Cliquez sur le bouton OK pour créer un nouveau diagramme Paquetage à
l'emplacement sélectionné dans la fenêtre Navigateur . Le Diagramme Vue s'ouvrira, vous permettant de commencer à
ajouter des éléments et des connecteurs qui décrivent la structure du système et sa division en ces groupes structurels.
Enterprise Architect affichera également les pages de la boîte à outils « Paquetage » qui contiennent les éléments et les
relations tels que définis par la spécification SysML pour être applicables à la construction diagrammes Paquetage .
N'importe quel nombre d'autres pages de la boîte à outils peuvent être ouvertes, si nécessaire, en plus des pages «

Éléments communs » et « Relations communes » qui seront toujours disponibles.

Les éléments et connecteurs les plus importés utilisés avec le diagramme Paquetage sont :
Éléments
· Modèle - utilisé pour définir une partie de haut niveau du système
· Bibliothèque d'Équipe - utilisée pour définir un ensemble d'éléments réutilisables
· Paquetage - utilisé pour créer une unité structurelle de base
· Vue - utilisé pour définir ce qu'une partie prenante verra lors de la visualisation
· Point de vue - utilisé pour définir un point de référence pour une vue
· Partie prenante - utilisé pour décrire des personnes ou des parties ayant un intérêt matériel

Connecteurs
· Se conformer
· Dépendance
· Importer
· Endiguement
· La concrétisation
· Affiner
· Exposer
Des éléments peuvent être ajoutés au diagramme en les faisant glisser et en les déposant depuis la boîte à outils vers le
Diagramme Vue . Il est considéré comme une bonne pratique de commencer par définir Modèle et les bibliothèques
Modèle . Lorsqu'une icône Modèle ou Bibliothèque d'Équipe est glissée de la Boîte à outils vers un diagramme , le
modélisateur sera invité à saisir un nouveau nom Paquetage à l'aide de cette dialogue :

Une fois le nom Paquetage saisi, un nouvel élément Paquetage sera créé sur le diagramme . Lors de la création d'un
Paquetage à partir de la boîte à outils ou de son insertion dans la fenêtre Navigateur , un modélisateur se voit proposer un
certain nombre d'options, comme indiqué dans le dialogue de cette capture d'écran.

Comme décrit précédemment, lorsqu'un Paquetage existant est glissé depuis la fenêtre Navigateur (ou copié à partir d'un
diagramme existant), Enterprise Architect vous permet de le créer de différentes manières, comme indiqué dans cette
capture d'écran :

Régimes d'organisation Paquetage

Comme suggéré précédemment, les bibliothécaires, administrateurs ou ingénieurs impliqués dans la mise en place du
référentiel peuvent se trouver en conflit sur la direction à prendre car il existe un large éventail de principes
d'organisation qui peuvent être utilisés pour structurer le contenu du référentiel. Certains d'entre eux sont :

· Une structure de décomposition - Systèmes | Sous-systèmes | Composants | les pièces

· Équipes d'ingénierie travaillant sur différents aspects d'un système - Team One | Équipe deux
· Programmes de travail et projets - Programme Un | Projet un, projet deux
· Divisions au sein d'une méthode - Architecture | Exigences | Conception
· Sécurité et contrôle d'accès
· Facilité de navigation
N'importe lequel ou n'importe quelle combinaison de ces principes peut être utilisé pour structurer le référentiel, et ils
peuvent être modifiés au fil du temps pour s'adapter à l'évolution des pratiques d'ingénierie ainsi qu'à l'utilisation du
modèle et à l'expérience des utilisateurs. Le plus difficile de ces principes est peut-être la nécessité de rendre le
référentiel convivial pour ses habitants, de garantir une navigation aisée afin qu'ils puissent trouver facilement ce qu'ils
recherchent. Enterprise Architect dispose de quelques facilités utiles pour réduire cette tension, permettant d'utiliser
d'autres mécanismes pour la navigation et libérant la conception du référentiel pour qu'elle se développe sur la base d'un
certain nombre d'autres principes plus importants. Certaines de ces fonctionnalités d’outils sont répertoriées ici.

Modèle Vues

Fournissez un mécanisme flexible et efficace permettant à un ingénieur ou à une équipe de créer n'importe quelle vue du
modèle qu'il juge utile. L'utilisation de cette facilité évite aux modélisateurs et aux ingénieurs d'accéder à la fenêtre
Navigateur , car ils peuvent localiser les éléments d'intérêt via la fenêtre Modèle Vues .

Par exemple, des vues peuvent être créées sur la base d'une recherche qui renvoie des éléments de n'importe quelle partie
du référentiel ; un ingénieur pouvait définir une vue renvoyant toutes les exigences hautement prioritaires, avec le statut
« Approuvé » et marquées comme « Difficile », quel que soit le projet dont il faisait partie ou l'endroit où il se trouvait
dans la hiérarchie Paquetage . Alternativement, un modélisateur peut simplement sélectionner des éléments et
diagrammes particuliers qui sont importants pour lui et les inclure dans une Vue Favoris, ou créer une vue basée sur les
composants nouvellement créés. Cette facilité fournit un mécanisme très flexible pour accéder aux parties importantes du
référentiel, et des vues peuvent être créées au niveau du modélisateur ou de l'équipe. Nous reviendrons sur le Modèle

Vues facilité dans une rubrique ultérieure, car il s'agit d'une partie extrêmement utile de l'outil.

Cellules de navigation Diagramme

Enterprise Architect a facilité la navigation des utilisateurs dans un référentiel en fournissant un mécanisme diagramme
permettant de créer un lien hypertexte vers n'importe quel diagramme du référentiel.

Cela permet aux bibliothécaires et même aux modélisateurs eux-mêmes de créer un nombre illimité de diagrammes qui
agissent comme des rampes de lancement qui dirigeront le spectateur vers diagrammes d'intérêt, le protégeant ainsi de la
nécessité de connaître la structure du référentiel. Ces diagrammes sont visibles via le navigateur Internet et les produits
Cloud , et offrent une expérience convaincante aux utilisateurs occasionnels et aux non-modélistes.

Rechercher Facilité

Il s'agit d'une fonctionnalité puissante qui fournit des recherches intégrées et définies par l'utilisateur pour récupérer une
liste d'éléments ou diagrammes répondant à un ensemble de critères spécifié. La quantité d'informations contenues dans
un référentiel peut croître de façon exponentielle à mesure que davantage de personnes contribuent aux modèles et que
les informations sont importées de sources externes telles que Risques , les politiques, les règles, les principes, etc. Il
existe un ensemble riche et utile de recherches définies dans le cadre du produit et, dans de nombreux cas, une de ces
recherches intégrées suffira à un modélisateur ou à un ingénieur pour localiser les éléments ou diagrammes qu'il
recherche. Ces recherches peuvent être pilotées par des paramètres, fournissant ainsi un mécanisme permettant de
réutiliser une recherche pour trouver une variété d'éléments. Par exemple, une recherche pourrait être écrite avec un
paramètre de saisie utilisateur Status permettant aux utilisateurs de saisir un statut, par exemple « Proposé » au moment
où la recherche est exécuter .

Les recherches peuvent être créées par du personnel non technique à l'aide du générateur Query intuitif, mais il existe
également un certain nombre d'autres façons de créer des recherches, notamment des requêtes basées sur SQL qui
nécessitent une connaissance des tableaux de la base de données et des requêtes complémentaires qui nécessitent une
personne technique. pour créer un programme qui définit la recherche. Ces recherches peuvent être utilisées par un
certain nombre d'autres facilités , notamment, comme indiqué précédemment, Modèle Vues .

La fenêtre du Navigateur
La fenêtre Navigateur est le principal outil permettant de structurer et de parcourir le référentiel, à l'aide de nœuds
d'arborescence développés et réduits. L'élément structurel clé est le Paquetage , qui est un élément de type dossier
pouvant contenir d'autres éléments et diagrammes , y compris d'autres Paquetages . Les éléments peuvent à leur tour
contenir d'autres éléments, fonctionnalités et diagrammes , mais pas Paquetages .

Les nœuds racines sont les nœuds les plus élevés de l’arborescence ; ces Paquetages racine peuvent contenir Vues qui à
leur tour peuvent contenir n'importe quel niveau de Paquetages et d'éléments. Les nœuds d'arborescence comprenant
Paquetages , les éléments, Fonctionnalités et diagrammes peuvent être copiés et collés entre des emplacements, ou
glissés et déposés vers de nouveaux emplacements. De nombreux outils, fonctions et fenêtres importants sont appliqués
au niveau du Paquetage , comme l'importation ou l'exportation du contenu du modèle, de la documentation et du
Contrôle Paquetage , y compris Lignes de base . Pour plus d’informations, consultez la rubrique The Browser Window .

Diagramme de contexte et navigateurs d'éléments

Enterprise Architect fournit un certain nombre de navigateurs supplémentaires qui aident un ingénieur ou un
modélisateur à se concentrer sur un sous-ensemble du contenu du référentiel. Ces navigateurs peuvent être sélectionnés
sous forme d'onglets dans la fenêtre principale Navigateur .

Le Context Navigateur fournit une vue filtrée uniquement d'une branche particulière du modèle, pour travailler
uniquement sur la section du référentiel pertinente à un moment donné. Cette vue Spotlight élimine le bruit et la
complexité de la vue Projet et affiche uniquement la partie du modèle qui l'intéresse, permettant à l'ingénieur de la
visualiser de manière isolée.

Dans notre exemple, le modélisateur souhaite concentrer son attention sur le Use Case Paquetage . En utilisant le bouton
, vous pouvez remonter dans l'arborescence, ou en cliquant sur un Paquetage ou un élément contenant d'autres
éléments, ceux-ci peuvent être affichés, mais la vue reste toujours à un seul niveau de hiérarchie.
Le Diagramme Navigateur liste les objets présents sur le diagramme actif. Les connecteurs de chaque object peuvent
également être affichés, ce qui en fait une vue précieuse du diagramme .

Le Navigateur d'Élément affiche des informations sur l'élément actuellement sélectionné. Cela permet de visualiser
toutes les relations entre les éléments, les scénarios, les exigences, fonctionnalités et bien plus encore.

Accéder au Référentiel à l'aide Modèle Vues

Modèle Vues fournissent des vues alternatives des éléments du Référentiel . Alors que la fenêtre Navigateur est conçue
pour organiser structurellement les Paquetages et les éléments, le Modèle Vues facilité permet au modélisateur de créer
un certain nombre de vues pouvant regrouper les éléments et diagrammes différemment. Il s'agit d'une facilité pratique
qui peut être utilisée par des individus et des équipes d'ingénierie pour voir le contenu du référentiel dans un certain
nombre de vues propriétaires conçues pour présenter uniquement les informations importantes ou pertinentes. Il vous
permet effectivement de créer des fenêtres à travers lesquelles visualiser le référentiel de manière unique et convaincante
qui fournira des informations et de la clarté, permettant au modélisateur de voir des choses qui n'auraient peut-être pas
été possibles avec la fenêtre Navigateur .

Les vues peuvent être basées sur un large éventail de critères, notamment des dossiers Favoris contenant des éléments
d'intérêt sélectionnés à la main, et des dossiers basés sur une recherche telle que « tous les éléments créés la semaine
dernière qui ont un statut Proposé » ou « tous les composants fournis par un fournisseur d'ingénierie particulier». Pour
plus d'informations voir le Model Views Rubrique d'aide.

Définition et gestion des besoins

Le domaine de l’ingénierie des exigences est l’une des disciplines les plus critiques dans le cycle de vie du
développement de solutions, et il a un impact documenté sur la réussite des projets. Selon les mots du célèbre physicien
du XXe siècle, Albert Einstein :
"Si vous définissez un problème avec suffisamment de soin, la solution vous sautera aux yeux."

Enterprise Architect dispose d'une gamme inégalée d'outils pour développer, gérer, visualiser et documenter les
exigences, y compris des outils pour importer ou intégrer et synchroniser avec des systèmes de gestion des exigences
externes.

Ces outils implémentent tous les aspects des exigences définies dans la spécification SysML, mais les fonctionnalités de
l'outil vont bien au-delà pour créer une plate-forme d'exigences sophistiquée remplie d'outils pour toutes les disciplines
associées à la gestion et à la définition des exigences. Non seulement les outils sont utiles pour les ingénieurs ou les
gestionnaires travaillant directement avec les exigences, mais il existe également une gamme de facilités telles que la
fenêtre de traçabilité qui aideront n'importe quelle discipline et qui peuvent être utilisées par les équipes d'architecture et
de conception chargées de garantir les exigences sont intégrées aux conceptions et, par conséquent, mises en œuvre dans
le produit ou le service livré. Pour plus d'informations, consultez la rubrique d'aide The Requirements Model .

Exigences en développement

Le développement des exigences comprend toutes les activités et tâches associées à la découverte, à l'évaluation, à
l'enregistrement, à la documentation et à la validation des exigences d'un projet particulier. Exigences sont découvertes,
analysées, précisées et vérifiées. Enterprise Architect dispose d'une large gamme d'outils et fonctionnalités pour aider
l'ingénieur système à développer ses exigences. La pièce maîtresse du développement des exigences est le Gestionnaire
de Spécification , grâce auquel l'ingénieur peut saisir, visualiser et gérer les exigences sous forme textuelle comme dans
une feuille de calcul ou un document. Les propriétés des exigences telles que le statut, la priorité et l'auteur peuvent être
modifiées en ligne et des filtres peuvent être appliqués pour restreindre l'affichage à des exigences particulières.

Le Gestionnaire de Spécification peut être utilisé conjointement avec une plateforme d'autres outils tels que diagrammes ,
la fenêtre Traçabilité et les Discussions facilité .

Gérer Exigences

Il s'agit des activités visant à maintenir un ensemble d'exigences qui représentent un accord ou un accord entre l'équipe
de projet et le client. Il vise également à garantir que les exigences sont acceptables pour les équipes de conception et de
développement et qu'elles sont suffisamment spécifiques pour être mises en œuvre dans des systèmes opérationnels,
logiciels ou matériels. Enterprise Architect est une plateforme sophistiquée de gestion des exigences, et quel que soit le
domaine, la taille du projet ou la méthode suivie, Enterprise Architect fournit des outils qui facilitent la gestion du plus
grand référentiel d'exigences dans des projets complexes.

Relations avec les exigences

Il existe un riche ensemble de relations d'exigences qui permettent aux éléments d'exigence d'être connectés à d'autres
éléments modélisation , y compris d'autres Exigences . Les relations comprennent :
· Endiguement

· Tracer
· Copie
· Dériver
· Vérifier
· Affiner
· Satisfaire
Nous explorerons pleinement ces relations dans le corps de ce sujet.

Visualiser Exigences

La visualisation des exigences est un aspect important du processus des exigences car il est essentiel que le catalogue des
exigences puisse être consulté par toutes les parties prenantes au fur et à mesure qu'elles sont spécifiées, analysées,
développées et gérées. Les exigences représentent l'interprétation par un ingénieur des discussions, des observations et
des articulations faites par les parties prenantes concernant le problème ou l'opportunité en question. Enterprise Architect
dispose d'un large éventail de mécanismes non seulement pour présenter ces exigences à la communauté des parties
prenantes, mais également pour permettre aux exigences d'être discutées, examinées et organisées.

Documenter Exigences

Il existe un certain nombre de documents qui sont couramment produits dans le cadre de la discipline d'ingénierie des
exigences, tels que les Spécification Exigences système et les Rapports de cas d'utilisation, et ceux-ci peuvent être
générés automatiquement à partir d'un modèle d'exigences à l'aide gabarits intégrés ou gabarits définis par l'utilisateur.
De plus, une large gamme d'autres documents peuvent être produits à l'aide gabarits intégrés ou personnalisés.

Il existe également la possibilité de visualiser les modèles dans un navigateur Web sur un appareil portable tel qu'un
téléphone ou une tablette ou un PC. Cette facilité est disponible dans le cadre du produit Pro Cloud Server et offre une
alternative à la production de documentation statique et permet à une équipe d'ingénierie de communiquer et de
collaborer avec un public étendu en dehors de l'environnement modélisation sans avoir besoin d'installation ou de
configuration logicielle.

Exigences en tant que citoyens de première classe

Enterprise Architect fournit une large gamme de facilités qui peuvent être utilisées pour le développement, la
visualisation, la gestion et la documentation des Exigences en tant qu'éléments de première classe. Les personnes lisant
des manuels SysML généraux reviendront souvent avec l'idée que Exigences sont exprimées sur diagrammes , mais
Enterprise Architect propose un large éventail d'autres moyens de visualiser Exigences qui aideront l'ingénieur lorsqu'il
travaillera avec elles en tant qu'éléments basés sur du texte, notamment en étant capable de visualisez-les
hiérarchiquement dans la fenêtre Navigateur .

Exigences peuvent être créées dans le cadre d'un cahier des charges ou d'un appel d'offres, ou faire partie d'un document
contractuel, auquel cas elles peuvent être facilement importées dans Enterprise Architect . Cependant, il est plus courant
qu'ils soient développés dans le cadre d'un effort d'élicitation généralement mené avec des ateliers et révisions .
Enterprise Architect dispose d'un certain nombre de fonctionnalités qui peuvent être utilisées pour enregistrer le résultat
de ces réunions, telles que diagrammes Mind Map. Une fois les ateliers terminés, les idées enregistrées lors de ces
réunions peuvent être converties en Exigences ou mappées aux éléments de la réunion de manière à permettre leur
développement collaboratif.
Les Exigences font souvent partie d'une relation contractuelle entre organisations, ou d'un accord entre différentes
sections d'une même organisation, et à ce titre doivent être entretenues et gérées avec rigueur. Enterprise Architect
propose une large gamme de facilités pour vous aider dans cette rigueur, notamment Lignes de base , Outils d'audit,
Contrôle de Version et bien plus encore.

Audit Exigences

L'audit peut être activé dans un modèle et suivre les détails d'une modification d'exigence, y compris la date à laquelle
elle a été modifiée, qui l'a modifiée et le delta - avant et après la modification. L'audit peut être utilisé pour suivre ce qui
a été modifié dans un modèle, qui l'a modifié et quand. Il existe un certain nombre de modes et un administrateur de
référentiel peut utiliser les paramètres pour spécifier ce qui est enregistré dans l'audit. Alors qu'une référence peut être
utilisée pour montrer la différence entre un modèle et un instantané à un moment donné, l'outil d'audit enregistre chaque
changement individuel ; il ne peut cependant pas être utilisé pour revenir à un état antérieur (l'outil Baseline serait utilisé
si cela était nécessaire).

Il s'agit d'une fonctionnalité particulièrement utile dans Ingénierie des Systèmes , lorsqu'un processus présente des
aspects réglementaires ou de conformité ou lorsque les défauts doivent être retracés jusqu'à leur conception ou la
spécification des exigences. L'audit serait généralement mis en place et administré par un bibliothécaire ou une fonction
administrative au sein de l'équipe. L'audit peut être activé, configuré et affiché à l'aide de l'option du ruban « Paramètres
> Modèle > Audit ».
L'audit est désactivé par défaut et doit être activé (activé) avant que le système ne commence à conserver un log d'audit.
Ceci, ainsi qu'une gamme d'autres options, est disponible dans la fenêtre Paramètres d'audit.

Pour plus d'informations, consultez la rubrique d'aide Auditing .

Exigences Lignes de base

Lignes de base sont des instantanés initiés par l'utilisateur d'un Paquetage dans un modèle. La Baseline fait effectivement
une copie d'une branche de la hiérarchie Paquetage et de son contenu. À un moment ultérieur, le modèle peut être
comparé à la ligne de base et, si le modèle a changé, ces modifications seront présentées dans un outil de visualisation,
permettant à un utilisateur de visualiser chaque partie du modèle qui a changé, y compris le contenu. qui existe dans la
ligne de base et le modèle. Il est alors possible d'injecter le contenu de la Baseline dans le modèle au niveau d'un
changement discret.

Lignes de base offrent aux équipes Ingénierie des Systèmes un moyen pratique de s'assurer que les modèles évoluent
dans le bon sens, et lorsqu'une direction de modèle doit être rétablie vers une version précédente, elles peuvent être
utilisées pour rétablir les parties atomiques du modèle. Lignes de base peuvent être configurées et visualisées en

appuyant sur Ctrl+Alt+B ou depuis l'emplacement du ruban :

Ruban : Conception > Paquetage > Gérer > Gérer Lignes de base
Comme indiqué précédemment, Lignes de base sont initiées par l'utilisateur et sont stockées dans le référentiel, donc si le
référentiel est copié, les Lignes de base le seront également. Il est assez courant que la plupart des utilisateurs reçoivent
l'autorisation de créer Lignes de base , mais la possibilité de restaurer à partir d'une Ligne de base est généralement
réservée à un rôle de bibliothécaire ou d'administrateur. Pour plus d’informations, consultez la rubrique d’aide Baseline
Tool .

Contrôle de Version

Contrôle de Version permet de versionner Paquetages au sein d'un modèle. Pour commencer à travailler sur une partie du
modèle, un utilisateur doit extraire un Paquetage (y compris ses sous-packages), puis travailler sur une copie locale.
Lorsque le travail est terminé ou à tout moment, un utilisateur peut enregistrer le Paquetage permettant aux modifications
d'être vues par d'autres utilisateurs du modèle.
Contrôle de Version offre une manière sophistiquée et robuste de travailler avec des modèles et, contrairement à Lignes
de base , ne nécessite pas qu'un utilisateur lance une version autrement que pour extraire le Paquetage . Le système crée
automatiquement une version en arrière-plan au fur et à mesure que le travail est effectué et que des modifications sont
apportées. Contrôle de Version peut être configuré et visualisé à partir de ces options du ruban.
Paramètres > Contrôle de Version > Projet-VC, Package-VC
Contrôle de Version fournit un mécanisme efficace de gestion du contenu du modèle et permet à un utilisateur ou à une
équipe de garder un contrôle précis sur la façon dont un Paquetage et son contenu évoluent au fil du temps. Pour plus
d'informations voir le Version Control of Model Data Rubrique d'aide.

Présentation Diagrammes d'exigences

Un diagramme d'exigences fournit un moyen de visualiser Exigences et leurs connexions. Ce n'est pas seulement la
relation entre deux Exigences , mais les relations entre Exigences et d'autres types d'éléments tels que le Cas
d'Utilisation, l'Activité et Bloc qui peuvent être visualisées sur ces diagrammes . Deux des éléments fournis dans la boîte
à outils sont :
· Exigence
· Cas Test
Ces éléments peuvent être connectés les uns aux autres ou à d’autres éléments, créant ainsi des expressions riches.

Dans ce diagramme , nous voyons une exigence qui a été connectée à un Bloc à l'aide d'une relation Satisfy , qui décrit
comment d'autres éléments garantiront que l'intention de l'exigence est satisfaite. Le Bloc a défini une image alternative,
celle d'un robot.
Encore une fois, le nombre de relations est assez limité, mais chacune a une signification spécifique dans le diagramme .
· Endiguement
· Tracer
· Copie
· Dériver
· Vérifier
· Affiner
· Satisfaire
Comme pour tous les éléments SysML, les éléments présentent à la fois un aspect graphique et textuel. L'exigence a deux
propriétés définies :

· id - un identifiant unique pour l'exigence

· Texte - une description textuelle de l'exigence
Un certain nombre de diagrammes d’exigences peuvent être créés pour décrire les besoins et les préoccupations des
parties prenantes et autres. Pour plus d’informations, consultez la rubrique SysML Requirements Modeling .

Création Diagrammes d'exigences

Un diagramme de besoins peut être créé à partir de plusieurs endroits dans l' Interface Utilisateur , tels que :
· Ruban de conception - Icône 'Ajouter Diagramme ' sur le ' Diagramme ' panneau
· Barre d'outils de la fenêtre Navigateur - Icône ' Nouveau Diagramme '
· Menu contextuel de la fenêtre Navigateur - option 'Ajouter Diagramme '
Nous utiliserons le ruban Conception pour créer un diagramme d'exigences. Tout d'abord, sélectionnez l'emplacement
dans la fenêtre Navigateur où vous souhaitez créer le diagramme des exigences. Comme pour tous diagrammes , il peut
s'agir soit d'un Paquetage , soit d'un élément, mais il est courant d'insérer diagrammes d'exigences dans un Paquetage .
Une fois l'emplacement Paquetage sélectionné dans la fenêtre Navigateur , cliquez sur l'option du ruban 'Conception >
Diagramme > Ajouter Diagramme '.

Cette option ouvre la dialogue ' Nouveau Diagramme ', vous permettant de renommer le diagramme - le nom par défaut
est initialement le nom du Paquetage ou de l'élément qui contient le diagramme . Lorsque vous sélectionnez la
perspective SysML et la version de SysML, une liste de diagrammes s'affichera, vous permettant de sélectionner le
diagramme d'exigence. Vous cliquez sur le bouton OK pour créer un nouveau diagramme d'exigences à l'emplacement
spécifié dans la fenêtre Navigateur . Le Diagramme Vue s'ouvrira, vous permettant de commencer à ajouter des éléments
et des connecteurs qui décrivent les Exigences et leurs relations. Enterprise Architect affichera également la page «
Exigences » de la boîte à outils, qui contient les éléments et les relations définis par la spécification SysML pour être
applicables à la construction diagrammes d'exigences. N'importe quel nombre d'autres pages de la boîte à outils peuvent
être ouvertes selon les besoins, en plus des pages de la boîte à outils « Éléments communs » et « Relations communes »
qui sont affichées par défaut.

Les éléments et connecteurs les plus importants utilisés avec le diagramme des exigences sont :

Éléments
· Exigence - utilisé pour définir une exigence
· Cas Test - utilisé pour décrire un Test

Connecteurs
· Confinement - utilisé pour fournir des informations supplémentaires qui aident à clarifier l'exigence
· Trace - utilisé pour connecter une exigence à tout autre élément modélisation
· Copie - utilisé pour montrer qu'une exigence est une copie d'une autre
· Dériver - utilisé pour décrire le fait qu'une exigence est basée sur ou est une extension ou une dérivation d'une autre
exigence

· Vérifier - utilisé pour indiquer qu'une exigence a été remplie

· Affiner - utilisé pour ajouter un affinement ou des informations supplémentaires qui aident à clarifier l'exigence
· Satisfaire - utilisé pour montrer qu'un ou plusieurs éléments de modèle dans l'architecture ou la conception
répondent à la notion exprimée dans l'exigence

Extensions d'exigences
· Exigence étendue – utilisé pour Exigences étendues
· Exigence fonctionnelle - utilisée pour Exigences liées à la fonction
· Exigence d'interface - utilisée pour Exigences liées aux interfaces
· Exigence de performance - utilisée pour Exigences liées à la performance
· Exigence physique - utilisée pour Exigences liées aux aspects physiques d'un système
· Exigence de conception - utilisée pour Exigences liées à la conception

Des éléments peuvent être ajoutés au diagramme en les faisant glisser et en les déposant de la boîte à outils vers le
Diagramme Vue . Relations peuvent être créées en sélectionnant d'abord la relation requise dans la boîte à outils, puis en
effectuant un glisser-déposer entre un élément source et un élément cible. Il est courant de ne pas créer diagrammes
d'exigences répertoriant simplement les Exigences , mais plutôt de créer diagrammes qui montrent les relations entre
deux Exigences quelconques ou les relations que les Exigences entretiennent avec d'autres éléments tels que les cas
d'utilisation, les activités et les blocs.

Exigences en développement
Le développement des exigences comprend toutes les activités et tâches associées à la découverte, à l'évaluation, à
l'enregistrement, à la documentation et à la validation des exigences d'un projet ou d'un programme de travail particulier.
Exigences sont découvertes, analysées, spécifiées et vérifiées, et Enterprise Architect dispose d'une large gamme d'outils
et fonctionnalités pour aider l'ingénieur système à mesure qu'il développe les exigences. La pièce maîtresse du
développement des exigences est le Gestionnaire de Spécification , permettant à l'ingénieur des exigences de saisir,
visualiser et gérer les exigences sous forme textuelle dans un format de feuille de calcul.

Le Gestionnaire de Spécification peut être utilisé conjointement avec une plateforme d'autres outils, tels que diagrammes
, la fenêtre Traçabilité et les Discussions facilité . Ces fenêtres fournissent d'autres vues des exigences, donnant au
modélisateur et au visualiseur une compréhension approfondie de la façon dont une exigence est liée à d'autres parties du
référentiel, et fournissant des détails non visibles via le Gestionnaire de Spécification .

Élicitation
L'élicitation est le processus de découverte d'informations, les informations glanées à partir de ce processus constitueront
les précurseurs des exigences. Les informations seront généralement brutes et souvent hétérogènes, et ce n'est qu'après la
phase d'analyse des exigences que les véritables exigences pourront en être dérivées. L'élicitation prendra de nombreuses
formes, et toutes les compétences de l'ingénieur des exigences seront nécessaires pour déterminer quels documents,
machines, outils, personnes et processus examiner pour découvrir les informations.

Sources des documents

Exigences peuvent souvent provenir d’un large éventail d’endroits, y compris des documents tels que :
· Affaire Métier
· Concept de fonctionnement
· Spécifications des exigences (d'un système existant)
· Manuel de l'Utilisateur
· Document de normes
· Document de politique
· Document réglementaire ou de conformité
Bien que tous ces documents puissent être développés dans Enterprise Architect à l'aide de Document Artifact facilité ,
ils sont généralement développés dans d'autres outils et se trouvent en dehors du référentiel. Ils peuvent être glissés sur
un diagramme et importés dans le référentiel ou enregistrés comme référence ou substitut pour le document externe.

Une autre option, peut-être plus utile, consiste à les ajouter à la Bibliothèque d'Équipe , qui est une bibliothèque de
documents et de pages Web utilisée pour créer un catalogue d'éléments pouvant être référencés par exigences. Il convient
également d'envisager réviser le contenu des documents et d'incorporer les informations comme éléments de modèle.
Cela présente l'avantage qu'un ingénieur soit capable de créer des relations de traçabilité entre des éléments tels que les
motivations Métier et les éléments de problème et de solution tels que Exigences , les cas d'utilisation et les composants.
Pour plus d'informations, consultez la rubrique d'aide The Model Library .

Observations des utilisateurs

Observer les utilisateurs effectuer leur travail est un moyen utile et discret de comprendre :

· Les tâches qu'ils accomplissent et

· Comment ils utilisent les informations et autres dispositifs logiciels et matériels pour obtenir un résultat de leur
interaction avec un système
Même si les processus qui support le système prévu seront différents, les observations des processus actuels fourniront
un contexte utile pour les discussions. Cela aidera également l'ingénieur à faire preuve d'empathie envers l'utilisateur, ce
qui pourra lui permettre de mieux comprendre les problèmes auxquels il est confronté et servir de base à la découverte de
solutions potentielles. Un ingénieur découvrira souvent des documents, des listes de contrôle et des fiches d’indices non
mentionnés qui peuvent aider à éclairer le processus. Equipé d'un téléphone portable ou d'un appareil photo, il est
également utile pour l'ingénieur de prendre des photos de l'utilisateur en train de travailler, ce qui aidera les ingénieurs et
autres à se rappeler et à discuter de la tâche pendant la phase d'analyse des besoins.
Enterprise Architect supporte le modélisateur à représenter des fichiers tels que des photos et des documents numérisés
directement dans le modèle, créant ainsi une représentation riche et expressive de l'utilisateur au travail. Il existe la
possibilité de les représenter sous forme d'artefact (qui, d'un simple appui sur une touche (F12), lancera le fichier) ou
d'utiliser un lien hypertexte ou même d'inclure l'image elle-même dans un diagramme . Pour plus d'informations,
consultez la rubrique Changing Element Appearance .

Ce diagramme représente une photographie prise par un ingénieur d'un robot de ligne de production avancé assistant un
système de fabrication. L'image peut être placée dans diagrammes et des relations peuvent être établies entre le robot et
d'autres parties de la description du système, y compris les exigences.

Séminaires des parties prenantes

L'Ingénieur Exigences est chargé de la tâche difficile de susciter les exigences, ce qui nécessite une excellente
communication avec les parties prenantes, notamment le client et l'équipe d'analyse. Un moyen très efficace de faciliter
l'élicitation des besoins des parties prenantes est d' exécuter un atelier avec toutes les parties prenantes clés présentes. Les
compétences de communicateur, de diplomate et de médiateur de l'Ingénieur Exigences sont importantes pour créer un
environnement collaboratif et respectueux propice à l'exploration des besoins et des préoccupations des parties prenantes.
Il est impératif que l'ingénieur utilise une terminologie que les parties prenantes comprennent et fasse également preuve
d'une compréhension ou d'une volonté d'en apprendre davantage sur les éléments qui composent le domaine de
l'ingénierie.
Il existe parfois une idée fausse selon laquelle ce qui sera articulé au cours de ces ateliers est un ensemble d'exigences
clairement définies qui peuvent être saisies dans l'outil en tant Exigences des parties prenantes. C’est loin de la réalité de
ce qui se passe. Les parties prenantes articuleront généralement un large éventail d'idées, notamment des politiques,
Règles Métier , des définitions de données, des contraintes Gestion de Projet , Exigences fonctionnelles, Exigences
Métier , des problèmes de système existants et même des solutions suggérées. Même lorsqu'un consultant externe est
utilisé pour exécuter ces réunions, l'ingénieur n'aura pas le temps de catégoriser toutes ces déclarations au sein des
réunions. Ce qu'il faut, c'est un moyen pour le scribe chargé de documenter les déclarations de les intégrer dans l'outil
sans se soucier du type d'informations enregistrées. Les enregistrer dans l'outil plutôt que les griffonner dans le cahier de
l'ingénieur est une bonne pratique car cela permet de les afficher pendant la réunion et aux parties prenantes de voir les
commentaires des autres.
Enterprise Architect propose un certain nombre de facilités qui peuvent vous aider dans ces ateliers. Une méthode très
pratique consiste à utiliser le diagramme Mind Mapping pour enregistrer les déclarations des parties prenantes, ce qui est
très efficace car il s'agit d'une méthode bien connue et n'introduit aucune des formalités liées aux langages modélisation
tels que SysML. Ce diagramme montre une carte mentale de départ créée à partir d'un motif qui peut être modifié en
fonction des besoins de l'atelier.

Le Mind Mapping facilité est disponible en passant à cette perspective ou, s'il est couramment utilisé, il peut être ajouté à
un ensemble de perspectives défini par l'utilisateur à l'aide de Mes Perspectives facilité .

Cette perspective, comme d’autres, nécessite l’activation de la technologie appropriée, qui dans ce cas est le Mind
Mapping.

Au fur et à mesure que des termes importants seront découverts, ils pourraient être inscrits dans le Glossaire du Projet et,
même s'il n'y a pas de temps pour discuter et débattre de la signification convenue, les mots serviront de liste initiale
d'entités importantes dans le domaine. Alternativement, les termes peuvent être créés sous forme de blocs dans un
diagramme de définition Bloc et liés les uns aux autres avec des connecteurs qui décrivent les relations importantes entre
les termes.
Les parties prenantes peuvent également être modélisées et leurs relations organisationnelles les unes avec les autres
peuvent être décrites dans un diagramme . Il s’agit d’une technique utile qui permet aux principales parties prenantes de
s’identifier dans les modèles, ce qui crée une adhésion.

Créer Exigences
Enterprise Architect dispose d' support étendu pour le développement Exigences et fournit un certain nombre d'outils
spécialisés à cet effet. Comme pour tout contenu de modèle, un modélisateur est encouragé à vérifier si les Exigences ont
été entrées dans le référentiel par quelqu'un d'autre avant de se lancer dans la tâche de création de nouvelles Exigences .
Il est également possible que les Exigences aient été définies dans un autre outil tel qu'une feuille de calcul et puissent
être importées dans Enterprise Architect sans qu'il soit nécessaire de créer chaque exigence manuellement.

Enterprise Architect dispose de deux sites pour Exigences ; ils peuvent être créés dans le modèle en tant qu'élément qui
apparaîtra dans la fenêtre Navigateur , ou ils peuvent être créés à l'intérieur d'un autre élément en tant qu'exigence interne
ou responsabilité.

Exigences externes et internes

Enterprise Architect peut support tout type de processus d'exigence et permet de définir Exigences en tant qu'éléments du
modèle. Celles-ci sont appelées Exigences Externes , mais l'outil permet également de définir Exigences pour un élément
spécifique, et celles-ci sont appelées Exigences Internes . Un ingénieur qui souhaite définir un besoin utilisateur tel que :
Le système doit permettre la mise à jour des horaires des bus.
utiliserait une exigence externe. Un modélisateur souhaitant décrire comment un composant doit se comporter utiliserait
une exigence interne pour le composant telle que :
L'éditeur doit support Unicode .
Il y a souvent des conflits entre les analystes et les développeurs quant à savoir si une exigence doit être interne ou
externe, et Enterprise Architect permet de déplacer facilité Exigences internes pour qu'elles soient externes à l'élément.
Lorsqu'ils sont déplacés, ils restent liés à l'élément d'origine.

Catégories d'exigences
La spécification SysML fournit une liste non normative de catégories (types) d'exigences. Il s'agit Exigences stéréotypées
qui affinent ou étendent l'exigence SysML de base, fournissant un mécanisme pour créer Exigences qui servent un
objectif particulier ou décrivent un aspect particulier d'un système. Par exemple, Exigences physiques peuvent être
utilisées pour décrire certains aspects physiques d'un système, tels que le poids ou la taille d'un composant. Ces
catégories, ainsi que d'autres catégories créées par l'utilisateur, peuvent avoir un certain nombre de propriétés
supplémentaires définies, telles que :
· Type de risque
· Type de méthode de vérification
Enterprise Architect fournit commodément ces catégories d’exigences sous forme d’éléments sur les pages de la boîte à
outils de l’exigence SysML.

L'outil fournit également un système de profil sophistiqué et entièrement fonctionnel, permettant aux utilisateurs de créer
des extensions à l'exigence SysML de base et à un nombre illimité de catégories d'exigences définies par l'utilisateur et
applicables au domaine modélisation ou à l'espace de problèmes. Ces Exigences stéréotypées peuvent avoir des
propriétés définies par l'utilisateur ajoutées qui sont nécessaires pour modéliser l'élément d'exigence spécifique (ou un
autre élément de modèle).

Par exemple, une équipe peut décider d'inclure une propriété de volatilité à une exigence pour garantir que le travail ne
commence pas tant que l'exigence n'est pas stable (c'est-à-dire non volatile). Comme autre exemple, une équipe peut
créer des dispositifs médicaux et devoir se conformer à diverses normes statutaires. Chaque composant utilisé dans le

cadre de la solution peut devoir être conforme. Une propriété de niveau de conformité pourrait être créée et le composant
pourrait se voir attribuer un niveau indiquant sa conformité à partir d'une plage de valeurs définies dans un contrôle de
rotation ou une liste déroulante. Pour plus d'informations, consultez la rubrique d'aide de Developing Profiles .

Propriétés des exigences

Le développement et la gestion des exigences sont essentiels au succès de tout projet, et les propriétés des Exigences sont
importantes pour la priorisation et la manière dont elles seront élaborées et utilisées au sein d'une équipe de mise en
œuvre ou de développement. Tous les éléments Enterprise Architect ont des propriétés standard telles que Statut, Auteur
et Phase, mais l'élément Exigence possède des propriétés supplémentaires telles que Difficulté et Priorité.

Certains processus d'exigence prescriront des propriétés spécifiques telles que le dépositaire et la volatilité ( stabilité ) et
celles-ci peuvent être configurées à l'aide Valeur Étiquetés qui peuvent être appliquées à chaque exigence. Le champ «
Notes » pour une exigence a une signification particulière car il contient souvent une description formelle et
contractuelle de la façon dont le système doit se comporter ou fonctionner. Pour plus d’informations, consultez la
rubrique d’aide Element Property Displays .

Spécification
La spécification Exigences est un aspect important de l’évolution d’une Exigence. Il fournit un catalogue important
d'énoncés sur le comportement du système dans des conditions normales et anormales. Les Exigences intéresseront un
large éventail de parties prenantes, notamment :

· Responsables de l'ingénierie
· Architectes
· Créateurs
· Clients ou leurs substituts
· Ingénieurs système
· Ingénieurs logiciels
· Testeurs
· Responsables de la conformité
· Ingénieurs Qualité
· Ingénieurs de sécurité
Tous ces groupes auront à la fois une contribution aux Exigences et le besoin d'utiliser le catalogue des Exigences dans
leur travail. Il existe différentes manières de spécifier les exigences dans Enterprise Architect , notamment :

· Directement dans la fenêtre Navigateur

· Sur un diagramme
· Utilisation du Gestionnaire de Spécification
Nous examinerons le Gestionnaire de Spécification dans la section suivante, et vous verrez qu'il offre une grande
flexibilité lorsque vous travaillez avec Exigences et d'autres éléments à contenu textuel.

Rencontrez le Gestionnaire de Spécification

Le Gestionnaire de Spécification est un outil unique et efficace fournissant une vue de feuille de calcul ou de traitement
de texte qui peut être utilisée pour gérer n'importe quel élément, bien qu'il soit particulièrement utile lorsque vous
travaillez avec Exigences qui ont toujours un texte descriptif pour décrire l'Exigence en détail. De nouvelles Exigences
peuvent être créées avec des noms et des descriptions détaillées, et des propriétés telles que le statut et la priorité peuvent
être ajoutées ou modifiées à partir de listes déroulantes. Exigences existantes peuvent être visualisées et gérées dans une
vue pratique - comme diagrammes et des fenêtres - et les modifier dans le Gestionnaire de Spécification les modifiera à
tous les autres endroits du référentiel.

Le Gestionnaire de Spécification est l'outil parfait pour les analystes qui sont plus à l'aise avec du texte qu'avec
diagrammes et qui sont habitués à travailler avec un traitement de texte ou un tableur. Il présente l'avantage
supplémentaire que les Exigences font partie d'un modèle et peuvent être rattachées à d'autres éléments, notamment les
moteurs Métier , les parties prenantes et les composants de la solution. Dans cette image, on peut voir que l'état de
l'exigence et d'autres propriétés d'élément peuvent être modifiés à partir de listes déroulantes.

Il existe un large éventail d'options qui offrent une grande flexibilité lorsque vous travaillez avec le Gestionnaire de
Spécification , notamment l'affichage notes en colonnes comme dans une feuille de calcul ou en ligne comme dans un
document, et l'ajustement de la taille du texte. Ces options sont disponibles à partir du ruban « Spécification - Spécifier »,
qui s'affiche conditionnellement au lancement du Gestionnaire de Spécification .

Les filtres constituent un moyen utile de limiter l'affichage aux éléments contenant un mot ou un fragment de texte dans
une colonne sélectionnée. Dans cette illustration, un modélisateur a décidé de limiter l'affichage à toutes Exigences
contenant le mot « lumière » dans le texte de l'exigence. Il s'agit d'un excellent outil de productivité lorsque vous
travaillez avec de grands ensembles d' Exigences , et il peut être utilisé pour localiser toutes Exigences avec un statut,
une priorité, une complexité particulière ou même toutes Exigences appartenant à une partie prenante ou à une équipe
spécifiée, si elles ont été définies dans le modèle.

Un diagramme peut également être ouvert à partir du Gestionnaire de Spécification , vous permettant d'éditer les
éléments du diagramme en groupe. Il s’agit d’un point de vue convaincant et bien accueilli par certains membres du
personnel non technique, notamment les managers et les clients. Pour plus d'informations, consultez la rubrique d'aide du
Gestionnaire de Spécification .

Analyse
La phase d'analyse du développement des exigences garantit que les exigences découvertes lors de la phase d'élicitation
ont été correctement articulées et ont le format, le niveau de détail et les propriétés corrects, et forment un ensemble
correct et cohérent. En raison des sources et des méthodes d'élicitation disparates, les exigences enregistrées lors de la
phase d'élicitation nécessiteront un certain ajustement et un certain équilibrage - il est assez courant, par exemple, de
trouver des exigences répétées ou qui se chevauchent ou qu'un ingénieur système ait omis par inadvertance d'enregistrer
les exigences. préoccupations d’une ou plusieurs parties prenantes. Des outils tels que la Matrice des relations et la
fenêtre de traçabilité aideront à révéler les omissions et les problèmes liés aux exigences. Les fenêtres Discuss &
Révision et Chat & Mail - y compris le Mail de Modèle facilité - fourniront également des mécanismes pour discuter,
réviser et discuter des Exigences avec les autres membres de l'équipe.

Prioriser les Exigences

La priorisation Exigences est impérative pour le succès d'un projet, car elle garantit que les ressources d'analyse, de
développement, de test et de mise en œuvre sont concentrées sur les aspects les plus critiques du système. La priorisation
est un processus de décision qui attribue une priorité à chaque exigence ; le critère de catégorisation le plus courant est
valeur commerciale. valeur Métier est généralement déterminée par l'analyse coûts-avantages de la valeur que l'exigence
mise en œuvre produira pour l'organisation ou ses clients. D'autres facteurs peuvent être la conformité aux politiques ou
aux réglementations, l'urgence, le risque commercial ou technique et la probabilité de succès. Exigences peuvent être
visualisées dans un tableau Kanban qui peut être utilisé pour indiquer la priorité en déplaçant les éléments d'une voie de
backlog vers une voie de file d'attente et en permettant également de commander des articles dans les voies. Pour plus
d'informations, consultez la rubrique d'aide Kanban Boards .

Alternativement, des recherches ou Modèle Vues pourraient être utilisés pour créer une liste d'exigences basée sur
certains critères qui permettraient de prioriser les Exigences .

Propriété de priorité d'exigence

Il existe un large éventail de critères qui peuvent être utilisés pour la priorisation, et chaque organisation et projet utilise
généralement un certain type de moyenne pondérée pour déterminer la priorité. Enterprise Architect offre support
flexible et complète de la priorisation des exigences, car chaque élément possède une propriété « Priorité » intégrée qui
peut être définie pour indiquer sa priorité, permettant à l'utilisateur de sélectionner la priorité alloué dans une liste
déroulante.

La liste des priorités est commodément préchargée lorsque vous installez Enterprise Architect , mais celles-ci peuvent
être modifiées ou complètement révisées en fonction d'une organisation ou d'un projet. Ils peuvent même être importés
comme données de référence d'un projet précédent ou, si le projet en cours a été créé sur la base d'un gabarit , les
priorités de l'organisation pourraient être préchargées à partir du modèle de base. Ils peuvent être configurés à l’aide de
cette option du ruban :
Paramètres > Données de référence > Types Modèle > Types généraux > Priorité

Changer la priorité de manière collaborative

Le processus de sélection des critères et d'attribution des priorités est généralement collaboratif et se déroule souvent
dans le cadre d'un atelier avec les parties prenantes ou leurs représentants débattant de la catégorisation. Dans les
époques précédentes, il s'agissait d'un processus laborieux et difficile, mais Enterprise Architect dispose de
fonctionnalités utiles pour travailler avec les propriétés des exigences, notamment la priorité. Il existe un certain nombre
de fenêtres - notamment la liste Paquetage et la liste Diagramme - qui support de travailler avec les Exigences et de
modifier la priorité en ligne, en filtrant ou en triant automatiquement la liste des Exigences en fonction de la priorité
nouvellement attribuée. Le Gestionnaire de Spécification est un outil utile à cet effet, fournissant une interface textuelle
où les Exigences et leurs notes peuvent être consultées et les priorités peuvent être sélectionnées dans une liste
déroulante. L'interface affiche également un certain nombre d'autres propriétés généralement utiles pour la priorisation,
telles que le statut et la complexité. Pour plus d'informations, consultez la rubrique d'aide Editing Elements .

Lorsqu'une propriété d'exigence est modifiée et enregistrée dans une fenêtre ou diagramme , la propriété sera modifiée

dans toutes les autres vues et tous les autres utilisateurs consultant le référentiel pourront immédiatement voir la
modification.

Diagrammes du tableau de bord

Enterprise Architect dispose d'une série de diagrammes de tableau de bord qui peuvent être utilisés pour créer une vue
convaincante de la priorité des Exigences dans un Paquetage , avec la possibilité d'inclure des sous-packages. Il existe un
certain nombre de graphiques préconfigurés qui peuvent être utilisés pour afficher le rapport des valeurs de priorité pour
Exigences dans une partie du modèle. Les filtres ajoutent un autre niveau de configuration utilisateur, permettant à un
modélisateur, par exemple, d'exclure Exigences d'un statut particulier ou de garantir que seules Exigences de la phase en
cours sont affichées. Pour plus d'informations, consultez la rubrique d'aide Dashboard Diagrams .

Visualisation avec les tableaux Kanban

Enterprise Architect dispose d'un diagramme Kanban Board qui peut être utilisé pour gérer Exigences et d'autres
éléments de spécification ou de gestion de projet tels que le changement. Le Tableau Kanban est particulièrement utile
pour gérer la priorité des Exigences et d’autres éléments. Les éléments peuvent simplement être glissés sur le diagramme
puis entre les colonnes, permettant aux équipes de gérer et de visualiser les progrès réalisés par une exigence entre la
spécification et la mise en œuvre.

Le diagramme Kanban peut être configuré de sorte que lorsqu'un élément est glissé entre les colonnes, la priorité de
l'élément est automatiquement modifiée. Pour plus d'informations, consultez la rubrique d'aide Kanban Boards .

Validation
La validation Exigences est nécessaire pour garantir que les Exigences sont d'un niveau élevé, définissent correctement
le problème (ou l'opportunité) du Client et sont suffisantes pour que les équipes de mise en œuvre puissent concevoir et
mettre en œuvre le produit. Il est impératif que les exigences aient le niveau de qualité souhaité et soient complètes et
nécessaires. Il existe un certain nombre de façons de valider Exigences , mais les deux méthodes les plus courantes
consistent probablement à effectuer révisions en équipe et à attribuer des cas de test aux exigences.
Les révisions d'équipe sont généralement effectuées par des membres de l'équipe ou d'autres analystes qui ont une
certaine familiarité avec le domaine, mais qui n'étaient pas eux-mêmes responsables du développement ou de la gestion
des exigences. Enterprise Architect dispose d'un outil pratique pour faciliter ce processus, appelé Bibliothèque d'Équipe ,
qui fonctionne sur l'ensemble du modèle et permet réviseurs d'enregistrer leurs conclusions dans des documents de
discussion et de référencer les éléments du modèle. Il existe également un élément de liste de contrôle Exigences
disponible sur la page « Exigences étendues » de la boîte à outils Exigences , qui fournit un mécanisme utile pour vérifier
la qualité des Exigences .

Les cas Test peuvent être définis à plusieurs niveaux, depuis les tests d'acceptation utilisateur jusqu'aux tests unitaires. La
définition des cas de test au début du processus de développement des exigences crée une double vérification des
Exigences , car lorsque les cas de test sont définis, des problèmes avec les Exigences sont souvent découverts. Enterprise
Architect dispose d'un certain nombre de facilités pour définir des cas de test et un modélisateur peut sélectionner celui
qui est le plus approprié pour l'entreprise.

Visualiser Exigences
Exigences peuvent être visualisées de différentes manières en utilisant différentes fonctionnalités du produit. Certaines
méthodes permettent à l'utilisateur de créer de nouvelles exigences et de modifier des exigences existantes, tandis que
d'autres fournissent simplement un moyen de visualiser les exigences. Exigences , comme tous les éléments du SysML,
peuvent faire partie d'un graphe et bon nombre des sémantiques importantes sont exprimées dans ces relations ; par
exemple la relation entre une exigence et les cas de test qui la vérifient. Il est cependant assez courant que les analystes
des exigences, les gestionnaires et autres parties prenantes souhaitent visualiser les exigences indépendamment de toute
relation dans laquelle une exigence pourrait participer. Nous examinerons maintenant un certain nombre de ces facilités
et d'autres seront abordées dans la section Visualisation. Sujet Relations avec les exigences.

Diagrammes Exigences
Le diagramme Exigences peut être utilisé pour visualiser Exigences et leurs relations avec d'autres éléments, y compris
d'autres Exigences . Vous pouvez bien sûr visualiser Exigences de plusieurs autres manières, mais pour de nombreuses
parties prenantes, le diagramme Exigences sera plus attrayant car il fournit un moyen graphique de visualiser les
connexions des Exigences avec d'autres parties importantes du modèle, notamment les parties prenantes, l'architecture, la
conception. et des tests. Ce diagramme montre comment Exigences peuvent être considérées ainsi que leur connexion
avec d'autres éléments. Une exigence stipulant que les véhicules non autorisés ne doivent pas être autorisés à accéder au
parking est alloué à l'activité « Restreindre les véhicules non autorisés », qui à son tour est alloué à un Bloc représentant
la Boom Gate.

Un diagramme Exigences peut être créé à partir d'un certain nombre d'emplacements différents dans l'interface
utilisateur, y compris à partir de l'option du ruban « Conception > Diagramme > Ajouter Diagramme ».
La dialogue ' Nouveau Diagramme ' s'affichera et le diagramme Exigences pourra être sélectionné dans la liste des types
diagramme SysML. Pour plus d'informations, voir la rubrique d'aide SysML Requirements Modeling .

Gestionnaire de Spécification
Le Gestionnaire de Spécification est l'outil central pour travailler avec Exigences dans Enterprise Architect et a été conçu
dès le départ pour être un outil permettant de créer et de gérer Exigences via une interface intuitive et complète. Pour les
ingénieurs ou autres parties prenantes habitués à travailler avec des feuilles de calcul ou des documents de traitement de
texte, l'outil semblera naturel et émule ces deux modes de visualisation, permettant à un utilisateur de basculer entre le
mode feuille de calcul et le mode document.

Le Gestionnaire de Spécification peut être ouvert depuis le ruban : 'Design > Paquetage > Spécification Vue '.
Le Gestionnaire de Spécification peut être utilisé pour visualiser tout type d'élément, mais est particulièrement adapté
aux éléments à forte composante textuelle comme Exigences . Tous les éléments modifiés dans l'outil le seront également
automatiquement dans diagrammes Exigences , dans la fenêtre Navigateur et dans d'autres catalogues tels que tableaux .
Pour plus d’informations, consultez le Specification Manager Rubrique d'aide.

Navigateurs et Vues
Le Navigateur est l'outil de navigation central, qui peut être utilisé pour structurer et explorer le contenu d'un référentiel,
y compris en travaillant avec les exigences. Le Navigateur comporte un certain nombre d'onglets qui permettent de
visualiser le contenu du référentiel de manière particulière. Nous avons examiné le Navigateur dans un sujet précédent,
mais nous parlerons de sa pertinence pour la visualisation des exigences.
La plupart des ingénieurs système essaieront de conserver leurs exigences pour un projet ou une entreprise particulière
en un seul endroit, bien qu'il puisse y avoir des circonstances dans lesquelles elles doivent être séparées ; par exemple,
pour des raisons contractuelles ou de calendrier. Une fois qu'un Paquetage Exigences a été sélectionné dans l'onglet
'Projet', un utilisateur peut basculer vers le 'Contexte'. pour obtenir une vue ciblée - supprimant efficacement le bruit des
autres éléments en dehors de ce contexte. Une exigence individuelle peut ensuite être sélectionnée et l'onglet « Détails »
sélectionné dans la fenêtre Inspecteur pour se concentrer sur les propriétés de l'exigence sélectionnée.
Les éléments et relations contenus dans un diagramme ouvert peuvent également être visualisés via l'onglet « Diagramme
» du Navigateur , offrant une manière alternative de visualiser le contenu d'un diagramme .

Tout Paquetage ou diagramme peut également être visualisé de différentes manières, y compris la vue en liste qui fournit
une vue souvent appréciée des éléments d'une liste, semblable à une feuille de calcul où les exigences sont répertoriées
en lignes et leurs propriétés sont répertoriées en colonnes. .

Matrice de relation
La Matrice de relations est un outil précieux pour visualiser les connexions entre les éléments de deux Paquetages
quelconques, dans une interface ressemblant à une feuille de calcul avec des lignes et des colonnes. L'outil est
particulièrement utile lorsqu'il est utilisé avec Exigences et permet à un ingénieur de voir comment Exigences sont liées à
d'autres éléments, y compris d'autres Exigences .

La Matrice de Relation peut être ouverte à partir de l'option du ruban 'Conception > Paquetage > Paquetage / Matrice '.
Sélectionnez si le Paquetage actuel est le Paquetage source, Paquetage cible ou les deux.
Lorsqu'une relation existe, une icône en forme de flèche s'affiche dans la cellule à l'intersection des éléments source et
cible, la pointe de flèche indiquant la direction de la relation. La matrice peut également être configurée pour mettre en
évidence les lignes ou colonnes qui n'ont aucune relation, dans une couleur distincte. Cette option et d'autres peuvent être
configurées dans la fenêtre Options (cliquez sur le bouton Options dans l'en-tête de la Matrice de relations).

Ces options vous permettent de personnaliser la façon dont la matrice est affichée, notamment si les éléments sont triés
ou si leurs noms sont préfixés par le nom Paquetage , et si les lignes et colonnes des éléments source et cible sans
connexions sont mises en surbrillance. Pour plus d’informations, consultez la rubrique d’aide Relationship Matrix .

Exigences Tableaux
Tableaux Exigences sont des vues ressemblant à des feuilles de calcul qui peuvent être créées à l'aide d'une instruction
SQL pour sélectionner Exigences (ou tout autre élément) en fonction d'une instruction select, qui filtre efficacement un
groupe particulier d' Exigences . Par exemple, un tableau pourrait être utilisé pour afficher toutes Exigences liées au
sous-système d'alimentation qui sont approuvées et hautement prioritaires ou pour la décomposition des exigences de
performance. N'importe quel nombre de tableaux peut être créé et ils sont actualisés dynamiquement à mesure que les
propriétés sous-jacentes sont mises à jour dans le référentiel. Cela offre plus de flexibilité que la vue Liste en raison de la
possibilité de sélectionner un groupe d' Exigences n'importe où dans le référentiel en fonction de critères spécifiés.

Gérer Exigences
Il s'agit des activités visant à maintenir un ensemble d'exigences qui représentent un accord ou un accord entre l'équipe
de projet et le client. Cela implique également de s'assurer que les exigences sont acceptables pour les équipes de
conception et de mise en œuvre et qu'elles sont suffisantes pour que ce qu'elles spécifient puisse être mis en œuvre dans
des systèmes commerciaux, logiciels ou matériels fonctionnels. Enterprise Architect est une plate-forme sophistiquée
pour gérer les exigences, et quel que soit le domaine, la taille du projet ou la méthode suivie, il existe des outils qui
faciliteront la gestion même de grands référentiels d'exigences dans des projets complexes.

Traçage des Exigences

La plupart des processus d'exigence exigent que Exigences soient tracées depuis les concepts de haut niveau tels que les
moteurs Métier , les visions et les objectifs jusqu'aux parties des composants qui les mettent en œuvre. Pour de nombreux
projets, il s'agit d'un problème insoluble car la plupart des informations se trouvent dans un ensemble d'outils hétérogènes
tels que des documents de traitement de texte, des feuilles de calcul, des outils diagramme , des outils de présentation
d'entreprise, etc. Certains Gestionnaires de Projet tentent de résoudre le problème en créant un tableur qui fait office de
registre de toutes les informations disparates mais la gestion de ce fichier mobilise des ressources considérables du projet
et le fichier est presque impossible à tenir à jour. Avec Enterprise Architect il est possible de modéliser toutes ces
informations de projet dans un seul outil et de créer des traces faciles à entretenir et analysables entre tous les éléments,
depuis l'énoncé de mission de l'organisation jusqu'au niveau du code de programmation, si nécessaire. .

Visualiser les traces dans diagrammes

Que vous ayez saisi les Exigences du projet à l'aide d'un diagramme , à l'aide d'un outil textuel tel que le Gestionnaire de
Spécification , ou en les important depuis un autre outil, la visualisation des traces d'exigences dans un diagramme
permet d'avoir une vision facilement compréhensible de leurs relations. Les diagrammes peuvent être créés facilement en
faisant glisser et en déposant des éléments depuis la fenêtre Navigateur , ou automatiquement en utilisant l'option
« Insérer des éléments associés ». Cette fonction peut être configurée et utilisée pour dessiner un graphique d'éléments à
n'importe quelle profondeur et peut être limitée à certains types d'éléments et de connecteurs. Il s'agit d'un outil de
productivité pratique dans un environnement d'équipe, et même les modélisateurs ayant une connaissance approfondie du
domaine et du référentiel sont surpris par les connexions affichées dans les diagrammes .

Visualiser les traces à l'aide de la Matrice de relations

La Matrice des Relations offre une manière alternative de visualiser les relations entre Exigences et d'autres éléments, ou
même entre différents niveaux ou types d'Exigences. Il est assez courant que certaines parties prenantes préfèrent une vue
sous forme de feuille de calcul des Exigences et de leurs relations, et la Matrice des Relations constitue un excellent
moyen de présenter les relations sans recourir à un diagramme . Dans les méthodes d'exigences basées sur les cas
d'utilisation, les cas d'utilisation sont censés réaliser une ou plusieurs Exigences , et ces relations peuvent être affichées
visuellement dans la Matrice des relations. La liste des cas d'utilisation apparaîtrait sur un axe de la matrice et les
Exigences seraient répertoriées sur l'autre axe. Un marqueur à l'intersection d'une ligne et d'une colonne s'afficherait si
une relation existe, indiquant qu'un cas d'utilisation particulier répond à une exigence. Relations entre les éléments
peuvent être créées ou supprimées à l'aide de la Matrice de relations, et la Matrice peut être enregistrée et rouverte à tout
moment ou enregistrée dans un fichier CSV afin de pouvoir être ouverte dans une feuille de calcul. Une documentation
peut également être créée qui inclut la Matrice relationnelle, fournissant un outil de communication utile pour les
personnes qui n'ont pas accès au modèle.

Visualisation des traces à l'aide de la fenêtre Traçabilité

Bien que diagrammes et la Matrice de relations permettent aux modélisateurs de visualiser les traces entre les éléments
d'exigence, il est possible que les créateurs de ces vues du référentiel aient délibérément omis des éléments de la vue. Par
exemple, un diagramme n’a pas besoin de montrer toutes les exigences appartenant à une partie prenante particulière. La
fenêtre Traçabilité présentera cependant une vue complète et intégrale des relations entre les éléments. Les relations entre
les éléments seront affichées quel que soit l'emplacement des éléments dans la fenêtre Navigateur .

Visualisation des traces à l'aide de la fenêtre Relations

Les modélisateurs choisissent souvent de masquer une ou plusieurs relations sur un diagramme dans le but de rendre le
diagramme plus simple à comprendre ou de masquer des détails. La fenêtre Relations est une fenêtre utile à ouvrir car
elle affichera toutes les relations qui existent entre les éléments du diagramme indiquant s'ils sont visibles ou masqués
dans le diagramme .

Si les relations ont été masquées dans un diagramme , elles peuvent être rendues visibles en sélectionnant l'option
'Afficher Relations ' sur la page 'Connecteurs' de la boîte dialogue ' Propriétés ' du diagramme .

Exigences de suivi
Le statut d’une exigence est un indicateur fondamental de sa position dans le processus de développement de l’exigence.
Par exemple, les exigences qui ont le statut « Proposé » indiquent qu'elles ne sont pas encore prêtes et disponibles pour le
début des travaux de développement. Enterprise Architect dispose d'une variété d'outils pour permettre le suivi, l'analyse
et la gestion des statuts, à commencer par le fait que chaque exigence peut se voir attribuer un statut et que la liste des
codes de statut est entièrement configurable. L'état est facilement affiché dans des vues de liste des exigences, y compris
lors de l'utilisation du Gestionnaire de Spécification . Il existe également un ensemble de tableaux de bord et de
graphiques prédéfinis et extensibles qui peuvent être utilisés pour obtenir une représentation visuelle convaincante de
l'état et d'autres propriétés des exigences.

Outils de suivi des exigences

Outil Description

Codes d'état Les codes de statut sont une liste contrôlée de statuts qui peuvent être appliqués à
n'importe quel élément, y compris Exigences . Enterprise Architect est livré avec
une liste prédéfinie de codes, mais la liste peut être configurée et les codes de la
liste peuvent être modifiés et supprimés et de nouveaux codes peuvent être ajoutés.
L'état des Exigences peut être affiché dans un diagramme sous la forme d'une bande
codée en couleur sur le côté de l'élément.

Tableaux et graphiques des diagrammes de tableau de bord sont un type diagramme étendu et permettent de
tableaux de bord créer des tableaux et des graphiques de haute qualité pour afficher les informations
du référentiel de manière visuellement convaincante. N'importe quel nombre de
diagrammes et de graphiques peuvent être créés et les données peuvent provenir de
n'importe quel niveau de la hiérarchie du référentiel Paquetage . Enterprise
Architect est livré avec une page de boîte à outils de tableaux et de graphiques
préconfigurés, mais de nouveaux graphiques peuvent être créés en fonction de
n'importe quelle information du référentiel.

Gérer Exigences changeantes

Il est inévitable que les exigences changent au cours des phases de spécification et de solution d'un projet, et la plupart
des processus de gestion des exigences disposent d'un certain type de mécanismes pour adopter ces changements. En
règle générale, un ensemble d'exigences aura été spécifié et préparé pour que les équipes de solutions puissent les mettre
en œuvre ; toutes les modifications ultérieures sont spécifiées sous forme de demandes de modification. Quelle que soit
la rigueur du processus utilisé, des changements involontaires se produiront et devront être gérés en même temps que les
demandes de changement. Enterprise Architect est une plateforme sophistiquée de gestion des exigences, dotée d'une
gamme d'outils pour aider le responsable des exigences. Les demandes de changement peuvent être gérées dans la fenêtre
Maintenance, qui permet d'enregistrer et de décrire le changement demandé, ainsi que celui qui l'a demandé, quand il a
été effectué et celui qui a effectué le changement. Les modifications involontaires peuvent être découvertes et analysées à
l'aide d'un certain nombre de fonctionnalités d'outils, notamment Auditing, Lignes de base et Contrôle de Version ; ces
outils ont des fonctionnalités qui se chevauchent et peuvent être utilisés isolément ou ensemble. Le système de sécurité
intégré aidera également à empêcher les modifications accidentelles des modèles, en permettant aux modélisateurs de
verrouiller intentionnellement Paquetages et les éléments du modèle.

Mécanismes de gestion des exigences changeantes

Mécanisme Description

Éléments de tâche et Les modifications des exigences peuvent survenir par inadvertance, mais il est plus
d'effort de changement courant qu'il y ait un changement intentionnel en réponse à une grande variété de
d'élément facteurs tels que la révision de leurs besoins par les parties prenantes, l'évolution de
l'entreprise ou la mauvaise compréhension d'un problème. Les modifications
involontaires peuvent être détectées à l'aide d'un certain nombre d'outils, mais des
modifications délibérées peuvent être attribuées à l'aide de l'élément de
modification, qui peut être enregistré pour chaque élément. Une fois l'impact du
changement analysé, des tâches peuvent être créées pour spécifier ce qui doit être
fait pour mettre en œuvre le changement et l'effort peut être attribué à l'aide de
l'élément Exigences Effort.

Audit L'audit est un outil intégré qui, lorsqu'il est activé, enregistre automatiquement les
modifications apportées au référentiel. Il propose un certain nombre de modes et de
vues différents et peut être configuré pour faciliter la gestion des Exigences . Il peut
suivre ce qui a été modifié dans le modèle, qui a effectué la modification et quand
elle a été effectuée, en affichant les vues avant et après. Ainsi, si le texte d’une
exigence était mis à jour ou si son statut était modifié, cela serait enregistré. La
fonctionnalité d'audit chevauche celle de l'outil Baseline, mais contrairement à

l'outil Baseline, les modifications sont enregistrées automatiquement et chaque

changement discret est enregistré. En revanche, l'outil Baseline comparera
uniquement le modèle actuel à une référence, quel que soit le nombre de
modifications apportées entre-temps. L'audit ne permettra pas d'évaluer l'impact des
changements, mais simplement les changements survenus. Une fois les
changements établis, des outils tels que la Matrice relationnelle peuvent être utilisés
pour déterminer l’impact.

Contrôle de Version Contrôle de Version peut être implémenté dans Enterprise Architect pour gérer les
modifications et les révisions de tout Paquetage , y compris Paquetages Exigences .
Une fois mises en œuvre, les modifications apportées à Exigences seront
enregistrées et un analyste des exigences pourra visualiser la version précédente et
revenir à ces versions si nécessaire. Il existe un certain chevauchement entre
fonctionnalité de cet outil et Auditing et Lignes de base . La différence entre cette
facilité et l'Audit est que l'Audit enregistre simplement les modifications mais ne
vous permet pas de revenir à une version précédente. La différence entre Contrôle
de Version et Lignes de base est qu'un modélisateur doit créer intentionnellement
une ligne de base alors qu'avec Contrôle de Version les modifications sont
enregistrées automatiquement en arrière-plan. De plus, avec Lignes de base les
changements intervenus ne sont pas enregistrés, juste la différence entre l'exigence
actuelle et celle capturée dans la Ligne de base.

Lignes de base Lignes de base fournissent un mécanisme polyvalent pour gérer les modifications
apportées aux Exigences . N'importe quel nombre de lignes de base peut être créé et
lorsque les exigences sont modifiées, ces exigences modifiées peuvent être
comparées à l'une des lignes de base . Lignes de base sont généralement créées à
des étapes importantes d'un projet, par exemple après une réunion des parties
prenantes ou avant le début d'une itération de développement. Lorsque des
différences sont constatées et que ces changements n'étaient pas intentionnels ou
contreviennent aux pratiques de gestion de projet, les exigences de la référence
peuvent être rétablies dans le modèle actuel. Lignes de base n'aideront pas à évaluer
l'impact d'un changement, mais une fois qu'un changement a été identifié, des outils
tels que la Matrice de relation et les traces d'éléments peuvent être utilisés pour
déterminer l'impact d'un changement.

Analyse d'impact des changements

Lorsque le développement d’un système a commencé et que les exigences changent, le changement aura un impact et cet
effet devra être déterminé, compris et géré. Avoir une traçabilité établie à la fois pour les éléments de processus
ascendant tels que les parties prenantes et les pilotes Métier et pour les éléments de processus descendant tels que les cas
d'utilisation, les composants, les cas Test et les opérations de code source est essentiel pour déterminer l'impact du
changement. Enterprise Architect dispose d'un certain nombre de facilités qui peuvent vous aider, notamment la
possibilité de visualiser des traces dans diagrammes , une Matrice de relations, une fenêtre de traçabilité, des éléments de
changement, de tâche et d'effort qui peuvent être utilisés pour enregistrer l'impact et ce qui est requis pour le mettre en
œuvre. .

Outils pour enregistrer et analyser l’impact du changement

Outil Description

Analyse à l'aide de traces La capacité de visualiser les exigences et la manière dont elles sont connectées à
d'exigences d’autres éléments est un outil pratique pour analyser l’impact du changement.
Exigences forment souvent une hiérarchie et lorsqu'une exigence est affectée, cela a
généralement un effet d'entraînement sur les enfants de l'exigence et il est très utile
de pouvoir visualiser cela dans un diagramme ou dans une hiérarchie. Exigences
sont également généralement attribuées aux éléments de processus ascendants et
descendants et un diagramme fournit un moyen de visualiser et d'analyser ces
connexions. La fonction Insérer des éléments associés peut découvrir ces
connexions et dessiner et disposition automatiquement un diagramme permettant au
modélisateur de passer son temps à analyser l'impact.

Analyse à l'aide d'une La Matrice de Relation peut être utilisée pour visualiser les exigences et leurs
matrice de relations connexions en plaçant l'Exigence sur un axe de la matrice et les éléments connectés
sur l'autre. Cette méthode est très utile dans les ateliers lorsque vous travaillez avec
des personnes qui ne sont peut-être pas familiarisées avec les langages modélisation
tels que UML ou qui travaillent mieux avec des vues de type tableur. N'importe
quel nombre de matrices peut être créé et leurs spécifications peuvent être stockées
afin qu'elles puissent être facilement rappelées.

Analyse via la fenêtre de La fenêtre Traçabilité est une fenêtre pratique qui montre la hiérarchie des éléments
traçabilité dans le Référentiel . Il est particulièrement utile car il montre de manière
inconditionnelle comment les éléments sont liés les uns aux autres. D'autres vues du
référentiel peuvent être configurées uniquement pour afficher des éléments
particuliers dans le but de communiquer une idée, tandis que la fenêtre Traçabilité
affichera toutes les relations auxquelles participe un élément, ce qui la rend
particulièrement utile pour analyser l'impact du changement.

Volatilité des exigences

Il existe des pressions de plus en plus fortes sur le marché pour lancer les produits et les systèmes le plus tôt possible, ce
qui oblige les équipes de projet à développer, tester et déployer des produits dans des délais de plus en plus courts. Les
processus d'exigences ont considérablement changé ces dernières années pour garantir que des spécifications stables,
correctes et bien articulées soient fournies aux architectes, concepteurs et développeurs lorsqu'ils en ont besoin. On a
évolué vers des processus itératifs et incrémentaux, ce qui nécessite de fournir un ensemble d'exigences stables pour
chaque itération. L'agitation des exigences indique souvent qu'un problème n'est pas clairement compris, que les parties
prenantes n'ont pas été compromises et qu'il existe des problèmes politiques non résolus, que la portée n'est pas définie
ou que l'entreprise elle-même est en fluctuation. Enterprise Architect dispose d'un certain nombre de mécanismes qui
peuvent être utilisés pour résoudre ce problème. Enterprise Architect n'a pas de propriété intégrée pour la volatilité des
exigences (stabilité), mais en utilisant le mécanisme d'extension UML à usage général de Valeur Étiquetés , une balise
pourrait être créée pour enregistrer cette propriété.
Note : les exigences internes ont une propriété de stabilité, mais pas les exigences externes.

Mécanismes de gestion de la volatilité des exigences

Mécanisme Description

La volatilité comme Valeur Enterprise Architect fournit une série de propriétés pour Exigences , mais des
Étiquetée propriétés supplémentaires peuvent être créées pour enregistrer d'autres propriétés
telles que la volatilité d'une exigence ou la source de l'exigence. Ceci est réalisé à
l'aide du mécanisme UML Valeur Étiquetée , qui permet à tout élément, y compris
Exigences , de se voir appliquer une ou plusieurs balises, représentant une propriété
à laquelle une valeur peut être attribuée. Enterprise Architect a étendu ce
mécanisme et permet au modélisateur de créer une liste de valeurs qui peuvent être
choisies dans une liste déroulante à l'aide des Valeur Étiquetés structurées
prédéfinies. Cela permet à une équipe de définir sa propre liste de valeurs de
volatilité, telles que extrême, élevée, moyennement basse, minimale.

Utilisation Lignes de base Baseline facilité est un outil efficace qui permet à un utilisateur de prendre un
instantané d'un modèle ou plus généralement d'un fragment de modèle, puis, au fur
et à mesure du développement du modèle, de comparer la nouvelle version du
modèle à la ligne de base, identifiant ainsi tout ce qui a changé depuis le la ligne de
base a été prise. Lignes de base ont une applicabilité générale mais sont
particulièrement utiles pour la gestion des exigences où les exigences sont souvent
considérées comme approuvées ou gelées et toute modification de celles-ci doit être
enregistrée comme un changement. L'outil Baseline dispose d'un utilitaire de
comparaison qui répertorie de manière pratique les modifications entre le modèle
actuel et la ligne de base.

Recherches d'exigences de Enterprise Architect dispose d'une facilité de recherche sophistiquée qui permet à
barattage un utilisateur de rechercher soit dans un Paquetage sélectionné, soit dans l'ensemble
du référentiel, pour localiser les éléments qui répondent à des critères précis. Cela
peut être utilisé pour localiser les exigences qui n'ont pas changé en recherchant un
changement dans la date de modification avant une date spécifiée, fournissant ainsi
une liste d'exigences stables. Alternativement, si la volatilité a été définie à l'aide
d'une Valeur Étiquetée , tous les éléments ayant une volatilité spécifiée pourraient
être localisés. La recherche facilité renvoie une liste d'éléments repérables dans la
fenêtre Navigateur ; la recherche peut être utilisée comme base d'un Modèle Vue
permettant de visualiser des exigences volatiles ou non volatiles.

Réutilisation des exigences

Le concept de réutilisation des artefacts d'un processus de développement de système a été abordé dans de nombreux
articles et manuels, mais s'est traditionnellement limité aux composants logiciels. Ces dernières années, l’idée de
réutiliser les spécifications, y compris les exigences, a commencé à gagner du terrain. La réutilisation est
particulièrement importante lorsque les organisations créent une famille de produits dotés de fonctionnalités similaires,
ou lorsqu'il existe une communauté d'utilisateurs au sein d'un secteur ou d'un domaine. D'autres types d'exigences, telles
que les exigences de sécurité et réglementaires, s'appliqueront généralement à un certain nombre de projets. Règles
Métier et les Préoccupations des Parties Prenantes s’appliqueront également généralement à de nombreux projets et il est
préférable de les cataloguer en dehors des structures de projet individuelles. Enterprise Architect fournit un certain
nombre de mécanismes sophistiqués pour gérer la réutilisation des éléments dans les projets, notamment la structuration
du référentiel pour la réutilisation, l'importation d'exigences à partir d'autres sources et un Service d'Actifs Réutilisables .

Mécanisme de réutilisation des exigences

Mécanisme Description

Structuration du référentiel Lorsque vous créez un référentiel, vous avez le choix de le structurer pour un seul
pour la réutilisation des projet ou pour plusieurs projets, qui peuvent à leur tour être organisés par plusieurs
exigences programmes de travail. Enterprise Architect donne au modélisateur un contrôle
complet sur la façon dont le référentiel est structuré, permettant de configurer
Paquetages au-dessus du niveau des projets où certaines exigences telles que
Exigences Métier , réglementaires et architecturales peuvent être ajoutées.

Création d'un modèle de Lorsque vous créez un nouveau référentiel dans Enterprise Architect , vous avez la
base possibilité de créer un modèle vierge à l'aide de l' Assistant de Modèle (onglet Page
Démarrage 'Créer à partir de Motif ') pour vous aider à mettre en place une structure
de référentiel, ou vous pouvez utiliser un modèle de base comme un gabarit pour le
nouveau modèle. Le modèle de base est un bon endroit pour stocker des actifs
réutilisables tels que Métier , Exigences réglementaires et architecturales, et les
Politiques et Règles Métier .

Importation d'exigences à Il est assez courant d'avoir un certain nombre de référentiels Enterprise Architect
partir d'autres modèles dans une organisation et il est très facile de copier et de réutiliser Exigences (ou
tout autre élément) d'un modèle dans un autre. Ceci peut être réalisé en copiant
simplement une sélection d' Exigences ou un Paquetage entier d'un référentiel à un
autre, voire d'un projet à un autre dans le même référentiel. Enterprise Architect
fonctionne de la même manière que n'importe quel autre programme Windows ,
copiant simplement la sélection dans le presse-papiers, puis permettant de la coller
à un autre emplacement du même modèle ou dans un autre référentiel ouvert.

Utiliser le Service d'Actifs Le Service d'Actifs Réutilisables (RAS) est particulièrement utile pour les équipes
Réutilisables distribuées et fournit un mécanisme simple et pratique permettant aux
modélisateurs de distribuer ou de télécharger des structures et des éléments de
modèles réutilisables tels que Exigences via un référentiel partagé, accessible via
une connexion Pro Cloud Server . Au niveau de l'entreprise ou de l'organisation,
Exigences pourraient être stockées dans le RAS et différentes équipes pourraient les
intégrer dans leurs modèles, la gouvernance des actifs serait généralement gérée par
le propriétaire de l'actif (registre) au niveau du Service d'Actifs Réutilisables .

Relations avec les exigences

Enterprise Architect supporte toutes les relations d'exigences SysML, qui peuvent être visualisées à différents endroits de
l'interface utilisateur, offrant ainsi une manière flexible de travailler avec ces connecteurs importants. Les relations entre
les éléments (y compris Exigences ) ne sont pas visibles dans la fenêtre Navigateur , car cela encombrerait les éléments
alors qu'il existe des moyens plus efficaces de visualiser les connexions.
La fenêtre Relations est utile pour être ancrée lors de la visualisation des éléments, soit dans la fenêtre Navigateur , soit
dans un diagramme . Au fur et à mesure qu'un élément est sélectionné dans la fenêtre Navigateur ou dans un diagramme ,
le contexte change et la fenêtre Relations affichera uniquement les relations qui existent entre l'élément sélectionné et les
autres éléments du modèle, y compris les autres Exigences .
Les relations entre Exigences et d'autres éléments, y compris d'autres Exigences , peuvent être visualisées dans n'importe
quel diagramme , y compris diagrammes Exigences , de trois manières différentes :
· Un connecteur entre deux éléments
· Un compartiment dans l'élément Exigence
· Une notation de légende sous la forme d'une note attachée soit à une exigence, soit à un autre élément de modèle
Les trois notations diagramme ont leur objectif et offrent au modélisateur la flexibilité de choisir la représentation
appropriée pour un objectif et un public particuliers.
La relation tracée entre deux éléments visibles dans un diagramme est la manière la plus courante de visualiser les
relations entre exigences ; la ligne pointillée est tracée du client (l'élément dépendant) au fournisseur (l'élément
fournisseur). Ainsi, dans cet exemple, le Bloc « Strip Illumination » est le client et cela dépend de l'exigence de « faible
luminosité visibilité », donc la flèche pointe du Bloc (client) vers l'exigence (fournisseur).

Notez également dans cet exemple que le modélisateur a choisi d'afficher le compartiment Pièces, montrant les Pièces
qui composent le Bloc , et le compartiment Notes qui décrit le Bloc . Une justification a également été ajoutée pour
qualifier la relation « Satisfaire » et pour expliquer pourquoi le Bloc a été choisi dans le contexte des normes.
Les compartiments peuvent être utilisés pour afficher les relations auxquelles participe une exigence, ce qui constitue un
moyen compact et utile de visualiser les relations entre les exigences sans avoir besoin d'inclure les éléments associés
dans le diagramme .

La liste des compartiments visibles peut être configurée pour chaque élément diagramme ou pour l'ensemble diagramme ,
offrant ainsi un contrôle granulaire précis sur la façon dont les relations sont visualisées.

Alternativement, une notation Légende peut être utilisée pour afficher la relation dans une note attachée soit à l'élément
Exigence, soit à l'élément dépendant auquel la relation se rapporte. Cette notation est particulièrement utile lorsque des
éléments apparaissent dans diagrammes dans lesquels les affichages des connecteurs ou des compartiments ne sont pas
adaptés, comme un diagramme Bloc internes, un diagramme Séquence ou diagramme de cas d'utilisation, ou dans
d'autres diagrammes selon ce qu'un modélisateur juge approprié. Les relations d'exigence sont binaires, ce qui signifie
qu'elles ont deux extrémités : un fournisseur et un client. Cela signifie que l'appel peut être attaché soit à une exigence,
soit à l'élément de modèle associé qui, selon la relation, peut être un Bloc , un scénario Test , un cas d'utilisation ou tout
autre élément de modèle, y compris une autre exigence.
Dans ce diagramme , le modélisateur se concentre sur l'exigence et l'élément Bloc est répertorié dans la note stéréotypée
comme « satisfaitBy ».

Dans ce diagramme , l'attention du modélisateur s'est portée sur un Bloc et l'élément Exigence est répertorié dans la note
stéréotypée comme « satisfait ».

La section suivante détaille les relations d'exigence, en fournissant un exemple de chaque relation.

Ajout de raffinement à une exigence

La relation Affiner est une relation entre une exigence et un autre élément de modèle qui ajoute un raffinement ou des
informations supplémentaires permettant de clarifier l'exigence afin que sa signification soit plus évidente. La relation
Affiner est disponible depuis la page ' Relations ' de la boîte à outils SysML Exigences .

La relation Refine peut être établie entre une exigence et n'importe quel élément de modèle tel qu'un cas d'utilisation, une
Statemachine ou une activité. Le choix de l'élément du modèle dépendra des informations exprimées dans l'exigence et
de la discrétion du modélisateur ou de l'ingénieur.

Dans cet exemple, le cas d'utilisation n'étend ni n'embellit l'exigence mais ajoute plutôt des détails sous forme de
descriptions et de scénarios qui faciliteront la compréhension de la signification de l'exigence.

Relation de confinement
Le nom de la relation de confinement décrit bien son objectif : il est utilisé pour montrer qu'une ou plusieurs Exigences
sont contenues dans, ou sont regroupées par, une autre Exigence de niveau supérieur. Il s’agit d’une relation
fondamentale et très utilisée lors modélisation des exigences de tout système de complexité même modérée. Un grand
système peut avoir des milliers, voire des dizaines de milliers d’exigences, et il est préférable de les regrouper dans des
hiérarchies. Une alternative à l'utilisation de la relation Containment est de regrouper Exigences à l'aide Paquetages .
Cette méthode fonctionne lorsqu'il n'y a que deux niveaux dans la hiérarchie ou lorsque vous regroupez Exigences par
type (par exemple partie prenante ou physique), mais elle présente des limites lorsqu'elle est utilisée de manière plus
étendue.
La relation de confinement est disponible à partir de la page Relations de la boîte à outils SysML Exigences .

Ce diagramme montre l'utilisation de la relation de confinement pour montrer deux Exigences de niveau inférieur qui
sont « contenues » par une exigence de niveau supérieur.

Le confinement des Exigences peut également être visualisé dans la fenêtre Navigateur , où le confinement est représenté
par des éléments imbriqués ou, plus formellement, les éléments contenus sont les enfants d'une autre Exigence. Ce
nivellement est possible pour tous les éléments du référentiel, mais a une signification particulière avec Exigences . Cette
image montre les mêmes Exigences que dans le diagramme précédent, mais dans la fenêtre Navigateur .

Note que l'imbrication des Exigences dans la fenêtre Navigateur ne crée pas de relations de Confinement entre Exigences
. En fait, il est possible que les deux méthodes différentes ne soient pas synchronisées car ce sont des mécanismes
indépendants.

Copier Exigences existantes

La relation Copie est une relation entre deux Exigences ; il est utilisé pour montrer qu’une exigence est une copie d’une
autre. La relation est un type de dépendance et est représentée par une ligne pointillée avec le mot-clé « copie » avec une
pointe de flèche ouverte pointant du copié (client) vers l'exigence de base (fournisseur). Étant donné que l'élicitation et la
gestion Exigences sont des activités coûteuses et chronophages, et que de nombreux projets ont souvent des intérêts qui
se chevauchent, il est utile de réutiliser Exigences ; la relation Copie fournit un mécanisme pour ce faire. L'exigence de
base est généralement stockée dans l'espace de noms d'un autre projet, mais il est considéré comme une bonne pratique
de déplacer les Exigences communes (de base) vers un espace de noms situé au-dessus du niveau des projets individuels.
La relation Copier est disponible depuis la page Relations de la boîte à outils SysML Exigences .

Ce diagramme représente une exigence d'utilisation de l'énergie qui a été copiée pour être réutilisée dans un certain
nombre de projets.

Lorsque la relation Copier est utilisée, les nouvelles Exigences se voient attribuer un nouvel identifiant, mais le texte de
la nouvelle exigence sera une copie en lecture seule de l'exigence de base.

Dériver une exigence d’une autre

La relation Derive est une relation entre deux Exigences , utilisée pour décrire le fait qu'une Exigence est basée sur ou est
une extension ou une dérivation d'une autre Exigence.
La relation Derive est disponible à partir de la page Relations de la boîte à outils SysML Exigences .

Les deux Exigences se situent généralement à des niveaux d’abstraction ou de résolution différents. Une exigence dans
une spécification de bas niveau peut avoir une relation Dériver avec une exigence dans une spécification de niveau
supérieur. L’exigence de niveau inférieur est généralement dérivée de l’exigence de niveau supérieur à la suite d’une
enquête, d’une élaboration ou d’une analyse. L'aspect important de cette relation est que si l'exigence située à l'extrémité
de la flèche de la relation est modifiée, il est très probable que l'exigence dérivée devra être réanalysée.

S'assurer qu'une exigence est satisfaite

La relation Satisfaire est utilisée pour montrer qu'un ou plusieurs éléments de modèle dans l'architecture ou la conception
remplissent la notion exprimée dans l'exigence. Il s'agit d'un lien ou d'un pont important entre ce qui pourrait être décrit
comme le problème ou l'opportunité et l'architecture, la conception et - une fois vérifiés - la mise en œuvre.
La relation Satisfy est disponible depuis la page ' Relations ' de la boîte à outils SysML Exigences .

La relation est un type de Dépendance et est représentée par une ligne pointillée avec le mot-clé « satisfaire » avec une
pointe de flèche ouverte pointant de l'élément de conception (Client) vers l'Exigence (Fournisseur).

Dans ce diagramme on peut voir que le Bloc « Strip Illumination » satisfait à l'exigence relative à la visibilité de la rampe
dans des conditions de faible luminosité. Une justification est également ajoutée qui décrit la conformité par rapport aux
réglementations du gouvernement State .
Dans ce diagramme la relation Satisfy a été affichée en utilisant la notation Callout.

Dans le diagramme suivant, la notation de légende a été utilisée, mais cette fois, le Bloc est référencé dans la légende.

Traçabilité aux éléments Modèle

La relation Trace est une relation à usage général et largement utilisée qui relie une exigence à tout autre élément
modélisation . La relation est exprimée sous la forme d'une ligne pointillée avec le mot-clé « trace » qui en indique la
signification ; la tête de flèche pointe vers un élément de processus ascendant (celui qui a été créé plus tôt dans le
processus).
Dans ce diagramme le modélisateur souhaite montrer qu'une exigence a une relation avec une étude commerciale
représentée par un artefact de document. Le document peut avoir été rédigé dans Enterprise Architect ou il peut s'agir
d'un document externe lié.

La relation Trace agit comme un fourre-tout et est utile lorsqu'un modélisateur souhaite montrer qu'une exigence a une
relation sémantique avec un élément de processus ascendant et qu'aucune des autres relations n'est appropriée.

Vérifier la relation
La relation Vérifier est utilisée pour indiquer qu'une exigence a été remplie. La relation est un type de dépendance et est
représentée par une ligne pointillée avec le mot-clé « vérifier » avec une pointe de flèche ouverte pointant du scénario
Test (client) vers l'exigence (fournisseur).
La relation Vérifier est disponible à partir de la page Relations de la boîte à outils SysML Exigences .

Le scénario Test peut décrire la méthode ou le processus de test ; il contient une balise qui définit le verdict (résultat du
test), qui peut être :

· passer
· échouer
· peu concluant
· erreur
· une valeur définie par l'utilisateur
La relation Satisfy a un objectif connexe dans la mesure où elle décrit quelle partie de la conception ou du système est
réellement utilisée pour mettre en œuvre la notion exprimée dans l'exigence.

Dans ce diagramme une exigence décrit les conditions de faible luminosité, et deux scénarios Test distincts sont utilisés
pour vérifier l'exigence. Le modélisateur a choisi d'afficher le compartiment « satisfiedBy » pour aider à clarifier quelle
partie de l'implémentation est soumise au test. Notez que le verdict est différent pour chaque scénario Test : le Test After
Dark n'est pas concluant alors que le Test Shadow réussit. Un modélisateur peut choisir d'afficher ou de masquer la balise
Verdict dans diagrammes individuels.

Visualisation Relations d'exigence

Relations entre Exigences et d'autres éléments - y compris d'autres Exigences - sont un aspect critique d' Ingénierie
Systèmes Modèles Basée . À bien des égards, ces relations constituent des ponts importants entre la spécification et la
conception, ou entre le problème et la solution. Ces relations peuvent être visualisées dans un large éventail de fenêtres
spécialisées et de mécanismes d'interface utilisateur. L'une des premières choses qu'un nouveau venu dans Enterprise
Architect observera est que ces relations ne sont pas visiblement imbriquées sous les éléments de l'onglet « Projet » de la
fenêtre Navigateur . Il s'agit d'une décision de conception consciente de ne pas encombrer l'onglet « Projet » avec ces
relations, mais plutôt de les rendre visibles dans d'autres affichages qui peuvent être ancrés et visualisés en même temps
que les éléments auxquels ils se rapportent.
Cette illustration montre l'onglet « Détails » de la fenêtre Inspecteur avec le nœud « Relations » développé pour afficher
toutes les relations qui sont connectées à l'exigence « Visibilité en basse lumière », qui a été sélectionnée dans l'onglet «
Projet ». Il existe également une fenêtre dédiée Relations .

Il existe également un large éventail d'autres fenêtres dans lesquelles les relations peuvent être visualisées. Pour plus
d’informations, consultez la rubrique The Browser Window .

Fenêtre de traçabilité

La fenêtre Traçabilité est une fonctionnalité utile et unique d' Enterprise Architect qui permet d'explorer les relations, afin
que le modélisateur puisse parcourir efficacement le graphique des éléments et leurs connexions. C'est une fenêtre utile à
ouvrir lorsque vous souhaitez voir comment un élément est connecté et également à quoi les éléments connectés sont

connectés. Ainsi, par exemple, dans ce modèle de Boom Gate, lorsque l'exigence « Faible visibilité lumineuse » est
sélectionnée, la fenêtre de traçabilité montrera qu'elle est connectée au Bloc « Strip Lighting » qui satisfait à l'exigence.

La fenêtre Traçabilité peut être ouverte à partir de l'option du ruban « Conception > Élément > Trace ».
Le modélisateur dans cette situation pourrait également être intéressé par les aspects structurels du Bloc « Strip
Lighting » et peut ainsi suivre les relations de cet élément pour découvrir ses relations structurelles, parcourir le
graphique pour trouver des réponses aux questions et explorer le modèle.
Si vous n'êtes pas préoccupé par l'affichage des relations, il est préférable de ne pas ouvrir cette fenêtre, car son contenu
doit être restitué à chaque fois que vous changez le focus sur un autre élément et, pour les éléments bien connectés, cela
peut prendre un certain temps, augmentant ainsi le temps nécessaire. pour se déplacer dans le modèle. Pour plus
d'informations, consultez la Traceability Window Rubrique d'aide.

Fenêtre Relations

La fenêtre Relations est une fenêtre utile à ouvrir lorsque l'on travaille sur des préoccupations transversales, comme c'est
généralement le cas avec Exigences . Lorsqu'un élément est sélectionné dans une fenêtre, la fenêtre Navigateur ou un
diagramme , la fenêtre Relations affiche la liste des connecteurs qui soit ciblent l'élément sélectionné (cible), soit
émanent de l'élément (source). Un autre aspect utile de cette fenêtre est que la colonne ' Vue ' indique si la relation est
visible dans le diagramme actuellement ouvert.
La fenêtre Relations peut être ouverte à partir de l'option du ruban ' Démarrer > Toutes Windows > Propriétés >
Responsabilités > Relations'.
Un modélisateur peut également localiser tous diagrammes contenant la relation sélectionnée, en choisissant l'option «
Rechercher dans tous Diagrammes » dans le menu contextuel. Dans cette illustration, on peut voir que la relation «
deriveReqt » qui relie l'exigence de « faible visibilité en lumière » et l'exigence d'« éclairage » existe dans deux
diagrammes . Pour plus d'informations, consultez la rubrique d'aide The Relationships Window .

Matrice de relation

La Matrice de relations est un excellent outil pour visualiser les connexions entre les éléments de deux Paquetages
quelconques, dans une interface ressemblant à une feuille de calcul avec des lignes et des colonnes. L'outil est
particulièrement utile lorsqu'il est utilisé avec Exigences et permet à un ingénieur de voir comment Exigences sont liées à
d'autres éléments, y compris d'autres Exigences .

La Matrice de Relation peut être ouverte à partir de l'option du ruban 'Conception > Paquetage > Paquetage / Matrice '.
Sélectionnez si le Paquetage actuel est le Paquetage source, Paquetage cible ou les deux.
Lorsqu'une relation existe, une icône en forme de flèche s'affichera dans la cellule à l'intersection des éléments source et
cible, la pointe de flèche indiquant la direction de la relation. La matrice peut également être configurée pour mettre en
évidence les lignes ou les colonnes qui n'ont aucune relation dans une couleur distincte. Cette option et d'autres peuvent
être configurées dans la fenêtre Options, disponible à partir du bouton Options dans l'en-tête de la Matrice de relations.

Ces options vous permettent de personnaliser la façon dont la matrice est affichée, notamment si les éléments sont triés et
si leurs noms sont préfixés par le nom Paquetage , et si les lignes et colonnes des éléments source et cible sans
connexions sont mises en surbrillance. Pour plus d’informations, consultez la rubrique d’aide Relationship Matrix .

Insérer des éléments associés

La fonctionnalité Insérer des éléments associés est un outil de productivité qui permet à un ingénieur ou à une autre
partie prenante de construire rapidement un diagramme en insérant un élément central, puis en demandant à l'outil de
trouver tous les éléments liés à cet élément, jusqu'à une profondeur de connectivité arbitraire. Cela aide l'ingénieur à
explorer efficacement le graphique des éléments et à créer un diagramme qui montre comment les autres éléments du
référentiel sont directement liés à cet élément central et comment les autres éléments sont liés à ces éléments. Les types
d'éléments et de connecteurs peuvent être spécifiés pour inclusion ou exclusion, et la profondeur peut être modifiée pour
introduire plus ou moins d'éléments et de connecteurs dans le diagramme . Le diagramme peut être automatiquement
disposé ou l'outil disposition diagramme peut être utilisé pour réorganiser la disposition afin de la rendre plus attrayante
ou pertinente.

La fonctionnalité Insérer des éléments associés peut être utilisée en sélectionnant un élément dans un diagramme , puis
en utilisant l'option du ruban « Conception > Élément > Ajouter un élément > Élément associé ».
La fonctionnalité peut être utilisée comme un outil exploratoire dans lequel les diagrammes rendus sont construits dans le
cadre d'un processus d'enquête et sont rejetés une fois qu'ils ont atteint leur objectif. Alternativement, cette fonctionnalité
peut être utilisée pour créer diagrammes plus permanents qui peuvent être enregistrés et réutilisés pour la visualisation.
Quoi qu'il en soit, l'outil fera gagner du temps à l'ingénieur et permettra la création de diagrammes précis et expressifs
qui ne manqueront pas d'impressionner les parties prenantes qui autrement n'auraient pas été en mesure de visualiser les
connexions entre les éléments. Pour plus d'informations, consultez la Insert Related Elements Aide sujet.

Diagrammes Kanban

diagrammes Kanban peuvent être utilisés pour visualiser les exigences (et d’autres éléments) à mesure qu’elles passent
par les étapes d’une norme industrielle ou d’un processus ou d’une méthodologie propriétaire. Le concept de Kanban
trouve son origine dans l'analyse de l'efficacité des processus dans l'industrie automobile à la fin du 20e siècle au Japon.
Depuis lors, il a été adopté par un certain nombre de communautés de logiciels et de systèmes comme moyen efficace de
gérer les exigences depuis le retard ou la file d'attente jusqu'à leur mise en œuvre. Enterprise Architect dispose d'une
implémentation complète et pragmatique de Kanban qui peut support un certain nombre de processus d'exigences
différents.

Dans ce diagramme nous voyons un certain nombre de colonnes qui représentent les étapes du processus d'exigences,
permettant de faire glisser des éléments entre les colonnes - généralement de gauche à droite, mais parfois des éléments
peuvent être renvoyés vers un Backlog, par exemple. Le diagramme est entièrement configurable par l'ingénieur, ce qui
permet de configurer le nombre de colonnes et leurs noms ainsi qu'un large éventail d'autres aspects du diagramme ,
notamment Propriétés liées, les limites des travaux en cours et les couleurs, pour n'en nommer que quelques-uns.

Il est également possible d'afficher les progrès réalisés sur une exigence particulière, en appliquant des allocations de
ressources et en affichant chaque ressource sous forme de barre de progression indiquant le pourcentage d'achèvement de
la tâche. Dans ce diagramme nous voyons un certain nombre d'éléments, dont l'un montre trois ressources travaillant sur
le même élément. Pour plus d'informations, consultez le Kanban Boards Rubrique d'aide.

Documenter Exigences
Un certain nombre de documents sont couramment produits dans le cadre de la discipline Ingénierie Exigences , tels que
les Exigences Logicielles (Systèmes) Spécification et Rapport de Cas d'Utilisation. Ceux-ci peuvent être générés
automatiquement à partir d'un modèle d'exigences à l'aide gabarits intégrés. De plus, une large gamme d'autres
documents peuvent être produits à l'aide gabarits intégrés ou personnalisés. La documentation facilité d' Enterprise
Architect est hautement configurable et de nombreux rapports peuvent être produits à l'aide du système gabarit , mais
pour les rapports plus complexes, il existe une facilité appelée Documents virtuels qui permet à un éditeur de modéliser
la structure du document et de sélectionner le contenu de n'importe où. dans le référentiel, en appliquant différents
gabarits à chaque section du document. Il existe également une grande variété d'options pouvant être appliquées au
niveau du gabarit ou de la génération de documents, et le moteur Scriptant peut être utilisé pour injecter du contenu dans
un document ou pour produire l'intégralité du rapport.

Il existe également un Document Personnalisé facilité qui permet à un modélisateur de définir un document créé
dynamiquement en faisant simplement glisser le contenu du Navigateur sous forme d'éléments, diagrammes ou
Paquetages et en appliquant à chaque élément un gabarit intégré ou défini par l'utilisateur qui spécifie comment le
contenu sera rendu. Cela permet de visualiser un document et peut inclure tout contenu ou image artisanal en plus du
contenu injecté depuis le Navigateur .

Glossaire du Projet
Un Glossaire du Projet répertorie et définit les termes importants pour un projet ou un programme de travail. Le
Glossaire du Projet peut être généré sous forme de document isolé, ou il peut être inclus sous forme de section dans un
ou plusieurs autres documents. Il fournit un point de vérité unique pour les termes importants du projet et leur
signification ; lorsqu'une nouvelle documentation est générée, les conditions seront automatiquement mises à jour. Le
glossaire peut être généré au format DOCX ou PDF, ou au format HTML qui pourrait être inclus dans un site Web au
niveau d'un projet ou d'une organisation. Le glossaire permet au modélisateur de classer les termes en types définis par
l'utilisateur, auxquels des styles peuvent être appliqués lorsqu'ils sont générés dans la documentation.

Le Glossaire du Projet peut être consulté et géré à partir de cet emplacement du ruban :
Conception > Dictionnaire > Glossaire > Glossaire Vue

Spécification logicielle requise

Ce document décrit les Exigences du système, son comportement dans des conditions définies et les contraintes sous
lesquelles il doit fonctionner ; il sera généralement lu par diverses parties prenantes. Il existe un gabarit Exigences
intégré qui peut être utilisé pour générer le document, bien que le modélisateur soit libre de créer un nouveau gabarit qui
pourrait être soit basé sur celui-ci, soit créé à partir d'un gabarit vierge. Lorsque le document contient du contenu
provenant de divers emplacements dans la fenêtre Navigateur , il serait plus judicieux d'utiliser la facilité Documents
virtuels , qui permet à l'utilisateur de créer un modèle du document (similaire à un document maître dans un traitement de
texte) qui comporte un certain nombre de sections appelées Modèle Documents. Ceux-ci peuvent avoir du contenu
sélectionné n'importe où dans la fenêtre Navigateur .

Rencontrez les outils Ingénierie des Systèmes

Enterprise Architect est une plate Modèle forme d'ingénierie système sophistiquée et flexible basée sur un modèle qui
peut être utilisée à la fois comme référentiel et comme outil de gestion de projets d'ingénierie. Il peut être utilisé tout au
long du cycle de vie, depuis la mise en place d'un programme ou d'une pratique Ingénierie des Systèmes , en passant par
la planification, la gestion, le développement et la documentation des efforts d'ingénierie, jusqu'à la gouvernance des
projets de mise en œuvre qui consomment les conceptions et les résultats architecturaux. L'outil peut être utilisé avec
n'importe quel processus et n'importe quel nombre de langages de représentation, notamment SysML, UML , ArchiMate
ou BPMN. Il existe une large gamme de facilités et d'outils qui permettent à l'ingénieur de travailler en utilisant ses
méthodes préférées, telles que des vues de traitement de texte, des vues de feuilles de calcul, diagrammes , des matrices
de relations et une gamme d'autres fonctionnalités de base et étendues.
Cette carte mentale présente le paysage des outils clés Ingénierie des Systèmes qui peuvent être utilisés pour mettre en
place et maintenir un certain nombre d'initiatives Ingénierie Systèmes Modèles Basée . Bien qu'il s'agisse des principaux
outils, il existe une gamme d'autres outils que les équipes ou les ingénieurs trouveront utiles ; ceux-ci peuvent être
explorés via le Guide de l’utilisateur.

Générateur de scénarios
Apprendre à connaître le générateur de scénarios

Présentation du Le générateur de scénarios est utilisé pour définir les détails d'un cas d'utilisation,
générateur de scénarios notamment la définition de descriptions détaillées, la création d'un ou plusieurs
scénarios et la définition de pré-conditions, de post-conditions et d'autres
contraintes. Les étapes détaillées d'un cas d'utilisation peuvent être enregistrées et
liées à d'autres éléments du modèle et celles-ci peuvent ensuite être générées sous
forme de diagramme fournissant une représentation visuelle du cas d'utilisation et
de ses scénarios. Le diagramme et le texte peuvent être synchronisés et les étapes
individuelles peuvent ensuite être attribuées à d'autres éléments tels que des
composants qui réaliseront l'exigence spécifiée dans le cas d'utilisation.

Où trouver le générateur Démarrer > Application > Modifier > Responsabilités > Scénarios structurés
de scénarios Conception > Élément > Editeurs > Responsabilités > Scénarios structurés
Menu Contexte élément : Propriétés | Responsabilités > Scénarios | clic droit |
Ajouter nouveau : éditeur de structure

Utilisation du générateur Définir les détails d'un cas d'utilisation, ainsi que ses scénarios et contraintes, qui

de scénarios peuvent être utilisés pour remplacer l'approche traditionnelle basée sur un
document texte pour définir les cas d'utilisation. Cela garantit que le diagramme de
cas d'utilisation et les détails textuels des cas d'utilisation et de ses scénarios et
contraintes sont tous contenus dans le même modèle et peuvent être tracés. Si les
cas d'utilisation sont requis dans un format de document pour des raisons
contractuelles ou de processus, un Rapport de cas d'utilisation peut être généré
automatiquement à partir des modèles à l'aide du moteur de documentation
intégré.

Options du générateur de Le Générateur de scénarios peut être affiché sous la forme d'une fenêtre à onglets
scénarios ou ancrée ou dans la fenêtre Propriétés d'un élément. Les étapes d'un cas
d'utilisation, y compris ses scénarios, peuvent être automatiquement générées dans
un certain nombre de types diagramme différents disponibles à partir de l'icône de
la barre d'outils Générer Diagramme .

Apprenez Plus sur le Scenarios

Générateur de Scénarios

Chaîne de valeur
Apprendre à connaître la chaîne de valeur

Présentation de la chaîne La Chaîne de Valeur est un diagramme stratégique qui permet de modéliser les
de valeur activités primaires et secondaires d'une organisation. Le diagramme peut être créé
à partir d'un Motif qui ajoute et relie les cinq activités principales d'une chaîne et
les quatre activités de soutien qui les sous-tendent.

L'élément Ventes brutes sert de cadre aux éléments Activité principale et Activité
Support .
Un analyste travaillant au niveau de l'unité commerciale stratégique sera souvent
invité à modéliser les activités que l'unité commerciale exécute pour apporter
valeur à ses clients. La chaîne de valeur est l'outil privilégié pour créer cette
représentation stratégique de la séquence d'activités qu'une organisation exécute.

Où trouver la chaîne de Ruban : Conception > Diagramme > Ajouter Diagramme > Modélisation
valeur Stratégique > Chaîne de valeur
Fenêtre Navigateur Barre d'outils : Icône Nouveau Diagramme > Modélisation
Stratégique > Chaîne de valeur
Menu contextuel de la fenêtre Navigateur | Ajouter Diagramme ... > Modélisation
Stratégique > Chaîne de valeur

Utilisation de la chaîne de La chaîne de valeur est un outil important d’aide à la planification stratégique
valeur permettant de comprendre l’ensemble de la séquence (ou de la chaîne). Il permet

également de décomposer la chaîne en ses activités constitutives, permettant ainsi

de déterminer et potentiellement d'améliorer l'évaluation des coûts, des ressources
et valeur .

Options pour la chaîne de Chacune des activités principales et de soutien peut être liée à d'autres éléments du
valeur modèle, notamment un document lié et des éléments qui définissent des repères.

Le diagramme de chaîne de valeur (comme tout diagramme ) peut être considéré

comme une liste d'éléments qui facilite le travail avec les propriétés de l'élément.
Filtres de Diagramme peuvent également être utilisés lors de la présentation des
diagrammes pour attirer l'attention sur des parties des diagrammes .

Apprenez Plus sur la Value Chains

Chaîne de Valeur

Fenêtre de traçabilité
Apprendre à connaître la fenêtre de traçabilité

Présentation de la fenêtre La fenêtre Traçabilité fournit une vue hiérarchique des connexions des éléments,
de traçabilité permettant de visualiser et d'interroger la traçabilité au fur et à mesure que les
éléments sont parcourus dans le modèle. Cet outil est particulièrement utile car un
modélisateur choisit souvent de masquer les relations diagramme , mais en
sélectionnant un élément dans le diagramme et en affichant ses connexions dans la
fenêtre Traçabilité, toutes ses relations seront révélées.

Où trouver la fenêtre de Démarrer > Application > Conception > Traçabilité

traçabilité

Utilisation de la fenêtre La fenêtre Traçabilité fournit une vue hiérarchique de la manière dont un élément
Traçabilité est connecté aux autres éléments du référentiel, ainsi que le type de chaque
relation. Cette fenêtre donne une liste complète de toutes les relations qui ne
peuvent pas être vues en visualisant les éléments dans la fenêtre Navigateur et qui
peuvent également n'apparaître dans aucun diagrammes . Il est très utile pour gérer
Exigences et suivre la manière dont une Exigence est liée aux éléments de

processus en amont tels que les Pilotes Métier et aux éléments de processus en
aval tels que les Composants. C'est un outil utile, permettant aux nouveaux
arrivants dans un modèle de comprendre rapidement quels sont les éléments
importants et bien connectés. Avant de supprimer un élément du modèle, vous
devez utiliser la fenêtre Traçabilité pour vous assurer que vous comprenez les
relations existantes de cet élément.

Options de la fenêtre Il existe une série d'options qui limitent la traçabilité aux types de connecteurs
Traçabilité spécifiés ; ces options peuvent être définies pour modifier ce qui est affiché dans la
fenêtre. Les options sont disponibles dans la barre d'outils en haut de la fenêtre.

Apprenez Plus sur la The Traceability Window

Fenêtre Traçabilité

Modélisation Consciente du Temps

Connaître Modélisation Consciente du Temps

Présentation Modélisation La fonctionnalité Modélisation Consciente du Temps permet aux analystes,

Consciente du Temps architectes et autres de créer des versions incrémentielles de leurs modèles en
fournissant des outils qui facilitent la migration des éléments, diagrammes et
Paquetages à travers la dimension du temps permettant la création de plusieurs
transitions ou versions. Les modèles de base (« tels quels », état actuel) restent
inchangés et un certain nombre de modèles cibles (« à devenir », état futur)
peuvent être construits à des fins de visualisation et d'analyse. Il est
particulièrement utile lorsqu'un certain nombre d'options futures doivent être
représentées et comparées efficacement, permettant ainsi de mener une analyse de
type « et si ». Le temps est l’une des dimensions les plus importantes de
l’architecture car c’est le substrat sur lequel se produisent tous les changements.
Les architectes sont conscients de son importance et créent traditionnellement des
modèles avec des éléments dupliqués ; modélisation temporelle permet de cloner
les éléments, diagrammes et Paquetages existants.

Où trouver Modélisation Cloner la structure Paquetage en tant que nouvelle version

Consciente du Temps Ruban : Conception > Paquetage > Gérer > Cloner la structure en tant que
nouvelle version
Menu Contexte de la fenêtre Navigateur : Cloner la structure en tant que nouvelle
version

Cloner Diagramme en tant que nouvelle version

Ruban : Conception > Diagramme > Gérer > Cloner en tant que nouvelle version

Cloner un élément en tant que nouvelle version

Ruban : Conception > Élément > Gérer > Cloner l'élément en tant que nouvelle

version

Utilisation de Modélisation Modélisation Consciente du Temps peut être appliquée dans un large éventail de
Consciente du Temps situations dans les modèles commerciaux et technologiques ; il permet de montrer
comment les entités représentées par le modèle évoluent au fil du temps. Les
modèles de référence (« tels quels », état actuel) peuvent ne pas être affectés,
tandis qu'un nombre quelconque de modèles cibles (« à venir », état futur) peuvent
être construits pour refléter l'évolution possible des modèles de base au fil du
temps. Il existe de nombreux domaines dans lesquels un analyste ou un architecte
trouvera cet outil utile ; Par exemple:
· Les architectes utilisent des modèles pour documenter l'état actuel, puis
passent à la tâche plus difficile et plus gratifiante consistant à définir à quoi
ressemblera l'état futur, souvent au travers d'une série de transitions.
· Lorsque de nouveaux clients sont acquis, un Analyste Métier est souvent
confronté au défi de décrire comment un produit de base doit être configuré
pour ces différents groupes de clients, ce qui entraîne différentes versions du
même produit.
· Les stratèges Métier prescrivent généralement à quoi ressemblera un modèle
de capacité pour l'organisation du futur, ce qui donne lieu à au moins deux
versions du modèle de capacité.
· Lors des Fusions et Acquisitions, Métier Architectes ont pour mission de
décrire les états possibles de l'entreprise une fois la reprise réalisée.
· Les ingénieurs doivent développer des solutions meilleures et plus efficaces
pour relever les défis du futur, c'est pourquoi ils définissent des versions plus
récentes de la solution.
· Les testeurs doivent connaître les différentes versions d'un produit lors de la
conception et de l'exécution de scénarios de test.
· Les ingénieurs d'infrastructure doivent définir les futurs environnements en
réponse à des problèmes de performances ou de sécurité, en créant plusieurs
versions de serveurs, d'appareils et même facilités entières.
Toutes les situations nécessitent que le temps soit intégré dans les modèles pour
pouvoir être raisonné et explicité. modélisation facilités Time Aware d' Enterprise
Architect peut être utilisée dans ces situations pour garantir que le temps est inclus
en tant que citoyen de première classe dans les modèles. Le temps n'est pas mesuré
ou modélisé en termes absolus ou relatifs, mais en représentant un nombre
quelconque d'états futurs ou de différences sous forme de versions.

Options de Modélisation Les fonctionnalités Modélisation Consciente du Temps permettent à un

Consciente du Temps modélisateur de cloner Paquetages , diagrammes et des éléments. La plupart des
modèles ne sont pas triviaux et Enterprise Architect fournit une large gamme
d'outils qui aideront à la visualisation des modèles et de leur évolution au fil du
temps. La fenêtre Traçabilité sera particulièrement utile pour visualiser la
connexion entre les éléments des modèles temporels et d'autres parties du
référentiel. Une fonctionnalité très utile est la possibilité d'appliquer un filtre à un
diagramme basé sur la version, masquant ainsi les éléments qui ne font pas partie
d'une version particulière.

Apprenez Plus sur Time Aware Models

Modélisation Consciente
du Temps

Bibliothèque
Faire connaissance avec la Bibliothèque

Présentation de la La fenêtre Bibliothèque offre aux développeurs, modélisateurs, clients et parties

Bibliothèque prenantes la possibilité de commenter et de fournir des commentaires sur le travail
en cours ou à l'achèvement d'une étape ou d'un projet.

Utilisation de la La fonctionnalité Bibliothèque peut être utilisée pour effectuer révisions de

Bibliothèque modèles sous un certain nombre de perspectives , y compris des visites guidées,
révisions de modèles formels ou révisions ad hoc.

Où trouver La Pour publier ou afficher la discussion d'un élément

Bibliothèque Ruban : Démarrer > Collaborer > Modèle Bibliothèque

Options pour la Il existe un large éventail de paramètres disponibles pour configurer la

Bibliothèque Bibliothèque , disponibles à partir des menus contextuels Catégorie et Sujet, et
comprenant la définition du statut de la catégorie ou du sujet et d'autres options.
Diagrammes , les éléments et fonctionnalités des éléments peuvent être facilement
glissés depuis la fenêtre Navigateur pour créer des liens de modèles qui peuvent
être utilisés par les membres de l'équipe pour créer un lien hypertexte directement
depuis la fenêtre Bibliothèque vers ces éléments dans la fenêtre Navigateur .

Apprenez Plus sur The Model Library

Bibliothèque d'Équipe

Carte de Stratégie
Une Carte de Stratégie est un diagramme utilisé pour décrire les principaux objectifs stratégiques importants pour une
organisation ou une équipe commerciale. Le diagramme montre quatre perspectives importantes qui sont les questions
importantes qui fournissent la définition d'une stratégie. Les perspectives définies sont : « Financière », « Client », «
Processus Métier Internes » et « Apprentissage et Croissance ». Le diagramme est utilisé comme outil de communication
pour garantir une compréhension commune de la stratégie, pour concentrer les efforts de l'organisation et pour aider à
l'évaluation des progrès.

Connaître la Carte de Stratégie

Où trouver la Carte de Ruban : Conception > Diagramme > Ajouter Diagramme > Modélisation
Stratégie Stratégique > Carte de Stratégie
Fenêtre Navigateur Barre d'outils : Icône Nouveau Diagramme > Modélisation

Stratégique > Carte de Stratégie

Menu contextuel de la fenêtre Navigateur | Add Diagramme ... > Modélisation
Stratégique > Carte de Stratégie

Utilisation de la Carte de La Carte de Stratégie est utilisée pour modéliser les objectifs stratégiques clés
Stratégie qu'une organisation ou une équipe de direction entend atteindre. Les éléments de
chacune des quatre perspectives peuvent être liés à d’autres éléments du référentiel
pour montrer comment ils pourraient être mis en œuvre au niveau métier,
applicatif ou technologique.

Options pour la Carte de Une Carte de Stratégie peut être créée à l'aide Motifs qui créent automatiquement
Stratégie des éléments et un diagramme pouvant être utilisé comme point de départ pour la
Carte de Stratégie . Trois Motifs sont disponibles, allant d'une expression très
simple avec un seul élément dans chaque perspective à une expression entièrement
travaillée avec plusieurs éléments dans chaque perspective. Une boîte à outils
fournit une gamme d'éléments et de relations supplémentaires pour étendre les
cartes de base créées à l'aide des Motifs .

Apprenez Plus sur la Strategy Maps

Carte de Stratégie

Gestionnaire de Spécification
Faire connaissance avec le Gestionnaire de Spécification

Présentation du Le Gestionnaire de Spécification est l'outil central pour travailler avec Exigences ;
Gestionnaire de il fournit une interface ressemblant à un traitement de texte ou à un tableur pour
Spécification saisir, gérer et visualiser Exigences . De nouvelles Exigences peuvent être créées
avec des noms et des descriptions détaillées et des propriétés telles que le statut et
la priorité peuvent être ajoutées à partir de listes déroulantes. Exigences existantes
peuvent être visualisées et gérées dans une vue pratique, et leur modification dans
le Gestionnaire de Spécification les modifiera à tous les autres endroits du
référentiel, tels que diagrammes et les fenêtres. C'est l'outil parfait pour les
analystes plus à l'aise avec du texte qu'avec diagrammes et habitués à travailler
avec un traitement de texte ou une feuille de calcul. Il présente l'avantage
supplémentaire que les exigences font partie d'un modèle et peuvent être
rattachées à d'autres éléments, notamment les moteurs Métier , les parties
prenantes et les composants de la solution.

Où trouver le Gestionnaire Fenêtre Navigateur | Cliquez-droit sur Paquetage | Gestionnaire de Spécification

de Spécification

Utilisation du Gestionnaire Créer, afficher et gérer Exigences dans un outil basé sur du texte qui ressemble au
de Spécification travail dans un traitement de texte ou une feuille de calcul. Des détails peuvent
être ajoutés aux Exigences et les propriétés des exigences peuvent être ajoutées à
partir des listes déroulantes. Lorsque les Exigences sont modifiées dans le
Gestionnaire de Spécification les modifications sont facilement reflétées dans la
fenêtre Navigateur et dans toutes les autres fenêtres.

Options pour le Il existe un large éventail d'options disponibles dans le menu d'options, pour
Gestionnaire de personnaliser la façon dont vous utilisez le Gestionnaire de Spécification . Ceux-ci
Spécification incluent la numérotation de niveau (hiérarchique), la dénomination automatique, la
vérification orthographique, la documentation, l'importation et l'exportation d'
Exigences , l'accès à divers outils connexes et plus encore.

Apprenez Plus sur le The Specification Manager

Gestionnaire de
Spécification

Feuille de Route Diagramme

Connaître le Diagramme de la Feuille de Route

Présentation du Le diagramme Feuille de Route est une superposition qui peut être appliquée à
Diagramme Feuille de n'importe quel diagramme pour décrire les phases significatives des éléments et
Route comment elles changent au fil du temps.

Il n'y a aucune restriction sur le type d'élément qui peut apparaître sur le
diagramme , et n'importe quel diagramme peut avoir une superposition Feuille de
Route définie. Les phases importantes définies par l'utilisateur dans la durée de vie
de l'élément sont représentées par des barres colorées, qui peuvent être définies
pour afficher la durée. Les couleurs et les phases peuvent être configurées à l'aide
d'une Légende Diagramme , qui les applique automatiquement aux éléments du
diagramme . Ils sont particulièrement utiles dans diagrammes Architecture
d'Entreprise pour décrire les capacités et les applications Feuilles de Route .

Où trouver le Diagramme Ruban : Disposition > Diagramme > Feuille de Route

de la Feuille de Route Diagramme Menu Contexte : Feuille de Route

Utilisation du Diagramme Le diagramme Feuille de Route a un large éventail d'utilisations dans Architecture
Feuille de Route d'Entreprise où ils peuvent être utilisés pour afficher des feuilles de route
d'applications et de capacités à Ingénierie des Systèmes , où ils sont utilisés pour
afficher le timing dans les composants de bas niveau.

Options pour le La superposition Feuille de Route propose une gamme d'options qui déterminent
Diagramme Feuille de les propriétés de la chronologie, telles que l'échelle des règles temporelles, les
Route unités, leurs positions et l'apparence de la chronologie, y compris les polices et les
couleurs. La hauteur et la position de la chronologie peuvent également être
configurées en fonction du diagramme et de l'affichage.

La légende Diagramme peut être configurée pour définir les phases de la vie de
l'élément, pour définir la spécification des bandes colorées et bien plus encore. Les
segments Feuille de Route peuvent être affichés ou masqués sur des éléments
individuels dans les cas où un segment particulier pourrait ne pas s'appliquer à un
ou plusieurs éléments du diagramme .

Apprenez Plus sur le Roadmap Diagrams

Diagramme Feuille de
Route

Diagramme Exigences
Connaître le Diagramme Exigences

Présentation du Le diagramme Exigences fournit une représentation visuelle de la façon dont

Diagramme Exigences Exigences sont liées les unes aux autres et à d'autres éléments du modèle, y
compris les pilotes Métier , les contraintes, Règles Métier , les cas d'utilisation, les
histoires d'utilisateurs, les composants de conception et plus encore. Le diagramme
est l'un des types diagramme étendus d' Enterprise Architect . Il fournit une
représentation graphique attrayante des Exigences , ce qui constituera un
changement bienvenu pour les analystes Exigences habitués à travailler avec des
outils basés sur du texte.

Où trouver le Diagramme
Exigences Fenêtre Navigateur Menu Contexte : Ajouter Diagramme : | Gérer | Afficher
toutes Perspectives | Étendu | Exigences

Utilisation du Diagramme Une utilisation consiste à montrer comment Exigences sont connectées entre elles
Exigences dans une hiérarchie ou, plus important encore, comment Exigences sont
connectées à d'autres éléments. Le modélisateur expérimenté définira et gérera les
Exigences dans le Gestionnaire de Spécification , puis utilisera le diagramme
Exigences pour montrer comment chaque Exigence est liée aux éléments de
processus en amont tels que les pilotes Métier , et aux éléments de processus en
aval tels que les cas d'utilisation, les histoires d'utilisateurs, l'expérience utilisateur.
conceptions et composants de solution.

Options pour le L'apparence d'un diagramme peut être modifiée en fonction du public cible, et des
Diagramme Exigences détails peuvent être inclus, supprimés ou modifiés pour garantir que le diagramme
réponde à son objectif principal de communication. Il existe un large éventail
d'options, allant de la création d'un style de diagramme dessiné à la main au

filtrage du contenu diagramme .

Apprenez Plus sur le Working In Diagrams

Diagramme Exigences

Matrice de relation
Apprendre à connaître la Matrice relationnelle

Présentation de la Matrice La Matrice de relation fournit une vue matricielle convaincante pour une analyse
des relations pratique de la manière dont Exigences sont liées les unes aux autres et aux autres
éléments du modèle. Il peut être utilisé pour visualiser les relations entre les
parties prenantes et leurs Exigences , comment les cas d'utilisation sont liés aux
Exigences Métier ou Exigences fonctionnelles, comment les capacités sont liées
aux pilotes Métier , quels composants implémentent un ensemble d' Exigences , et
plus encore. N'importe quel nombre de matrices peut être défini rapidement, puis
enregistré pour être visualisé dans des ateliers, ou inclus dans la documentation
générée automatiquement à partir du modèle ou exportée vers un tableur.
Lorsqu'une matrice est créée, les connexions peuvent être visualisées en plaçant
les Exigences sur un axe de la matrice et les éléments connectés sur l'autre axe,
puis les cellules de la matrice indiqueront le sens de la relation.

Où trouver la Matrice des Dans la fenêtre Navigateur , cliquez sur un Paquetage et sélectionnez :
relations · L'onglet 'Ressources' | Profils Matrice | Cliquez-droit sur un profil | Ouvrez le
profil Matrice ou
· Le ruban Démarrer > Toutes Windows > Conception > Outils > Matrice
Paquetage

Utilisation de la Matrice Afficher les relations qui existent entre les éléments - par exemple quelles
des relations Exigences sont réalisées par quels cas d'utilisation - dans deux Paquetages dans
une matrice visuellement convaincante. Il est utile pour analyser les éléments ou
les relations manquants ; par exemple, pour déterminer quelles Exigences ne sont
réalisées par aucun cas d'utilisation, ou quels composants n'ont pas Exigences ou
de cas d'utilisation correspondants. Il est particulièrement utile dans les ateliers
avec les acteurs Métier qui ne sont peut-être pas familiers avec diagrammes
Exigences in Trace.

Options pour la Matrice Il existe une gamme d'options qui peuvent être définies pour la Matrice de
des relations relations, notamment son enregistrement dans l'onglet « Ressources » de la fenêtre
Navigateur ou au format CSV pour l'ouvrir dans une feuille de calcul. L'apparence
de la Matrice de relation peut également être modifiée en triant les éléments, en
affichant une vue de numérotation des plans et en supprimant les noms Paquetage .
Ces éléments sont disponibles à partir du bouton Options de la Matrice des
relations.

Apprenez Plus sur la Relationship Matrix

Matrice Relationnelle

Motifs
Apprendre à connaître Motifs

Présentation Motifs Un Motif est une solution de conception générale réutilisable à un problème
courant dans un contexte architectural donné. Motifs ne sont pas des conceptions
résolues, mais plutôt gabarits indiquant comment un problème peut être résolu. Le
concept est né dans le monde de l'architecture du bâtiment et a été publié pour la
première fois dans un livre de Christopher Alexander intitulé Design Motifs . Ils
ont ensuite été appliqués à l’industrie du logiciel et ont été largement utilisés par le
domaine du génie logiciel pour résoudre des problèmes de génie logiciel
couramment récurrents, même si, à première vue, la nature des problèmes semblait
assez différente.

Où trouver Motifs Créer un Motif :

Spécialiser > Technologies > Publier la technologie > Publier Diagramme en tant
que Motif
Utiliser un Motif :
Démarrer > Application > Partager > Ressources > Motifs < groupe motif > >
Cliquez-droit sur le nom Motif > Ajouter Motif au Diagramme

Utilisation des Motifs Motifs peuvent être appliqués dans un large éventail de situations, de l'architecture
commerciale à l'architecture technologique, mais sont toujours utilisés pour
appliquer une solution commune à un certain nombre de problèmes ou de

contextes qui, à première vue, peuvent sembler très différents. Enterprise Architect
a fourni un mécanisme utile pour extraire Motifs , ce qui signifie que n'importe
quel diagramme peut être publié en tant que Motif puis réutilisé dans le même
contexte ou dans un contexte différent. Un exemple de Motif et de son utilisation
pourrait être un Motif articulant la relation entre les moteurs, les buts, les objectifs
et les mesures. Un diagramme existant pourrait être publié sous forme de Motif ,
puis n'importe quelle architecture d'entreprise pourrait réutiliser le Motif en le
faisant simplement glisser sur un diagramme vide.

Options pour Motifs Motifs sont le plus souvent disponibles dans l'onglet « Ressources » de la fenêtre
Navigateur , mais sont aussi parfois intégrés aux technologies et mis à disposition
à partir d'une page Boîte à outils. Il existe un certain nombre d'options disponibles
lors de la publication d'un Motif , notamment la possibilité de décrire les détails du
Motif dans son ensemble et d'inclure notes pour chacun des éléments qui
composent le Motif .

Diagramme Paramétriques
Connaître le Diagramme Paramétriques

Présentation du Le diagramme Paramétriques est l'un des diagrammes structurels du Systems

Diagramme Modeling Language (SysML) qui peuvent être utilisés pour modéliser des
Paramétriques systèmes d'équations mathématiques. Il existe un assistant qui aidera à convertir
les équations en éléments modélisés incluant les propriétés. Une fois les équations
modélisées, elles peuvent être utilisées pour créer des simulations à l'aide de
l'intégration OpenModelica.

Où trouver le Diagramme Ruban : Conception > Diagramme > Ajouter Diagramme : Type = Ingénierie des
Paramétriques Systèmes > SysML, Select From = SysML 1.5, Diagramme Types = Paramétriques
Barre d'outils de la fenêtre Navigateur : Type = Ingénierie des Systèmes > SysML,
Select From = SysML 1.5, Diagramme Types = Paramétriques
Fenêtre Navigateur Menu Contexte | Ajouter Diagramme : Type = Ingénierie des
Systèmes > SysML, Select From = SysML 1.5, Diagramme Types = Paramétriques

Utilisation du Diagramme Le diagramme Paramétriques peut être utilisé chaque fois que vous avez besoin de
Paramétriques visualiser ou de simuler un système d'équations.

Options pour le Le diagramme Paramétriques propose de nombreuses options, notamment la

Diagramme modélisation d'une équation simple ou d'un système d'équations.
Paramétriques

Apprenez Plus sur le · Parametric Diagrams

Diagramme · Class Diagram
Paramétriques

Feuilles de calcul d'importation et d'exportation

Présentation des feuilles de Cette facilité est un mécanisme utile pour importer Exigences qui ont été définies
calcul d'importation et dans une feuille de calcul ou un tableau de traitement de texte dans Enterprise
d'exportation Architect . Une fois dans Enterprise Architect les Exigences peuvent être gérées et
tracées jusqu'à des éléments tels que les moteurs d'activité, les scénarios et les
composants. Alternativement, Exigences d' Enterprise Architect peuvent être
exportées vers une feuille de calcul dans le but de les fournir à un tiers ou pour un
certain type d'analyse numérique ou statistique. Le mappage entre les champs de la
feuille de calcul et les propriétés analogues dans Enterprise Architect est
entièrement configurable à l'aide d'une spécification.
Pour un échange d'informations plus détaillé, le MDG Link pour Microsoft Office
(disponible auprès de Sparx Systems ) fournit des fonctionnalités supplémentaires
et des points d'intégration utiles pour traiter des Exigences complexes.

Où trouver des feuilles de Ruban : Publier > Échange de Modèles > CSV
calcul d'importation et
d'exportation

Utilisation de feuilles de Cette fonctionnalité peut être utilisée pour importer ou exporter Exigences à partir
calcul d'importation et d'un fichier CSV. Avant l'installation d'un outil tel qu'Enterprise Enterprise
d'exportation Architect , les analystes utilisaient peut-être une feuille de calcul ou un tableau
dans leur traitement de texte préféré pour enregistrer Exigences ; ceux-ci peuvent
facilement être importés à l’aide de l’importation CSV facilité . Alternativement,
Exigences doivent parfois être fournies à un tiers qui précise généralement qu'il les
souhaite dans un fichier tableur ; ceci peut être réalisé en utilisant l'exportation
facilité .

Options d'importation et L'importation et l'exportation facilité sont entièrement configurables et disposent

d'exportation de feuilles de d'une spécification définie par l'utilisateur pour faciliter le mappage des champs de
calcul la feuille de calcul aux propriétés Exigences dans Enterprise Architect . Cette
facilité inclut également la possibilité d'importer et d'exporter les champs dans
Valeur Étiquetés du Exigence.

Apprenez Plus sur les CSV Import and Export

feuilles de calcul
d'importation et
d'exportation

Carte de Chaleur
Connaître la Carte de Chaleur

Présentation de la Carte Une Carte de Chaleur est un type de graphique qui peut être utilisé pour visualiser
de Chaleur des données en deux dimensions. Il utilise la couleur des rectangles pour indiquer
une dimension des données et la taille relative des rectangles pour indiquer une
autre dimension. Ils sont généralement utilisés pour créer des représentations
convaincantes de données pour la prise de décision stratégique ou tactique. Ils
peuvent être utilisés à n’importe quel niveau d’un référentiel, depuis l’architecture
stratégique jusqu’aux architectures technologiques.

Où trouver la Carte de Double-cliquez sur l'élément Graphique | Détails du graphique | Source >
Chaleur Paquetage

Utilisation de la Carte de Cartes des Chaleur sont généralement utilisées pour créer des représentations
Chaleur convaincantes de données pour la prise de décision stratégique ou tactique. Ils
peuvent être utilisés avec Exigences pour indiquer les statuts d'un groupe
d'exigences et, si les métriques sont disponibles, le coût de mise en œuvre estimé
de chaque exigence. Ils pourraient être utilisés avec un inventaire d’applications
ou de technologies pour montrer la prévalence des technologies. Par exemple,
quelles applications ont été développées dans un langage particulier ou exécuter
sur un système d'exploitation particulier.

Options pour la Carte de Au lieu de spécifier les paramètres de la Carte de Chaleur dans les champs de
Chaleur l'onglet « Paquetage », vous pouvez sélectionner l'onglet « SQL personnalisé » et
créer une Carte de Chaleur personnalisée à l'aide de SQL. Vous précisez toujours
le type de graphique dans le champ ' Type ', mais les autres champs dialogue sont
grisés.

Apprenez Plus sur la Heat Maps

Carte de Chaleur

Matrice d'Analyse des Écarts

Connaître la Matrice d'Analyse des Écarts

Présentation de la Matrice La Matrice d'Analyse des Écarts est une Matrice relationnelle spécialisée qui est
d'Analyse des Écarts utilisée pour enregistrer les écarts qui existent entre deux versions d'une partie
d'une entreprise. Les écarts entre deux versions différentes d'une architecture
pourraient être enregistrés, ou les écarts entre deux versions de capacités ou de
compétences du personnel, ou deux versions d'informations ou de données. L'outil
est structuré de la même manière qu'une feuille de calcul avec des colonnes et des
lignes. Les éléments qui constituent la ligne de base (point de départ) sont
répertoriés sous forme de lignes et les éléments qui constituent la cible (point
final) sont répertoriés sous forme de colonnes. Il y a une colonne pour enregistrer
les éléments manquants ou éliminés et une ligne pour enregistrer les nouveaux
éléments. À l'intersection d'un élément de base et d'un élément cible, notes
peuvent être ajoutées pour décrire tous les détails de la relation entre les deux
éléments.

Où trouver la Matrice Ruban : Conception > Paquetage > Analyse des écarts
d'Analyse des Écarts

Utilisation de la Matrice La Matrice d'Analyse des Écarts peut être utilisée aussi bien pour l'analyse
d'Analyse des Écarts commerciale que technique. Il s'agit d'un outil à usage général permettant
d'enregistrer les détails d'une comparaison entre différentes versions d'une partie

d'une entreprise. Dans l'analyse commerciale, il peut être utilisé pour analyser les
compétences du personnel, les données et informations, Processus Métier , les
lignes de Métier et plus encore, en les comparant dans les états actuels et futurs
d'une entreprise. Dans Architecture d'Entreprise la matrice peut être utilisée pour
enregistrer les écarts entre les architectures de base, de transition et cible, en
comparant les capacités, l'architecture et les composants de la solution, etc.

Options pour la Matrice La Matrice d'Analyse des Écarts peut être configurée pour afficher différentes
d'Analyse des Écarts parties du référentiel. Une fois que les Paquetages appropriés ont été choisis pour
la cible et la ligne de base, et que les types d'éléments ont été sélectionnés pour le
filtre, le type d'élément Gap peut être sélectionné. L'élément choisi pour l'espace
limitera les éléments disponibles pour représenter l'espace pour les éléments
« Manquant » ou « Nouveau » dans les cellules de la matrice. De nombreux choix
sont disponibles dans le menu « Options », notamment la possibilité de mettre à
jour, de supprimer et de sauvegarder la Matrice d'Analyse des Écarts en tant que
profil, en lui donnant un nom afin de pouvoir la rappeler ultérieurement.

Apprenez Plus sur la Gap Analysis Matrix

Matrice d'Analyse des
Écarts

Documentation
Apprendre à connaître la documentation

Présentation de la Les fonctionnalités de documentation peuvent être utilisées pour générer

documentation automatiquement une large gamme de documentation directement à partir des
modèles. Ceux-ci peuvent être basés sur des documents tels que les formats PDF
et Docx ou basés sur HTML. gabarits flexibles peuvent être utilisés pour
personnaliser complètement les documents générés, notamment les logos
d'entreprise, tableaux de contenu, tableaux d'informations sur les éléments et
diagrammes . Des rapports ad hoc peuvent également être créés à partir d'un
certain nombre d'outils tels que le glossaire et la fenêtre de recherche.

Où trouver la Ruban : Publier > Rapports de Modèle > Générateur de Rapports

documentation

Utilisation de la Les modélisateurs, analystes, architectes, Gestionnaires de Projet et autres peuvent

documentation utiliser facilité pour produire une large gamme de publications et de rapports basés
sur des documents, tels qu'une Spécification Exigences système, Rapport de cas
d'utilisation, Dictionnaire de données, une description de l'architecture de solution,
etc. Il peut également être utilisé pour des rapports ad hoc afin de créer des
rapports tels qu'une liste des exigences les plus volatiles. Une documentation
HTML peut également être publiée pour permettre aux parties prenantes qui n'ont
pas accès à Enterprise Architect de visualiser les modèles à partir d'un site Intranet
qui peuvent simplement être placés sur un système de fichiers sans avoir besoin
d'un serveur Web.

Options de documentation Plusieurs options peuvent être définies pour personnaliser les informations
incluses dans un document généré, notamment l'ordre des éléments et diagrammes
et le masquage de certains éléments. Des filtres, des substitutions de mots et
d'autres options peuvent également être appliqués.

Apprenez Plus sur la Model Publishing

Documentation

Diagramme Statemachine
Apprendre à connaître le Diagramme Statemachine

Présentation du Le diagramme Statemachine est l’un des diagrammes de comportement Systems

Diagramme Statemachine Modeling Language (SysML) qui peut être utilisé pour modéliser un large éventail
de choses. Il s'agit d'un diagramme à usage général pour les entités modélisation
dans les domaines métier et technique, comprenant les termes et concepts, Règles
Métier et les capacités en XML et les schémas de base de données.

Où trouver le Diagramme Ruban : Conception > Diagramme > Ajouter Diagramme : Type = Ingénierie des
Statemachine Systèmes > SysML, Sélectionner depuis = SysML 1.5, Types Diagramme =
Statemachine > <type requis>
Barre d'outils de la fenêtre Navigateur : Type = Ingénierie des Systèmes > SysML,
Select From = SysML 1.5, Diagramme Types = Statemachine > <type requis>
Fenêtre Navigateur Menu Contexte | Ajouter Diagramme : Type = Ingénierie des
Systèmes > SysML, Select From = SysML 1.5, Types Diagramme = Statemachine
> <type requis>

Utilisation du Diagramme Le diagramme de classes peut être utilisé chaque fois qu'une représentation
Statemachine logique ou structurelle d'un système est requise. Il est applicable à modélisation de
concepts commerciaux et techniques et peut être utilisé pour modéliser des
informations et des structures telles que XML et des schémas de bases de données.

Options pour le Le diagramme de classes (comme tout diagramme ) peut être considéré comme
Diagramme Statemachine une liste d'éléments, ce qui facilite l'utilisation des propriétés de l'élément.
Filtres de Diagramme peuvent également être utilisés lors de la présentation des
diagrammes pour attirer l'attention sur des parties des diagrammes . Les
diagrammes peuvent être présentés sous forme dessinée à la main ou sous la forme
d'un tableau blanc en modifiant les propriétés du diagramme .

Apprenez Plus sur le StateMachines

Diagramme Statemachine

Diagramme d'arbre Décision

Connaître le Diagramme de l'arbre Décision

Présentation du Les arbres Décision constituent un moyen efficace de représenter graphiquement

Diagramme d'arbre un certain nombre d'options et fournissent un mécanisme permettant d'étudier les
Décision résultats et les avantages possibles du choix de ces options. Ils peuvent également
aider l'analyste à se faire une idée équilibrée des risques et des avantages associés
à chaque plan d'action possible. Ils sont un proche cousin du Tableau de Décision
mais ont l'avantage d'être graphiques. Enterprise Architect dispose d'un diagramme
spécialement conçu permettant de modéliser et d'afficher des décisions complexes,
y compris les probabilités et l'incertitude.

Où trouver le Diagramme Ruban : Conception > Diagramme > Ajouter Diagramme > Modélisation
de l'arbre Décision Stratégique > Arbre Décision
Fenêtre Navigateur Barre d'outils : Icône Nouveau Diagramme > Modélisation
Stratégique > Arbre Décision
Menu contextuel de la fenêtre Navigateur | Ajouter Diagramme ... > Modélisation
Stratégique > Arbre Décision

Utilisation du Diagramme Les arbres Décision peuvent être utilisés pour faciliter les processus de prise de
d'arbre Décision décision, en particulier lorsque la décision implique un ensemble complexe de
conditions dont les probabilités d'occurrence sont différentes. Ils peuvent être
utilisés pour l'analyse des décisions stratégiques ou opérationnelles et peuvent
aider à formaliser la base de la prise de décision, en particulier lorsqu'il est
impératif que les actions prises soient basées sur une analyse formelle ou aient des
conséquences coûteuses. Un arbre Décision peut être utilisé pour présenter une
image graphique d'un Tableau de Décision aux parties prenantes qui sont plus à
l'aise avec la visualisation diagrammes plutôt que tableaux et de documents.

Options pour le Les arbres Décision peuvent être dessinés avec différents niveaux de formalité,
Diagramme d'arbre depuis des arbres simples avec une série de décisions aboutissant à des résultats
Décision jusqu'à des arbres plus formels qui impliquent une incertitude avec des valeurs de
probabilité attribuées ou des expressions formules avec des paramètres d'entrée.
La page de la boîte à outils « Arbre Décision » contient une gamme d'éléments qui
peuvent être utilisés et deux Motifs qui peuvent être utilisés pour créer un
diagramme donnant à l'analyste un point de départ.

Filtres de Diagramme peuvent également être utilisés lors de la présentation des

diagrammes pour attirer l'attention sur des parties des diagrammes . Les
diagrammes peuvent être présentés sous forme dessinée à la main ou sous la forme
d'un tableau blanc en modifiant les propriétés du diagramme .

Apprenez Plus sur le Decision Tree

Diagramme d'Arbre
Décision

Diagrammes de tableau de bord

diagrammes du tableau de bord vous permettent de créer des tableaux et des graphiques de haute qualité pour afficher les
informations du référentiel de manière visuellement convaincante. Ce diagramme est un exemple de création d'un
diagramme de tableau de bord dans Sparx Systems Enterprise Architect ; il illustre le ratio des priorités des exigences
dans un graphique à secteurs.

Enterprise Architect fournit une page Boîte à outils de graphiques et de graphiques préconfigurés, mais vous êtes libre de
créer et d'enregistrer n'importe quel nombre de graphiques, en extrayant des données depuis n'importe où dans le
référentiel. Les tableaux et graphiques fournissent des informations récapitulatives précieuses qui aident à la gestion des
Exigences . Les rapports de haut niveau et l'état du projet peuvent être facilement suivis et documentés à l'aide des
nombreux graphiques et éléments de rapport disponibles, qui sont étroitement liés au contenu et à l'état du modèle.

Apprendre à connaître Diagrammes de tableau de bord

Utilisation des diagrammes du tableau de bord présentent des vues d'informations riches mais
Diagrammes de tableau de faciles à comprendre - telles que l'état des Exigences dans une version particulière
bord du système - qui peuvent être ouvertes dans le modèle ou copiées directement dans
les présentations de la direction ou de l'équipe de projet. Ils sont utiles pour
planifier une itération telle qu'un sprint Agile afin de voir dans quelle mesure les
Exigences sont prêtes pour l'équipe de mise en œuvre ; par exemple, pour voir
quel pourcentage des Exigences ont été approuvées et sont hautement prioritaires.

Options pour Diagrammes Les diagrammes et graphiques standards disponibles dans la boîte à outils peuvent
de tableau de bord être configurés de plusieurs manières, notamment en changeant la source, en
appliquant des filtres ou en modifiant l'apparence du diagramme comme indiqué
dans ce diagramme , disponible depuis la fenêtre Propriétés du diagramme en
utilisant la section "Apparence". .

Apprenez Plus sur · Standard Charts

Diagrammes de tableaux
de bord

Interrompre lorsqu'une Variable Change de Valeur

Connaître l' Interrompre lorsqu'une Variable Change de Valeur

Introducing the Le diagramme de définition Bloc est l'un des diagrammes structurels du Systems
Interrompre lorsqu'une Modeling Language (SysML) qui peut être utilisé pour modéliser un large éventail
Variable Change de de choses. Il s'agit d'un diagramme à usage général pour les entités modélisation
Valeur dans les domaines métier et technique, comprenant les termes et concepts, Règles
Métier et les capacités en XML et les schémas de base de données.

Où trouver l' Interrompre Ruban : Conception > Diagramme > Ajouter Diagramme : Type = Ingénierie des
lorsqu'une Variable Systèmes > SysML Select From = SysML 1.5 Types Diagramme = Définition Bloc
Change de Valeur > <type requis>
Fenêtre Navigateur Barre d'outils : Icône Nouveau Diagramme : Type = Ingénierie
des Systèmes > SysML Select From = SysML 1.5 Types Diagramme = Définition
Bloc > <type requis>
Fenêtre Navigateur Menu Contexte | Ajouter Diagramme : Type = Ingénierie des
Systèmes > SysML Select From = SysML 1.5 Types Diagramme = Définition Bloc
> <type requis>

Utilisation de l' Le diagramme de définition Bloc peut être utilisé chaque fois qu'une
Interrompre lorsqu'une représentation logique ou structurelle d'un système est requise. Il est applicable à
Variable Change de modélisation de concepts commerciaux et d'ingénierie. C'est le diagramme
Valeur fondamental pour modélisation la structure d'un système ou d'un sous-système ou
de l'un de ses composants.

Options pour l' La définition Bloc (comme n'importe quel diagramme ) peut être considérée
Interrompre lorsqu'une comme une liste d'éléments, ce qui facilite le travail avec les propriétés de
Variable Change de l'élément.
Valeur Filtres de Diagramme peuvent également être utilisés lors de la présentation des
diagrammes pour attirer l'attention sur des parties des diagrammes . Les
diagrammes peuvent être présentés sous forme dessinée à la main ou sous la forme
d'un tableau blanc en modifiant les propriétés du diagramme .

Apprenez Plus sur l' Using Blocks to Model Structure and Constraints
Interrompre lorsqu'une
Variable Change de
Valeur

Calendrier
Connaître le calendrier

Présentation du calendrier Le calendrier est un mécanisme complet permettant d'enregistrer les événements
importants d'une initiative et d'afficher d'autres informations telles que l'allocation
des ressources. Il existe des vues journalières, hebdomadaires et mensuelles et
l'affichage peut être configuré pour afficher les entrées du calendrier, les tâches du
projet et l'allocation des ressources. Lorsqu'une ressource a été alloué - par
exemple pour analyser un ensemble d'exigences - un utilisateur peut accéder au
niveau supérieur du calendrier jusqu'à l'emplacement des exigences dans la fenêtre
Navigateur .

Il existe également des types d'événements, des catégories et des couleurs

entièrement configurables. Le travail d'un Analyste Métier impliquera un large
éventail d'événements incluant : des ateliers, des entrevues, des groupes de
discussion, des jeux collaboratifs, des séances de brainstorming, révisions , des
observations et des réunions. Tous ces événements peuvent être facilement
enregistrés et gérés dans le calendrier. Lorsque des ressources ont été alloué entre
des éléments et que des tâches ont été assignées à des individus, celles-ci peuvent
être affichées dans le calendrier.

Où trouver le calendrier Ruban : Démarrer > Collaborer > Calendrier

Utilisation du calendrier Le calendrier peut être utilisé pour planifier et afficher des événements tels que
des réunions, des jalons, révisions , des ateliers et bien plus encore. Il peut être
utilisé pour visualiser l'allocation des ressources aux éléments du référentiel, par
exemple qui analyse un ensemble d'exigences. Il peut également être utilisé pour
afficher les tâches du projet. Un analyste peut facilement cliquer sur les éléments
de la fenêtre du Navigateur ou des tâches du projet.

Options pour le calendrier Le calendrier propose un certain nombre d'options, notamment la possibilité de
créer des événements récurrents. Il existe une icône dans la barre d'outils d'options
qui permet de configurer certains aspects de l'apparence du calendrier.

Apprenez Plus sur le The Model Calendar

Calendrier

Diagramme Interne de Bloc

Connaître le Diagramme Interne de Bloc

Présentation du Le diagramme Bloc interne est utilisé conjointement avec l' Interrompre lorsqu'une
Diagramme Interne de Variable Change de Valeur , mais il est généralement utilisé pour montrer la
Bloc structure interne d'un Bloc y compris ses parties, et comment elles fonctionnent
ensemble pour offrir les comportements spécifiés par le bloc ou celui-ci. y ont été
alloué .

Où trouver le Diagramme Ruban : Conception > Diagramme > Ajouter Diagramme : Type = Ingénierie des
Interne de Bloc Systèmes > SysML Select From = SysML 1.5 Types Diagramme = Bloc interne >
<type requis>
Fenêtre Navigateur Barre d'outils : Icône Nouveau Diagramme : Type = Ingénierie
des Systèmes > SysML Select From = SysML 1.5 Types Diagramme = Bloc
interne > <type requis>
Fenêtre Navigateur Menu Contexte | Ajouter Diagramme : Type = Ingénierie des
Systèmes > SysML Select From = SysML 1.5 Types Diagramme = Bloc interne >
<type requis>

Utilisation du Diagramme Le diagramme Bloc interne est utilisé pour modéliser la structure interne d'un bloc,
Interne de Bloc y compris ses parties et la relation entre ces parties.

Options pour le Le diagramme Bloc interne (comme tout diagramme ) peut être considéré comme
Diagramme Interne de une liste d'éléments, ce qui facilite le travail avec les propriétés de l'élément.
Bloc Filtres de Diagramme peuvent également être utilisés lors de la présentation des
diagrammes pour attirer l'attention sur des parties des diagrammes . Les
diagrammes peuvent être présentés sous forme dessinée à la main ou sous la forme
d'un tableau blanc en modifiant les propriétés du diagramme .

Apprenez Plus sur le Using Properties and Parts to Model Block Usage
Diagramme Interne de
Bloc

Diagramme de cas d'utilisation

Connaître le diagramme de cas d'utilisation

Présentation du Le diagramme de cas d'utilisation est l'un des diagrammes Comportementale du

Diagramme de cas Unified Modeling Language (UML) qui peuvent être utilisés pour décrire les
d'utilisation objectifs des utilisateurs et des autres systèmes qui interagissent avec le système
modélisé. Ils sont utilisés pour décrire les exigences fonctionnelles d'un système,
d'un sous-système ou d'une entité et présentent une image simple mais
convaincante de la façon dont le système sera utilisé.

Elles sont généralement utilisées conjointement avec Exigences de niveau

supérieur Métier et les parties prenantes et sont souvent complétées par un
ensemble d' Exigences non fonctionnelles.

Où trouver le Diagramme Ruban : Conception > Diagramme > Ajouter un diagramme > Comportementale
de cas d'utilisation UML > Cas d'utilisation
Barre d'outils de la fenêtre Navigateur : icône Nouveau Diagramme > UML
Comportementale > Use Case
Menu contextuel de la fenêtre Navigateur | Ajouter Diagramme ... >
Comportementale UML > Cas d'utilisation

Utilisation du Diagramme Le diagramme de cas d'utilisation est utilisé pour décrire les objectifs que les
de cas d'utilisation utilisateurs ou d'autres systèmes souhaitent atteindre en interagissant avec le
système. Ils décrivent toujours l'objectif du point de vue des acteurs, les détails du

cas d'utilisation décriront l'objectif avec plus de précision.

Les cas d’utilisation serviront souvent de base à la définition des cas Test .

Options pour le N'importe quel nombre de diagrammes de cas d'utilisation peut être créé pour
Diagramme de cas représenter différentes parties d'un système ou Paquetages de cas d'utilisation. Les
d'utilisation diagrammes peuvent rester simples ou ils peuvent être structurés par l'application
d'un certain nombre de connecteurs supplémentaires tels que les relations
d'inclusion, d'extension et de généralisation.
Un système Bordure peut être inclus et utilisé pour nommer le système, le
sous-système ou l'entité en discussion ; les Acteurs se trouvent à l'extérieur de la
Bordure et les Cas d'Utilisation à l'intérieur.

diagrammes de cas d'utilisation peuvent être utilisés pour montrer comment les cas
d'utilisation sont liés à d'autres éléments du système, y compris des éléments en
amont tels que Exigences et des éléments en aval tels que les composants.
Le diagramme de cas d'utilisation (comme tout diagramme ) peut être visualisé
sous la forme d'une liste d'éléments, ce qui facilite l'utilisation des propriétés de
l'élément.
Filtres de Diagramme et Diagramme Layers peuvent également être utilisés lors de
la présentation des diagrammes , pour attirer l'attention sur des parties des
diagrammes et les diagrammes peuvent être présentés comme dessinés à la main
ou dans un style de tableau blanc en modifiant les propriétés du diagramme .

Apprenez Plus sur le Use Case Diagram

Diagramme de Cas
d'Utilisation

Audit
Apprendre à connaître l'audit

Présentation de l'audit La fonctionnalité d'audit peut suivre les modifications apportées aux Exigences , y
compris ce qui a été modifié, quand cela a été modifié et par qui. L'audit est
désactivé par défaut et doit être activé avant que les modifications apportées aux
exigences soient enregistrées. Une fois activé, c'est un outil passif qui enregistre
silencieusement les modifications apportées aux éléments. Il ne remplace pas
Contrôle de Version ou Lignes de base et contrairement à ces outils il ne peut pas
être utilisé pour revenir à un état antérieur du modèle. La gestion du changement,
la gouvernance et le contrôle qualité sont tous facilités par l’utilisation de l’audit.

Où trouver l'audit Ruban : Paramètres > Modèle > Audit

Utilisation de l'audit L'audit peut être utilisé pour suivre ce qui a été modifié dans un modèle, qui l'a
modifié et quand. Il existe un certain nombre de modes et un administrateur de
référentiel peut utiliser les paramètres pour spécifier ce qui est enregistré dans
l'audit. Alors qu'une référence peut être utilisée pour montrer la différence entre un
modèle et un instantané à un moment donné, l'outil d'audit enregistre chaque
changement individuel ; il ne peut cependant pas être utilisé pour revenir à un état
antérieur.

Options d'audit Il existe un large éventail de paramètres pour configurer l'audit, à commencer par
l'activation ou la désactivation des paramètres qui déterminent quels éléments
disposent d'une piste d'audit et le niveau de détail enregistré. Les journaux d'audit
peuvent être exportés depuis le référentiel pour augmenter les performances.

Apprenez Plus sur l'Audit Auditing

Diagramme d'activité
Le diagramme d'activité est l'un des diagrammes Comportementale du Unified Modeling Language (UML) qui peut être
utilisé pour modéliser un processus ou un algorithme sous la forme d'une séquence d'étapes. Il s'agit d'une version plus
sophistiquée de son proche cousin le diagramme Flowchart. diagrammes d'activités peuvent être utilisés pour modéliser
Métier Processus comme alternative UML au diagramme BPMN Processus Métier ; ils ont la même capacité à créer une
hiérarchie d'Activités dans la fenêtre Navigateur .

Les éléments peuvent recevoir un nom et des descriptions détaillées peuvent être ajoutées aux Notes . En connectant les
activités, les décisions et les forks avec des connecteurs (flux de contrôle), une séquence d'éléments peut décrire le
processus métier. Une hiérarchie de processus peut être construite en imbriquant les activités dans la fenêtre Navigateur
et en utilisant la fonctionnalité diagramme enfant pour permettre une analyse descendante du niveau de la chaîne valeur
jusqu'aux processus de niveau le plus bas.

Connaître le Diagramme d'activités

Où trouver le Diagramme Ruban : Conception > Diagramme > Ajouter Diagramme > UML >
d'activités Comportementale > UML Comportementale > Activité
Barre d'outils de la fenêtre Navigateur : Icône Nouveau Diagramme > UML >
Comportementale > UML Comportementale > Activité
Menu contextuel de la fenêtre Navigateur | Ajouter Diagramme ... >
Comportementale UML > Activité

Utilisation du Diagramme Le diagramme d'activité peut être utilisé pour modéliser toute activité ou notion
d'activités commerciale ou technique comportant une série d'étapes. Cela inclut les processus
commerciaux et techniques ainsi que les algorithmes informatiques. Les étapes
sont reliées par des relations de flux de contrôle qui montrent le séquencement des
étapes. Les décisions et les fusions peuvent être utilisées pour modéliser le choix
et pour contrôler davantage le flux à travers l’activité. Des fourches et Jointures
peuvent être ajoutées pour diviser et réunir le flux de contrôle et des objets ajoutés
pour montrer comment les données sont fournies et consommées.

Options pour le diagrammes d'activité peuvent être dessinés à différents niveaux de formalité,
Diagramme d'activités depuis un diagramme de type organigramme de base utilisé pour représenter un

Processus Métier simple jusqu'à un diagramme sophistiqué basé sur des actions
qui peut être utilisé pour modéliser un système complexe. Il existe une boîte à
outils contenant une gamme d'éléments, de relations et Motifs pour créer les
modèles.
Le diagramme d'activité (comme tout diagramme ) peut être considéré comme une
liste d'éléments, ce qui facilite le travail avec les propriétés des éléments.
Filtres de Diagramme peuvent également être utilisés lors de la présentation des
diagrammes , pour attirer l'attention sur des parties des diagrammes , et les
diagrammes peuvent être présentés sous forme de dessins dessinés à la main ou de
tableau blanc en modifiant les propriétés du diagramme .

Apprenez Plus sur le Activity Diagram

Diagramme d'Activités

Une équation à quatre variables

Le titre de ce guide implique qu’il n’y a que deux disciplines à apprendre :
· Ingénierie Systèmes Modèles Basée (MBSE) et
· Le Systems Modeling Language (SysML)
Cependant, quatre aspects doivent être pris en compte lors de l’adoption de cette approche. C'est comme une équation
avec quatre inconnues, dont chacune doit être résolue avant qu'une équipe puisse réussir un projet ou une initiative
MBSE. Les variables dans les équations sont :
· La méthode ou le processus d'ingénierie
· La discipline de modélisation
· Le Systems Modeling Language (SysML)
· Enterprise Architect , l'outil modélisation de choix
Il n'est pas impératif de maîtriser d'emblée ces quatre aspects, mais il est important qu'ils soient connus et travaillés et
que l'équipe développe les compétences nécessaires pour les comprendre individuellement et leurs relations les uns avec
les autres. Par exemple, comment créer un diagramme SysML Exigences à l'aide Enterprise Architect et quelles
propriétés doivent être incluses, quand cela doit-il être fait et à quelles autres parties du modèle doit-il être lié.
Approche MBSE = Processus + Langage + Modélisation + Outil
Le guide abordera toutes ces préoccupations et, à la fin, le lecteur ne sera pas confronté à des variables inconnues, mais
l'équation aura des valeurs basées sur la formation , résolvant ainsi l'équation avec les quatre variables avec lesquelles
nous avons commencé. À ce stade, le lecteur sera sur la bonne voie vers une solide pratique modélisation technique.

La méthode ou le processus d'ingénierie

Le Langage Modélisation des Systèmes est indépendant du processus et peut être utilisé avec n’importe quelle méthode
ou processus. Ce point n'est parfois pas compris par les nouveaux venus dans le langage qui s'attendent à ce qu'il soit
prescriptif et donne des lignes directrices claires quant aux éléments, diagramme et modèles qui doivent être créés et à
quel moment. Cette position agnostique offre une grande flexibilité et permet d’utiliser le langage de manière applicable
au processus et au domaine de problème ou de solution sous-jacent.
Les éléments, connecteurs, diagrammes et définitions de langage définis dans le cadre du langage Modélisation de
systèmes ont tous été créés dans le but exprès de permettre aux ingénieurs de créer des modèles :
· mission
· parties prenantes
· exigences
· mesures d'efficacité
· aspects structurels et comportementaux d'un système tels que les composants qui mettent finalement en œuvre les
exigences
Le processus utilisé par une équipe pour créer, gérer et diffuser les artefacts est complètement arbitraire et doit être défini
au niveau de l'organisation ou de l'équipe.
L'ingénierie système nécessite généralement une approche collaborative ou multidisciplinaire où les équipes travaillent
ensemble pour produire un résultat qui répond aux besoins des parties prenantes. Il y a deux aspects importants dans tout
processus :
· Un processus de gestion - qui régit les parties prenantes, les risques, le calendrier, le budget et la qualité
· Un processus technique - qui gère l'architecture, l'analyse, la conception, l'intégration et les tests
Cependant, les deux processus nécessitent clairement des points de contact pour garantir que la mission globale ainsi que
les buts et objectifs du projet sont atteints.
Enterprise Architect vous permet d'utiliser n'importe quel type de processus, qu'il soit formellement défini, intégré à une
norme ou élaboré en interne. Il existe également facilités dans Enterprise Architect qui vous permettent de définir,
publier et partager un processus sur mesure.

Une équipe bien accompagnée

Enterprise Architect fournit une large gamme d'outils qui aideront les équipes à collaborer, quel que soit leur
emplacement géographique ou la façon dont elles sont séparées par le temps et la distance. Le produit a été construit dès
le départ comme une plate-forme collaborative, permettant aux parties prenantes techniques et non techniques,
techniques et non techniques, de travailler ensemble dans une structure collaborative et intégrée.
Le référentiel peut être basé sur le cloud et les utilisateurs peuvent se connecter en toute sécurité depuis n'importe où
dans le monde, créant ainsi une équipe virtuelle. Ceci est important pour un certain nombre de projets pour lesquels
l'expertise n'est pas disponible localement ou lorsque le projet lui-même est mondial. Les utilisateurs et les équipes
peuvent utiliser les fonctionnalités de collaboration telles que Discussions, Chats, Révisions et Mail de Modèle pour
travailler ensemble. Le résultat sera une architecture et une conception collaboratives qui ne sont pas le résultat du travail
d’un seul ingénieur, mais le fruit de nombreux esprits, et le travail sera plus que la somme de ses parties.

Ces outils sont efficaces car ils peuvent être utilisés pour annoter des modèles, des éléments et diagrammes , permettant
aux utilisateurs de travailler ensemble comme s'ils travaillaient en collaboration sur un tableau blanc dans la même pièce.
Bibliothèque de Modèle est un autre outil de collaboration pratique qui permet à tout type de fichier d'être soit inclus
dans le référentiel, soit répertorié avec un lien hypertexte et/ou une référence URL vers son emplacement externe sur un
site Web. Des documents tels que des normes, des spécifications, des lignes directrices, guidage , des exemples, des
mentors et d'autres documents peuvent tous être catalogués dans la Bibliothèque d'Équipe .

Il existe une large gamme d'autres outils qui peuvent être utilisés pour faciliter le travail d'équipe, notamment les
fonctionnalités Gestionnaire d'images, Calendriers, Publication, Kanban, Gestion de Projet et bien d'autres. Cet exemple
montre un diagramme Kanban qui peut être utilisé pour visualiser ce sur quoi travaille une équipe Agile développant des
composants physiques ou logiciels d'un système. Pour plus d'informations, consultez la rubrique d'aide The Modeling
Team .

Modélisation comme discipline

La plupart des gens, y compris les ingénieurs système, trouvent généralement plus facile de rédiger une longue
description d'un sujet plutôt qu'un résumé succinct et concis - ceci est analogue au défi de modélisation .
La question n’est pas tant de savoir quoi inclure, mais plutôt ce qu’il faut laisser de côté.
L’un des avantages de l’ingénierie système basée sur des modèles est précisément celui-ci : elle encourage les ingénieurs
à créer des modèles descriptifs, clairs et concis. Les phrases longues (et parfois décousues) des processus basés sur des
documents sont remplacées par diagrammes clairs et laconiques qui décrivent sans ambiguïté les exigences, la structure
et le comportement du système.

Certains décrivent modélisation comme une discipline hermétique et en parlent comme d'un des « arts sombres »
pratiqués par des ingénieurs alchimistes vêtus de robes violettes. Cela sous-tend le problème selon lequel modélisation
est rarement enseignée en tant que matière dans nos universités et qu'il n'existe pas non plus de grandes quantités de
littérature sur le sujet, ce qui la fait apparaître comme un art mystérieux plutôt que comme ce qu'il est : une science qui
peut être apprise.
Il existe différents types de modèles, notamment :
· Modèles à Échelle
· Modèles physiques
· Modèles abstraits
Dans ce guide, nous nous intéressons surtout aux modèles abstraits, car ce sont les modèles que nous créerons

généralement à l'aide Enterprise Architect et du Langage Modélisation des Systèmes .

Ces modèles sont - comme leur nom l'indique - des abstractions de la réalité qui cherchent à mettre en évidence les
aspects les plus importants d'une entité, d'un sous-système ou d'un système, tout en laissant de côté les éléments qui ne
sont pas importants ou qui ne sont pas pertinents de ce point de vue. Pour plus d'informations, consultez le Rubrique
d'aide sur Models .

Démarrage
Un modèle abstrait est une représentation d’un objet du monde réel d’une manière qui nous aide à raisonner sans avoir
besoin de voir l’objet réel. Généralement, un modèle est beaucoup plus petit et constitue une vue simplifiée d’un système
ou de l’une de ses parties. Un modèle peut également être créé qui se concentre sur un seul aspect ou facette d'un
système ; par exemple, le système de communication ou de navigation d'un avion.
Un bâtiment est une structure complexe qui comporte un certain nombre de systèmes différents, notamment structurels,
électriques, de ventilation, de plomberie, d'aménagement paysager et bien plus encore.

En construisant un certain nombre de modèles, nous sommes en mesure de créer une vue simplifiée de chacun des
sous-systèmes, ce qui facilite la compréhension de cet aspect du bâtiment. Les modèles eux-mêmes doivent également
être comparés les uns aux autres. Par exemple, il est essentiel que le système électrique représenté dans le modèle
électrique fournisse de l'électricité à l'équipement de climatisation modélisé dans le système de ventilation. Le modèle
d'utilisation humaine doit être comparé au modèle de paysage pour garantir que les jardins et l'aménagement paysager
répondent aux besoins récréatifs des occupants et de leurs visiteurs.
Un modèle sera généralement vu par un certain nombre de parties prenantes différentes qui ont généralement des rôles
assez disparates en ce qui concerne la partie du système modélisée. Pour garantir que le modèle est utile à une partie
prenante particulière, des vues peuvent être créées représentant ce qui est vu lorsque l'on regarde le modèle d'un point de
vue particulier.
Le modèle électrique du bâtiment est utile à un certain nombre d'intervenants différents, qui ont tous un point de vue
différent sur le système, notamment le responsable du réseau électrique, l'inspecteur de sécurité, l'électricien et le
responsable des achats.

Définir le but d'un Modèle

Le passage à l'ingénierie système basée Modèle entraîne un certain nombre de défis et de pièges pour les équipes plus
habituées à travailler avec des méthodes centrées sur les documents. Le piège le plus courant consiste probablement à
démarrer modélisation sans avoir une compréhension ou une définition claire de l’objectif des modèles.
En comparaison avec les approches modélisation centrées sur les documents, il est plus difficile de définir l’objectif d’un
modèle que de définir l’objectif d’une suite de documents. Le modèle est bien plus utile et efficace qu'un document et
peut être utilisé pour effectuer un travail inimaginable avec un système basé sur des documents. Certains des avantages
de l’approche basée sur un modèle sont :
· Les contrôles de cohérence peuvent être facilement appliqués
· Des vues alternatives peuvent être facilement créées et maintenues cohérentes
· Si une documentation est requise, elle peut être générée automatiquement
· Les modèles sont imbriqués et cohérents
· L’impact du changement peut être visualisé et automatisé
· Les modèles peuvent rester conformes à un métamodèle sous-jacent
· Les modèles peuvent être versionnés et référencés
· La traçabilité Exigences peut être facilement gérée
· Les modèles peuvent être facilement manipulés et modifiés
· Le modèle peut être utilisé pour générer du code et des normes
· Les modèles peuvent être simulés pour produire des visualisations riches
· Les modèles peuvent être transformés d'un niveau d'abstraction à un autre
· Certaines parties du modèle peuvent être facilement réutilisées pour créer de l'efficacité
Ce diagramme montre comment la traçabilité peut être visualisée et gérée dans l'outil, vous permettant de visualiser la
manière dont les parties des modèles s'emboîtent et comment les éléments forment un graphique de connexions, vous
aidant ainsi à décrire et à comprendre votre modèle.

Enterprise Architect exploite la puissance de SysML, ainsi qu'un large ensemble d'outils conçus pour les responsables de
l'ingénierie système, les ingénieurs système et d'autres parties prenantes, offrant des moyens simples mais efficaces de
tirer parti de l'approche Model-Based Ingénierie des Systèmes .
Il existe d’autres avantages considérables qui peuvent être obtenus en passant à une approche basée sur des modèles,
notamment en garantissant que les projets et les programmes de travail sont exécutés avec rigueur, productivité et
efficacité à l’aide d’un outil qui encourage l’excellence et la collaboration. Pour plus d’informations, consultez la
rubrique d’aide Why Enterprise Architect? .

Décider où Démarrer
Le processus de modélisation peut être assez intimidant pour les ingénieurs qui débutent chez Ingénierie Systèmes
Modèles Basée . Apparemment, plus que toute autre chose, c'est la question de savoir par où commencer modélisation -
l'équivalent pour l'ingénieur de l'inertie de la « toile vierge » de l'artiste.
Enterprise Architect apporte une solution bienvenue à ce problème, en fournissant une série de motifs qui peuvent être
utilisés pour créer des points de départ pour une initiative ou un projet, y compris tous les types diagramme SysML avec
un certain nombre de motifs pour chaque type. Pour plus d'informations, consultez la rubrique d'aide The Model Wizard ,

Les manuels décrivent généralement une série d'étapes qui doivent être effectuées dans un ordre prescrit, mais dans la
pratique, ces recettes ne fonctionnent pas car les projets sont nettement plus complexes que les méthodes génériques
décrites dans les livres, et les dépendances complexes entre les projets et les ressources signifient que les tâches ne peut
être exécuté dans un ordre prescrit.
Le point de départ sera généralement déterminé par la méthode ou le processus d'ingénierie utilisé pour le projet, qui peut
être une cascade, un itératif, une combinaison des deux ou un autre type de processus. Quel que soit le type de processus
utilisé, avoir une compréhension claire de la mission est souvent un bon point de départ, et définir les parties prenantes
concernées ainsi que leurs préoccupations et exigences est souvent une bonne étape suivante.

Pièces de connexion du Modèle

Le Langage Modélisation des Systèmes encourage les ingénieurs à créer une série de modèles, qui apparaîtront au novice
ou au nouveau venu dans l'ingénierie des systèmes basée sur des modèles comme une fragmentation de la vision du
système. En réalité, le SysML décrit un réseau de modèles, chacun répondant à des préoccupations particulières mais
connectés entre eux pour décrire le système et ses parties dans son ensemble.

Dans cette illustration, nous voyons un diagramme Enterprise Architect convaincant qui décrit les connexions entre les
parties du modèle à l'aide d'éléments et de connecteurs spécialisés, à savoir une exigence, une activité et un Bloc utilisant
la relation Allouer. Les éléments peuvent être réutilisés dans n'importe quel nombre de diagrammes , et la modification
de leurs propriétés en un seul endroit les mettra à jour dans chaque contexte. Diagrammes peuvent être créés rapidement
et facilement à l'aide d'un certain nombre de fonctionnalités , et ils peuvent être visualisés de différentes manières, telles
que des listes, tableaux et des feuilles de calcul. Les diagrammes peuvent être filtrés et les éléments peuvent être
remplacés par des icônes graphiques pour susciter davantage d'intérêt auprès d'un public non technique. Pour plus
d'informations, consultez la rubrique d'aide Model Diagrams .
C'est la véritable puissance de l'approche Ingénierie Systèmes Modèles Basée , car elle permet de visualiser un système
de multiples façons, depuis une vue complète et de haut niveau jusqu'à travers plusieurs couches de décomposition ou de
hiérarchie. Chaque niveau est connecté, les lacunes ou ruptures dans les modèles peuvent être facilement identifiées et
des solutions peuvent être trouvées.

Assurer la qualité d'un Modèle

La qualité d'un modèle se reflétera en fin de compte dans la qualité du système qu'il représente. Enterprise Architect a été
conçu pour fournir une plateforme de création et de gestion de modèles collaboratifs de haute qualité. Il existe un certain
nombre de fonctionnalités qui aident le modélisateur à atteindre le niveau de qualité requis, notamment facilités telles
que :
· Métamodèle - qui peut être défini par un utilisateur pour créer efficacement une grammaire pour le modèle,
garantissant que les utilisateurs créent des phrases modélisation « conformes » ; pour plus d'informations, consultez
la rubrique d'aide Developing Profiles
· Validation Modèle - qui permet de vérifier la conformité du modèle avec le métamodèle sous-jacent
· Discussions et chat - qui permettent aux modélisateurs de travailler en collaboration sur un problème ou une solution
· Révisions - qui permettent aux experts internes ou externes de visualiser et de critiquer les modèles
· Modèle Motifs - qui fournissent Paquetages de modèles créés par des experts pour fournir un point de départ pour
modélisation
· Recherches - qui aident à trouver des problèmes particuliers dans le modèle

Ce diagramme montre le Modèle Motifs en action, où les modélisateurs débutants et expérimentés peuvent, d'une simple
pression sur un bouton, créer des modèles et diagrammes bien formés en utilisant un corpus productif de modèles de
meilleures pratiques de l'industrie, tous conformes à SysML. Il y a également une explication détaillée et une discussion
sur la façon d'utiliser le motif , où obtenir de l'aide supplémentaire et bien plus encore. Pour plus d'informations,
consultez la rubrique d'aide The Model Wizard .

Le Systems Modeling Language (SysML)

Le Systems Modeling Language (SysML) a été défini dans le but de représenter les problèmes et solutions ou
programmes de travail des artefacts de Ingénierie des Systèmes de manière cohérente, efficace et robuste.

SysML est conçu pour fournir des constructions simples mais efficaces pour modélisation un large éventail de problèmes
et de solutions d'ingénierie système. Il peut être utilisé à diverses fins, mais il est particulièrement efficace pour spécifier
les exigences, la structure, le comportement, les allocations et les contraintes sur les propriétés du système afin de
support l'analyse technique, notamment l'analyse paramétrique et la simulation. SysML peut être utilisé avec plusieurs
processus et méthodes tels que structurés, orientés objet, itératifs, en cascade et bien d'autres.
Le langage a été conçu et enrichi pendant plus de dix ans pour s'adapter à des systèmes modélisation d'une complexité
toujours croissante. Ces changements ont vu un langage relativement compact et concis devenir plus large et plus
diversifié ; néanmoins, la majorité des projets d'ingénierie système peuvent encore être modélisés avec une plus petite
partie du langage, que l'on pourrait appeler « Core SysML ». Pour plus d'informations, consultez la rubrique d'aide
Modeling Systems in Enterprise Architect .

Enterprise Architect l'outil Modélisation

Enterprise Architect est à la fois un Modèle Référentiel et une Plateforme de Collaboration, ce qui en fait un outil
efficace pour les projets Ingénierie Systèmes Modèles Basée . Il permet aux membres de l'équipe - notamment les
sponsors de projet, les responsables de l'ingénierie, les clients et les ingénieurs - de collaborer sur des projets dans un
environnement rigoureux et productif. Grâce à WebEA et Prolaborate , la collaboration peut se poursuivre sur les
appareils mobiles tels que les téléphones mobiles, les tablettes et les ordinateurs portables.
À l’ère de l’information et de l’innovation, un outil doit faire bien plus que stocker des informations ou permettre aux
utilisateurs de visualiser diagrammes et des modèles. Enterprise Architect a relevé ce défi et propulsé son offre Ingénierie
des Systèmes à un autre niveau, avec des outils tels que :
· Scenario Builder , qui crée automatiquement diagrammes d'activité à partir des étapes du cas d'utilisation et génère
des cas de Test à partir de scénarios ; pour plus d'informations, consultez la rubrique d'aide Scenario Builder

· Statemachines Exécutables , qui permettent de générer automatiquement du code de programmation à partir de

Statemachines ; pour plus d'informations, consultez la rubrique d'aide Executable StateMachines

· Simulations Paramétriques utilisant OpenModelica ou Simulink, donnant vie à des modèles et permettant de
visualiser et d'analyser des problèmes complexes et souvent insolubles pour support l'analyse des compromis et les
investigations techniques ; pour plus d'informations, consultez l'aide Simulation sujet
Dans cet exemple, les relations entre les facteurs contrôlant un fluide circulant entre deux réservoirs sont définies :

Les modèles peuvent ensuite être simulés à l'aide des fonctionnalités avancées de simulation d'OpenModelica.

Plateforme collaborative
L’ère de l’information s’est transformée en ère de l’innovation presque pendant que nous dormions, et maintenant est
plus que jamais impératif que les équipes travaillent ensemble de manière nouvelle et cohérente. Partager des documents
et des fichiers sur disque et travailler avec diagrammes statiques sont maintenant des choses que l'on s'attend à voir dans
les musées. Des solutions réactives, robustes et innovantes ne peuvent être obtenues que par des équipes travaillant avec
des outils exceptionnels qui permettent non seulement de construire des modèles et facilitent la collaboration, mais aussi
d'effectuer le travail. Enterprise Architect est une boîte à outils multifonctions qui permet aux équipes de collaborer,
réunissant les meilleurs esprits et les mains les plus expérimentées d'un large éventail de disciplines interdépendantes.
Les personnes qui contribuent à la mise à jour et à la visualisation des modèles peuvent être dispersées
géographiquement, opérer dans des fuseaux horaires différents, provenir de différentes organisations ou même parler des
langues naturelles différentes.

Cette image montre certaines des fonctionnalités de collaboration utiles disponibles à partir du ruban Démarrer . Des
discussions et Révisions sont également disponibles sur WebEA et Prolaborate , permettant au personnel modélisation et
non-modélisation de collaborer, ce qui aboutit à des solutions plus robustes et adaptées à leurs besoins. Pour plus
d’informations, consultez la rubrique d’aide Teams & Collaboration .

Gestion de Projet Établi

Enterprise Architect propose une large gamme d'outils pour gérer un projet Ingénierie Systèmes Modèles Basée . De cette
manière, il peut servir d’atelier de gestion de projet pouvant être utilisé pour gérer un projet d’ingénierie. L'ensemble du
cycle de vie des systèmes peut être modélisé dans l'outil, depuis la conceptualisation des besoins commerciaux en
passant par la conception, la mise en œuvre, l'utilisation, support et finalement jusqu'au retrait ou à l'élimination du
système.
Il existe des diagrammes de Gantt, des calendriers, des bibliothèques Modèle , des registres de risques, de défauts, de
tâches, d'efforts et de métriques, pour n'en nommer que quelques-uns. Feuilles de Route sont une autre fonctionnalité
précieuse qui permet à un chef de projet de visualiser le développement d'un projet au fil du temps, depuis un état actuel
jusqu'à un certain nombre d'états de transition ou futurs.

Une équipe peut également travailler de manière cohérente en utilisant les tableaux Kanban intégrés qui permettent de
visualiser des éléments tels que Exigences , les témoignages d'utilisateurs, Défauts et les modifications, etc., au fur et à
mesure qu'ils sont activement travaillés. L'allocation des ressources et Propriétés telles que la priorité et le statut peuvent
être consultées via les éléments du tableau et les limites de remplissage excessif sont affichées.

Cette technique éprouvée, qui trouve son origine dans le secteur automobile japonais, a été implémentée dans Enterprise
Architect de manière à améliorer considérablement la productivité de votre équipe et de sa gestion de projet. Pour plus
d'informations, consultez la Project Build & Deploy Rubrique d'aide.

Modèle Référentiel
Enterprise Architect est avant tout un référentiel de modèles qui permet de gérer les modèles depuis leur création jusqu'à
leur retrait. Le référentiel est stocké dans une base de données relationnelle qui peut être hébergée dans une configuration
client serveur ou dans le cadre d'un service Cloud facilité , sur site ou hors site dans un environnement Cloud . Ainsi,
même si les modélisateurs travaillent avec diagrammes et des éléments visuels, ces diagramme sont tous codifiés et
stockés dans la base de données du référentiel. Le référentiel peut contenir un nombre illimité de modèles et peut être
organisé pour la réutilisation et pour les modèles d'entreprise et de projet. Pour plus d'informations, consultez la rubrique
The Model Repository .

Où nous allons
La discipline de Ingénierie des Systèmes remonte au début des années 1900 ; On pense que le terme a été inventé pour la
première fois par les Laboratoires Bell au début des années 1940. Une soixantaine d'années s'écouleront avant que la
nécessité d'un langage dédié aux systèmes modélisation ne soit perçue en 2001, mais ce n'est qu'en 2006 que le Systems
Modeling Language (SysML) a été adopté par l' Object Management Group et est devenu le langage de choix pour les
systèmes de modélisation. décrire des systèmes.
Dans le domaine de Ingénierie des Systèmes , Enterprise Architect est devenu l'outil de choix pour de nombreux leaders
de l'industrie, en raison de son approche flexible, extensible et pragmatique de modélisation de systèmes complexes et de
sa forte conformité à la spécification Langage Modélisation des Systèmes .

En tant que plateforme, Enterprise Architect offre une capacité unique à prendre en charge l'intégration de modèles
stratégiques, commerciaux, d'ingénierie et technologiques, depuis les modèles de motivation jusqu'à la mise en œuvre de
systèmes, en passant par le support . L'outil aide l'ingénieur système à créer des modèles stratégiques - y compris
diagrammes tels que le Tableau de Bord Équilibré - des modèles de capacités, des modèles tactiques - tels que l'analyse
des écarts et Feuilles de Route - et des modèles opérationnels, attrayants pour les parties prenantes, notamment les cadres
supérieurs, les responsables de l'ingénierie. , les équipes de solutions et de mise en œuvre et les ingénieurs.

Comment cela vous aidera

Les lecteurs aborderont généralement le sujet d' Ingénierie Systèmes Modèles Basée avec des connaissances ou une
expérience existantes, même s'il s'agit de quelque chose qui a été appris lors de cours ou d'une formation sur le tas, ou
peut-être en utilisant un outil différent. Les lecteurs bénéficieront de la compréhension fonctionnalités d' Enterprise
Architect et des outils disponibles pour développer et gérer les modèles Ingénierie Systèmes Modèles Basée dans
Enterprise Architect . Ces connaissances leur permettront d’être plus productifs en tant qu’individu mais aussi en tant que
membre d’une équipe. Le lecteur découvrira également la syntaxe et la sémantique du Langage Modélisation des
Systèmes communément appelé SysML, et comment il peut être utilisé pour modéliser et même simuler des systèmes
d'ingénierie complexes.

Qui en bénéficiera

Toute personne impliquée dans le développement, la gestion ou support des initiatives Ingénierie Systèmes Modèles
Basée que ce soit à un :

· Niveau stratégique,
· Niveau Métier Valeur,
· Niveau de gestion ou
· Niveau ingénieur
bénéficieront de la lecture de ces informations. Cela couvre un large éventail de rôles, notamment :

· Clients,
· Penseurs stratégiques,
· La haute direction,
· Gestion de l'ingénierie,
· Concepteurs et architectes de systèmes,
· Concepteur de logiciels et architectes,
· Ingénieurs systèmes,
· Ingénieurs logiciels,
· Équipes de fabrication,
· Équipes de mise en œuvre,
· Le personnel Support .
Le véritable pouvoir de cette façon de travailler et d’utiliser Enterprise Architect comme outil réside dans l’unification
des équipes interdisciplinaires. Permettant ainsi à des personnes issues d'un large éventail de disciplines, potentiellement
géographiquement dispersées et travaillant à des niveaux très variés, de la stratégie au support , de partager une vision
commune du produit ou du système en cours de développement.

Ce que vous apprendrez

Ce guide vous apprendra à utiliser les riches fonctionnalités d' Enterprise Architect pour développer et gérer des
initiatives Ingénierie Systèmes Modèles Basée , à écrire et lire le Systems Modeling Language (SysML) , à créer de la
documentation et à travailler en collaboration en tant que membre d'une équipe à l'aide d'un processus d’ingénierie
formel ou informel.

Vous apprendrez quels outils facilités sont disponibles et quels outils doivent être utilisés pour exécuter une technique
particulière et en utilisant des liens vers des sujets d'aide sur la façon de les utiliser. Par exemple, quel que soit le
processus ou le cadre adopté, il faudra à un moment donné effectuer une répartition entre les éléments structurels et
Comportementale ; cette rubrique décrira la technique et la meilleure façon de la réaliser en utilisant les outils et facilités
dont vous disposez du bout des doigts en adoptant Enterprise Architect .

Aperçu de la documentation

Ce tableau fournit une liste et une description des sujets inclus dans cet ouvrage, donnant un aperçu du matériel.

Une équation à quatre Ce sujet décrit Ingénierie Systèmes Modèles Basée d'un point de vue mathématique
variables sous la forme d'une équation à quatre variables à savoir : Modélisation , Enterprise
Architect l'outil de choix, le langage modélisation de systèmes et un processus
d'ingénierie . Les mathématiques élémentaires suggèrent que nous avons besoin de
quatre équations simultanées pour résoudre un tel problème. Ce sujet présentera ces
quatre variables et suggérera des façons dont vous, en tant qu'ingénieur ou
gestionnaire, pouvez devenir compétent dans cette discipline sans avoir besoin de
résoudre les équations simultanément.
Nous verrons comment Enterprise Architect peut jouer un rôle important dans les
quatre parties de l'équation et a été conçu pour vous aider à réussir vos initiatives
d'ingénierie.

Démarrage Ce sujet présente aux nouveaux arrivants l'outil les aspects les plus importants de
l'application, notamment la configuration d'une structure de modèle, la
personnalisation de l'application, l'utilisation de diagrammes , d'autres façons de
visualiser le contenu et les intégrations avec d'autres outils. Il comprend également
des discussions sur l'interface utilisateur, notamment les rubans et Perspectives , qui
sont fondamentaux pour travailler avec l'outil.
L'outil dispose d'un système d'aide complet qui a été développé sur plus de vingt
ans et qui peut fournir des réponses à presque toutes les questions qu'un ingénieur
ou une autre partie prenante pourrait se poser lorsqu'il travaille dans l'outil.

Où nous allons Cette rubrique décrit la liste des rubriques du Guide, en donnant un aperçu de
chaque rubrique.

Apprendre à connaître les Cette rubrique présente le diagramme comme méthode préférée et la plus
Diagrammes SysML couramment utilisée pour visualiser les modèles et le contenu du référentiel. Il
donne une brève introduction à chaque diagramme et permet au lecteur de
construire une carte mentale de ce que sont les diagrammes et de la manière dont ils
peuvent être utilisés à la fois pour exprimer ses idées et pour interpréter les idées
des autres.

Présentation Langage Ce sujet donne un aperçu de l'anatomie et de la physiologie du Langage

Modélisation des Modélisation des Systèmes . Il fournit un résumé utile de la notation et décrit
Systèmes l'architecture du langage. Il présente également les concepts fondamentaux,
notamment : éléments, Diagrammes , modèles et Vues . Bien que ces informations
puissent être tirées de la Spécification elle-même, elles sont résumées dans ce sujet
avec suffisamment de détails pour protéger le nouveau venu de la nécessité de
parcourir la spécification.
Enterprise Architect fournit des exemples de modèles et un système d'aide complet
qui constitueront des ressources utiles pour aider les nouveaux arrivants et les

praticiens expérimentés à acquérir de l'expérience avec le langage.

Collaborer en tant Ce sujet présente les formidables outils de collaboration grâce auxquels les
qu'équipe d'ingénierie ingénieurs système, les gestionnaires, les clients, les ingénieurs-conseils, les
régulateurs et les organismes de normalisation peuvent tous contribuer aux
modèles. Cela comprend des discussions, des chats, des modèles de courrier, une
bibliothèque d'équipe, révisions et bien plus encore.

Utiliser Paquetages pour Ce sujet couvre l'aspect fondamental de la structure du référentiel et la manière dont
Structurer le Référentiel elle est utilisée comme principe d'organisation pour garantir que le référentiel est
adapté à son objectif. Il explique également comment le Paquetage peut être utilisé
comme un conteneur permettant à la fois d'ajouter du contenu mais fournissant
également un mécanisme de gestion des éléments, propriétés, diagrammes et vues
ajoutés à chaque Paquetage .

Définition et gestion Ce sujet présente à l'ingénieur et aux autres parties prenantes cette discipline très
Exigences importante et centrale qui constitue la base de tous les autres aspects d'un effort
modélisation . Enterprise Architect dispose d'un ensemble formidable et inégalé
d'outils pour développer, gérer, visualiser et documenter les exigences. Ceux-ci sont
présentés et des exemples pratiques sont donnés sur la façon dont l'outil peut être
utilisé.

Décrire les objectifs des Cette rubrique décrit une manière centrée sur l'utilisateur d'articuler les exigences,
utilisateurs avec des cas où l'objectif que l'utilisateur tente d'atteindre constitue la base sur laquelle une
d'utilisation exigence est écrite. Les objectifs des utilisateurs sont codifiés dans des cas
d'utilisation, représentés simplement sur un diagramme mais dont les détails sont
étoffés dans Enterprise Architect à l'aide du Scenario Builder. Cette facilité permet
d'écrire la description, les contraintes telles que les préconditions et les
post-conditions, ainsi que les étapes des scénarios dans une interface utilisateur
convaincante et productive. Il décrit également comment diagrammes
comportementaux peuvent être générés automatiquement à partir de l'outil, et les
éléments tels que les activités peuvent être liés à des éléments modélisation en
amont tels que Exigences et aux éléments en aval tels que les composants - créant
ainsi une traçabilité efficace et utile.

Utiliser des blocs pour Le Bloc , présenté dans cette rubrique, est l'unité fondamentale de structure du
Modèle une structure et langage et peut également être utilisé pour modéliser des contraintes. C'est l'atome
des contraintes du langage SysML et peut avoir Fonctionnalités , Propriétés et Points d'Interaction
qui décrivent en détail l'anatomie. Cette rubrique décrit également les relations que
les blocs entretiennent avec d'autres éléments du modèle, y compris la relation
d'allocation très importante qui relie les blocs aux activités. Les allocations relient
les deux piliers importants du SysML : Structure et Comportement . Il présente
également des dispositifs de modélisation des types de quantités et de valeurs qui
peuvent être utilisés pour modéliser des dimensions dans le monde physique.

Utilisation Propriétés et Cette rubrique fait suite à la rubrique précédente et présente le diagramme Bloc
des pièces pour interne, qui permet de visualiser comment les blocs sont utilisés dans un contexte
l'utilisation Modèle Bloc donné. Ces diagrammes montrent comment les propriétés des pièces d'un Bloc
peuvent être connectées entre elles. Le Bloc propriétaire est représenté sous forme
de cadre diagramme et les pièces qui apparaissent à l'extrémité de l'association de
pièces sur un diagramme de définition de Bloc apparaissent sur le diagramme Bloc
interne en tant qu'élément de pièce.

Coordonner le Cette rubrique présente les activités et l'unité plus atomique, l' Action , qui sont
comportement avec les toutes deux utilisées pour décrire les aspects comportementaux d'un système à
activités différents niveaux. Ces éléments essentiels sont équivalents aux verbes de nos
langues naturelles et, comme les verbes, ont une fonction organisatrice dans le
modèle. Enterprise Architect dispose d'un certain nombre de dispositifs utiles tels

que des simulations qui peuvent donner vie à ces modèles et permettre de simplifier
et de visualiser des problèmes complexes du monde réel.

Visualiser avec des Cette rubrique explore l'utilisation des diagrammes Paramétriques en relation avec
paramètres et des diagrammes Bloc Definition , qui définissent des ConstraintBlocks qui modélisent
simulations les équations mathématiques et les paramètres qu'elles utilisent. Le sujet décrit
comment ces contraintes et paramètres peuvent être représentés sur le diagramme
Paramétriques , qui est un cousin du diagramme Internal Bloc . Simulation des
diagrammes Paramétriques est également introduite et vous apprendrez à installer et
à travailler avec l'interface OpenModelica. Vous apprendrez comment visualiser
des tracés d'équations avancés sans avoir à quitter l'environnement Enterprise
Architect .

Modélisation Ce sujet présente la Statemachine comme méthode de description des conditions

Changement avec discrètes ( States ) qu'une entité telle qu'un Bloc peut présenter. Ce dispositif
Statemachines comportemental peut apporter une grande clarté à un modèle et résoudre des
problèmes autrement insolubles. Enterprise Architect dispose d'un certain nombre
de fonctionnalités d'outils qui peuvent donner vie à ces modèles, à savoir le State
Tableau et Statemachines Exécutables qui permettent aux States et aux transitions
d'être actifs dans des visualisations convaincantes.

Interactions comme Dans cette rubrique, le diagramme Séquence est présenté comme un moyen de
Séquence de messages modélisation des comportements basés sur des messages. Vous apprendrez à utiliser
ce diagramme pour modéliser une gamme de concepts d'ingénierie. Les
diagrammes modélisent l'interaction entre les blocs internes au système, ou entre le
système lui-même et son environnement, et ils peuvent être utilisés pour modéliser
la communication qui se produit avec les étapes d'un cas d'utilisation. Les lignes de
vie et les activations sont étudiées et l'orchestration des messages est introduite
avec l'utilisation de fragments.

Un premier exemple Dans ce sujet, nous explorons les diagrammes qui spécifient, conçoivent et testent
Modèle SysML un véhicule SUV hybride qui utilise du carburant et de l'électricité comme sources
d'énergie, doté de mécanismes tels que le freinage par récupération pour répondre à
ses exigences en matière d'efficacité énergétique. L'exemple de modèle est publié
dans une annexe de la spécification SysML ; dans cette rubrique, nous explorons les
diagrammes qui ont été créés dans Enterprise Architect , expliquant les principales
fonctionnalités du langage et des outils.

Rencontrez les outils Cette rubrique présente certains des outils les plus importants pour travailler avec
Ingénierie des Systèmes les modèles Ingénierie des Systèmes , décrivant ce qu'ils sont, où ils peuvent être
trouvés et comment ils peuvent être utilisés, y compris les options et où trouver de
l'aide supplémentaire. Il existe de nombreux autres outils que les modélisateurs
pourraient trouver utiles ; ceux-ci sont introduits aux points pertinents du
document.

Démarrage
Démarrer avec un nouvel outil est souvent l'un des défis les plus difficiles, mais Enterprise Architect facilite la tâche en
fournissant un certain nombre de facilités pour aider le nouveau venu dans l'outil. Enterprise Architect est une application
volumineuse et polyvalente et l'étendue de sa couverture pourrait submerger une personne qui découvre le programme,
mais heureusement, une solution à ce problème a été intégrée à la conception.
Perspectives peuvent être utilisées pour limiter les fonctionnalités à un domaine spécifique, tel que l'ingénierie système,
ce qui facilite le démarrage d'un ingénieur système ou d'un gestionnaire. Un utilisateur a toujours la possibilité d'utiliser
d'autres fonctionnalités qui pourraient être utiles, telles que Modélisation Stratégique , le Mind Mapping, l'Ingénierie du
Code et plus encore, simplement en changeant Perspectives , le tout sans avoir à ouvrir un autre outil. Il convient de
noter que Perspectives existent pour un large éventail de disciplines modélisation supporte par Enterprise Architect . Pour
plus d'informations, consultez la rubrique d'aide Model Perspectives .

Un utilisateur dispose également d'une grande flexibilité pour personnaliser son propre environnement et l'interface
utilisateur en définissant ses préférences et en sélectionnant des espaces de travail et des styles visuels. Pour plus
d'informations, consultez la rubrique d'aide Advanced Customization .

La mise en place d'un nouveau projet est simple grâce à l'utilisation de l' Assistant de Modèle Motifs (avec
documentation d'accompagnement) qui peut être utilisé pour créer automatiquement une structure de projet MBSE pour
vous aider à démarrer. L' Assistant de Modèle (onglet Page Démarrage 'Créer à partir de Motif ') peut ensuite être utilisé
pour créer un nombre illimité de diagrammes SysML au fur et à mesure que le modèle est développé et que les espaces
de problèmes et de solutions sont étoffés.

Toutes ces facilités facilitent le démarrage d'un nouveau venu, l'aidant à devenir des membres productifs d'une équipe et
à commencer à contribuer aux modèles rapidement et sans délai. Un ingénieur débutant sera surpris de voir à quel point
il peut être productif par rapport à un travail avec des outils de modélisation textuels ou d'autres outils modélisation plus
rudimentaires. Il y aura des défis tout au long du chemin à mesure que vous repousserez vous-même et l'outil vers de
nouvelles limites, mais un système d'aide approfondi, une large communauté d'utilisateurs, des forums complets, un site
communautaire et des services support de premier ordre rendront le voyage facile et informatif. .

Mise en place d'une structure Modèle

Enterprise Architect a été conçu dès le départ comme un outil de productivité, et la mise en place d'une structure de
modèle - parfois une tâche ardue pour le débutant et fastidieuse pour l'utilisateur expérimenté - est simplifiée dans
Enterprise Architect grâce à l'utilisation de l' Assistant de Modèle ( Page Démarrage (onglet 'Créer à partir d' Motif ').
La structure d'une nouvelle initiative (projet) peut être créée à l'aide de l' Assistant de Modèle , qui créera une structure
de projet entière pouvant être personnalisée lors de l'importation, fournissant tous les Paquetages prêts à démarrer le
projet.

La structure du référentiel est un sujet qui sera exploré dans un sujet ultérieur, car il est essentiel au succès d'une
approche d'ingénierie basée sur des modèles pour Ingénierie des Systèmes . Nous apprendrons plus tard que Paquetages
sont des unités importantes dans l'organisation et la maintenance d'un référentiel modèle, et il existe un sujet entier dédié
au sujet de l'utilisation Paquetages pour structurer le référentiel. Pour plus d'informations, consultez la rubrique d'aide
The Model Wizard .

Adaptation de l'application
Enterprise Architect est un outil doté d'une grande quantité de fonctionnalités, ce qui est l'une des raisons pour lesquelles
il est si populaire en tant qu'outil de modélisation de systèmes de toute sorte. Pour garantir que l'outil apporte le plus
d'avantages à une organisation, une équipe, un projet ou un individu, une certaine personnalisation de l'interface en
fonction de l'intention modélisation garantira que toutes les parties obtiendront les meilleurs résultats. La plupart des
paramètres peuvent être modifiés d'un simple clic, transformant ainsi l'outil adapté à son objectif, qui - pour nous -
collabore aux projets Ingénierie Systèmes Modèles Basée .
Nous examinerons un certain nombre d'endroits où nous pouvons faire évoluer l'application d'un outil modélisation
générique à un outil d'ingénierie système. Nous examinerons ces sujets.

Sélection d'une perspective

La sélection d’une perspective revient à placer un filtre sur une lentille optique. Il permet à un modélisateur de voir
simplement facilités d'application pertinentes pour cette perspective - dans notre cas, le Systems Modeling Language
(SysML) .

Sélection d'un espace de travail

La sélection d'un espace de travail est importante car elle permet à l'utilisateur de s'assurer que les fenêtres, rubans,
barres d'outils et autres éléments visuels offrent un environnement de travail efficace et un accès facile aux facilités
importantes nécessaires.

Définition Styles Visuels

Les styles visuels fournissent une série d'options pour l'apparence de l'application, notamment des éléments tels que les
couleurs et la position des onglets.

Définition des préférences

Les préférences offrent un large éventail d'options pour personnaliser l'apparence et les fonctions Enterprise Architect ,
depuis les paramètres généraux tels que les options de la fenêtre Navigateur jusqu'aux options Diagramme , Objets et
Ingénierie. La plupart des options s'appliquent à un utilisateur individuel, d'autres concernent l'ensemble du référentiel.

Définir une perspective

Enterprise Architect est un outil doté de fonctionnalités pour un large éventail de disciplines, de méthodes, de langages et
de frameworks. Perspectives permettent à un utilisateur de sélectionner une facette de l'outil qui lui permet de se
concentrer sur un sous-ensemble particulier des fonctionnalités et facilités de l'outil. Le groupe de Perspectives d'
Ingénierie des Systèmes constitue un point de départ naturel pour les ingénieurs système, mais à tout moment, si vous
décidez d'utiliser d'autres facilités dans l'outil, vous pouvez simplement modifier Perspectives et l'outil changera pour se
concentrer sur la zone sélectionnée.

La sélection de l'une des Perspectives Ingénierie des Systèmes modifiera les outils pour se concentrer sur l'aspect
sélectionné de Ingénierie des Systèmes . Par exemple, choisir la perspective SysML affichera une série de motifs de
modèle, donnant à l'utilisateur un bon départ en pouvant charger un motif pour un fragment ou diagramme de modèle
standard. La dialogue ' Nouveau Diagramme ' affichera également simplement les types diagramme SysML.

Il existe également une facilité pratique pour un utilisateur de créer n'importe quel nombre de ses propres Perspectives ,
en ajoutant des ensembles de technologies à chaque perspective. Cela permet à un modélisateur dont la principale
préoccupation est diagrammes SysML d'ajouter d'autres facilités telles que des modèles stratégiques, diagrammes
Kanban et des dizaines d'autres mécanismes de création de diagrammes et modélisation utiles. Pour plus d’informations,
consultez la rubrique Model Perspectives .

Sélection d'un style visuel

Chaque modélisateur aura ses propres préférences concernant la palette de couleurs et le style de l'interface utilisateur, et
Enterprise Architects permet de les définir et de les enregistrer pour chaque utilisateur, ce qui rend l'application plus
attrayante. Par exemple, certains modélistes voudront une palette de couleurs sombres et d’autres préféreront une palette
claire ou colorée.

Il existe une gamme d'options ici, notamment la définition de la position des onglets de la fenêtre principale, la taille du
texte dans la fenêtre notes , et bien plus encore. La définition du style visuel aidera à personnaliser l'environnement
modélisation et à permettre aux modélisateurs individuels de se sentir à l'aise tout en conservant des modèles cohérents et
rigoureux. Pour plus d’informations, consultez la rubrique d’aide Visual Styles .

Sélection d'un espace de travail

Enterprise Architect dispose d'un moyen utile pour modifier rapidement la disposition de l' Interface Utilisateur afin de
faciliter des tâches ou des méthodes de travail particulières. Ceci est réalisé en sélectionnant simplement un espace de
travail qui modifiera les fenêtres et les outils visibles, afin de fournir la méthode de travail la plus efficace adaptée à la
tâche. Par exemple, il existe un espace de travail défini pour Ingénierie des Systèmes Simulations, un pour Use Case
Modélisation et un autre pour Tester . Vous pouvez également définir un certain nombre de dispositions de votre propre
espace de travail que vous jugez utiles, en ouvrant des fenêtres et des outils et en les positionnant dans un arrangement
qui facilite le travail sur une tâche ou un ensemble de tâches particulier, et en les enregistrant. Dans cet exemple, un
modélisateur a défini trois dispositions d'espace de travail personnalisées. Pour plus d'informations, consultez le sujet
Workspace Layouts .

Définition des préférences

Enterprise Architect dispose d'un formidable ensemble de préférences, dont certaines peuvent être définies pour
l'ensemble du référentiel et d'autres pour chaque utilisateur. Ceux-ci permettent d’adapter l’application à un ingénieur
individuel ou à une équipe entière. Pour plus d'informations, consultez la rubrique User Preferences .
Ce diagramme montre comment les thèmes diagramme peuvent être définis et les éléments du style peuvent être
spécifiés, notamment les polices, les couleurs, l'épaisseur des lignes et les dégradés.

Importation de matériel existant

Une fois Enterprise Architect a été configuré pour être utilisé, il est probable que vous ayez encore certains artefacts de
projet existants sous la forme de diagrammes , de documents, de feuilles de calcul et d'éléments dans d'autres formats.
Beaucoup d’entre eux peuvent être facilement importés dans Enterprise Architect ou référencés à partir de l’outil. L'outil
fournit également une connectivité étendue côté serveur à un large éventail d'autres outils, notamment des outils Gestion
des Exigences tels que DOORS Next Generation, des outils de gestion de projet tels que Wrike et des outils de mise en
œuvre de projets tels que Jira, via le Pro Cloud Server (un composant côté serveur sous licence distincte).

Importation de feuilles de calcul

Les feuilles de calcul sont couramment utilisées comme conteneur à usage général pour un large éventail de données de
projet numériques et textuelles. Les utilisations incluent :
· Exigences
· Analyse des parties prenantes
· Planification
· Feuilles de Route
· Sous-systèmes
· Composants
· Définitions des interfaces
· Gestion des Tâches
Bien que le tableur soit un outil très familier, il lui manque de nombreuses fonctionnalités rigoureuses et utiles d'une
plate-forme de gestion de l'information telle qu'Enterprise Enterprise Architect , notamment :
· Collaboration,
· Diagramme
· Traçabilité,
· Lignes de base ,
· Visualisations,
· Simulation
· Versions et plus encore.
Enterprise Architect a intégré la prise en support de toutes ces formes d'informations et de nombreuses autres formes
d'informations couramment stockées dans les feuilles de calcul. L'outil est également livré avec facilités pour importer et
exporter les données de la feuille de calcul en utilisant le format de fichier CSV.

Le scénario le plus courant consiste à importer les informations contenues dans les feuilles de calcul dans Enterprise

Architect , puis à mettre hors service la feuille de calcul et à gérer les actifs informationnels dans Enterprise Architect à
partir de ce moment-là.
Il peut y avoir des situations où l'utilisation des aspects d'analyse numérique d'une feuille de calcul serait utile, et
Enterprise Architect fournit commodément un outil pour exporter des informations au format de fichier CSV pour les
importer dans une feuille de calcul. Pour plus d’informations, consultez la rubrique Import and Export Spreadsheets .

Importation Diagrammes Visio

Microsoft Visio est couramment utilisé par les équipes d'ingénierie, souvent parce qu'il n'existe pas d'autres outils plus
sophistiqués disponibles et qu'il sert à créer diagrammes à usage général. Il est courant qu'une équipe qui adopte
Enterprise Architect comme plate-forme d'ingénierie de choix dispose d'une collection de diagramme Visio préexistants.
Tous ces diagrammes peuvent être importés dans Enterprise Architect , mais les résultats sont plus efficaces lorsque ces
diagramme Visio ont été construits de manière cohérente ou en utilisant des palettes industrielles standard plutôt que des
formes géométriques de forme libre telles que des carrés et des cercles qui n'ont aucune signification commune. Une fois
importés, les diagrammes peuvent être modifiés et mis à jour pour faire partie du référentiel, et les diagrammes Visio
originaux peuvent être mis hors service.
Enterprise Architect fournit un outil gratuit qui peut être utilisé pour se connecter à un moteur MS Visio et importer
diagrammes sélectionnés dans le référentiel.
Il faut décider s'il convient de mettre hors service les diagrammes dans Visio et de permettre à Enterprise Architect de
gérer les diagrammes à partir de ce moment. Avoir les diagrammes dans le référentiel offre une grande puissance, car les
éléments des diagrammes peuvent être liés à d'autres éléments du référentiel. Pour plus d'informations, consultez la
rubrique Extensions - MDG Technologies .

Utiliser la Bibliothèque d'Équipe

Même si une équipe d'ingénierie est passée à Ingénierie Systèmes Modèles Basée il est probable qu'il existera toujours
une gamme de documents et de matériel Web essentiels à la gestion et au développement de solutions d'ingénierie.
Enterprise Architect propose une approche pragmatique à ce besoin en incorporant une fonctionnalité Bibliothèque
d'Équipe où les documents et les ressources Web (locales et distantes) peuvent être rassemblés comme références.
Toutes les références cataloguées dans la Bibliothèque d'Équipe peuvent être incluses sur un diagramme en tant
qu'artefact interne ou externe, mais plus commodément, elles peuvent également être importées ou référencées. Pour plus
d'informations, consultez la rubrique d'aide The Model Library .

Intégration Microsoft Office

Enterprise Architect a la capacité de s'intégrer à la suite d'applications Microsoft Office à l'aide de MDG Link pour
Microsoft Office, facilitant ainsi l'échange d'informations entre n'importe quel modèle Enterprise Architect et MS
Powerpoint, MS Word et MS Excel . Il existe des options pour importer, exporter et synchroniser le contenu.

Microsoft PowerPoint
L'intégration PowerPoint offre un accès facile au référentiel de modèles d' Enterprise Architect dans les présentations
PowerPoint. Vous pouvez insérer des références au modèle, utiliser des noms d'éléments de modèle avec des liens
hypertextes, insérer diagrammes sous forme d'images et tabuler le contenu Paquetage sur des diapositives.
Microsoft Excel
L'outil Microsoft Excel Importer vous permet d'importer le contenu des classeurs Microsoft Excel dans Enterprise
Architect en tant qu'éléments de modèle. Cela inclut l'importation de données de feuille de calcul sous forme d'éléments,
de connecteurs, d'attributs et d'opérations UML .
Microsoft Word
L'outil Microsoft Word Importer apporte Exigences , les cas d'utilisation, Processus , les classes et d'autres données des
documents Microsoft Word dans Enterprise Architect en tant qu'éléments de modèle. L'importateur Microsoft Word
propose une approche étape par étape qui vous aide à mapper des éléments tels que des sections, tableaux et des paires
nom-valeur délimitées aux éléments et propriétés Enterprise Architect , y compris la définition Valeur Étiquetés
personnalisées.

Intégration avec des outils externes

Enterprise Architect fournit une interface (dans le cadre du Pro Cloud Server ) pour connecter vos référentiels de
modèles à des outils externes. Cela permet à Enterprise Architect de synchroniser des éléments dans des outils externes
avec des vues des éléments dans Enterprise Architect , ce qui est particulièrement utile si Enterprise Architect et un autre
outil partagent un intérêt pour des types d'informations particuliers. Un exemple est l'intégration avec le produit DOORS
Next Generation (NG), où les exigences modélisées dans DOORS peuvent être visualisées dans Enterprise Architect , et
les substituts locaux des éléments peuvent être placés sur diagrammes et liés à un certain nombre d'autres éléments
modélisation , y compris des stratégies. , études commerciales, cas d'utilisation et composants. (Il existe également une
facilité intégrée au modèle disponible pour se connecter aux anciennes versions de DOORS .)

Il existe un large éventail d'intégrations disponibles et les équipes peuvent créer leurs propres intégrations à l'aide d'Open
Services for Lifecycle Collaboration (OSLC) facilité , disponible dans le cadre du Pro Cloud Server . Pour plus
d’informations, consultez la rubrique d’aide Integrate Data from External Providers .

Création d'éléments et Relations Diagrammes

Une fois qu'une structure de modèle a été mise en place et que l'application a été adaptée à vos besoins, y compris la
sélection de la perspective SysML et un espace de travail approprié, vous êtes prêt à commencer à créer des éléments et
diagrammes . Bien qu'il soit possible de créer un élément sans créer au préalable un diagramme , il est courant de créer
d'abord un diagramme comme canevas pour la manière dont les éléments seront visualisés. La première chose à faire est
de choisir un emplacement pour le diagramme dans la fenêtre Navigateur . Par exemple, vous définissez peut-être
l'architecture fondamentale de votre système et avez défini un Paquetage appelé « Sous-systèmes ». En sélectionnant ce
Paquetage vous indiquez à Enterprise Architect que c'est ici que vous souhaitez insérer un nouveau diagramme de
sous-systèmes.

Création d'un Nouveau Diagramme

Enterprise Architect est un outil flexible et offre un certain nombre de façons d'insérer un nouveau diagramme ,
notamment :
Sélection parmi les rubans :

Sélection dans la barre d'en-tête de la fenêtre Navigateur :

Sélection dans le menu contextuel (clic droit) :

Quelle que soit la méthode que vous choisissez, vous pourrez sélectionner le type diagramme SysML dans le panneau
'Types Diagramme ' de la boîte dialogue ' Nouveau Diagramme '.

Continuons en créant un diagramme de définition Bloc pour représenter le sous-système. Sélectionnez le diagramme
Définition Bloc comme type de diagramme et entrez un nom approprié. Une fois que vous avez cliqué sur le bouton OK ,
un nouveau diagramme BDD (vierge) sera créé et la boîte à outils Interrompre lorsqu'une Variable Change de Valeur sera
affichée, prête pour vous, ou un membre de votre équipe, à créer des éléments et des relations.
Enterprise Architect créera un canevas diagramme avec un cadre visible qui représente la bordure du diagramme . Le
cadre diagramme est inclus car certains utilisateurs préfèrent le voir, mais il peut être masqué sans perte de sens ni de
conformité ; une fois masquée, la toile devient alors le cadre et les informations d'en-tête sont contenues en haut de la
toile. Le cadre peut être inclus dans diagrammes enregistrés ou publiés en choisissant cette option dans la dialogue
'Préférences'.

Ajout d'éléments à un Diagramme

Une fois le nouveau diagramme ouvert, vous êtes prêt à commencer à créer des éléments et des relations pour décrire les
sous-systèmes. Il existe essentiellement deux types d' Object qui peuvent être ajoutés à un diagramme :
· Nouveaux éléments - Créés en faisant glisser un élément de la boîte à outils et en le déposant sur le canevas du
diagramme
· Eléments existants - Placés sur le diagramme par glisser-déposer d'un élément depuis la fenêtre du Navigateur
Si vous démarrez un nouveau projet et venez de configurer votre référentiel, vous n'aurez généralement pas d'éléments
dans la fenêtre Navigateur , vous utiliserez donc davantage la première option et créerez des éléments à partir de la boîte
à outils. Au fur et à mesure que votre projet progresse, il deviendra plus courant d'utiliser la deuxième option et de faire
glisser les éléments existants depuis la fenêtre Navigateur .

Nous allons créer un certain nombre de blocs. Tout d'abord, nous avons besoin d'un Bloc pour représenter l'ensemble du
véhicule, nous allons donc glisser et déposer un élément Bloc de la boîte à outils sur le canevas du diagramme . L'outil
redimensionnera le cadre pour inclure le Bloc quel que soit l'endroit où vous l'avez placé sur la toile. L'élément recevra le
nom par défaut « Block1 ». Maintenant, en utilisant la fenêtre Propriétés , généralement ancrée sur le côté du diagramme
, changez le nom de l'élément en « Véhicule » en tapant le nom par défaut « Block1 ».

Cela changera le nom de l'élément dans la fenêtre Navigateur et dans le diagramme . En revenant au diagramme , vous
verrez le Bloc nouvellement ajouté avec le nom « Véhicule » inclus dans le cadre du diagramme .

Nous pourrions maintenant utiliser la même méthode pour ajouter une série de blocs pour représenter chacun des
sous-systèmes.

Ajout Relations à un Diagramme

Une fois que vous avez ajouté deux éléments ou plus, vous pouvez les relier avec des relations, qui fournissent le lien
sémantique entre les différents éléments du modèle. Par exemple, un élément Bloc peut être connecté à un autre élément
Bloc à l'aide d'une relation d'association de parties . Il existe deux manières principales d'ajouter des connecteurs à un
diagramme :
1. Quick Linker - un dispositif diagramme intuitif lancé en faisant glisser un lien entre la flèche Quick Linker (en haut
à droite de l'élément) et un autre object diagramme
2. Items de la boîte à outils : les connecteurs peuvent être sélectionnés dans la boîte à outils, puis glissés entre deux

objets diagramme .
Quelle que soit la méthode, le connecteur spécifié sera dessiné entre les deux éléments. Il faut faire preuve de prudence
pour s'assurer que vous avancez dans la bonne direction ; la relation d'association partielle, par exemple, devrait être
déplacée du Bloc qui se trouve à l' extrémité partielle vers le Bloc qui se trouve à l' extrémité entière . Cela garantira que
le petit marqueur en forme de diamant à la fin de la relation est positionné à la bonne extrémité, indiquant la relation de
la partie entière.

Quelle que soit la méthode utilisée, le résultat sera une relation d'exigence d'information reliant les deux blocs. La
direction et le style du connecteur peuvent être modifiés, et un nombre illimité de points de cheminement peuvent être
ajoutés pour l'acheminer différemment au fur et à mesure du développement du modèle. Ce diagramme montre la relation
ajoutée où le modélisateur a également ajouté un nom de rôle (+cu) et une multiplicité (1..2), indiquant qu'un Boom Gate
doit avoir au moins une unité de contrôle mais peut en avoir jusqu'à deux. Si un modélisateur ajoutait par inadvertance le
connecteur dans la mauvaise direction, cela peut être facilement inversé en accédant aux options du sous-menu Avancé
du menu contextuel du connecteur.

Visualiser les modèles

Vous avez peut-être découvert SysML en lisant du matériel d'introduction dans des manuels ou dans notes de cours dans
le cadre d'un diplôme d'études supérieures ou sur des pages en ligne. Une grande partie de ce contenu présente SysML
comme un langage de diagrammes , mais Enterprise Architect élargit les horizons du langage - et modélisation en général
- en fournissant diverses façons de visualiser les informations dans le référentiel. Les diagrammes jouent toujours un rôle
important, mais dans de nombreuses circonstances, il existe des moyens plus efficaces de visualiser ou d'utiliser le
contenu du référentiel, notamment :
· Spécification Vue - une feuille de calcul ou une vue de document pour ceux qui sont plus familiers avec cette façon
de travailler
· List Vue - une vue basée sur un tableau similaire à une feuille de calcul où les propriétés de plusieurs éléments
peuvent être visualisées
· Traceability Vue - une vue hiérarchique et graphique où les relations entre les éléments peuvent être visualisées à
n'importe quel niveau d'imbrication
· Matrice d'Analyse des Écarts - affiche les éléments source et cible ainsi que les lacunes dans les modèles
architecturaux
· Matrice de relation - une vue basée sur une grille avec deux axes contenant des ensembles d'éléments
· State Tableau Vue - une vue disponible pour diagrammes Statemachine pour afficher les transitions d'état dans un
tableau
· Vue du diagramme de Gantt - affichez une chronologie lorsque les ressources ont été attribuées
· Recherches : affichez les listes d'éléments conformes à un ensemble de critères intégré ou défini par l'utilisateur.
· Publications - affichez les éléments d'une publication à l'aide gabarits intégrés ou définis par l'utilisateur.
· Vue graphique - affichez les éléments sous forme de diagramme (c'est la vue par défaut)

Ce diagramme montre un diagramme de Gantt qui a été automatiquement créé à partir des informations sur les ressources
saisies par rapport aux éléments visualisés sur un diagramme Kanban. Pour plus d'informations, consultez la rubrique
d'aide Gantt View .

Synchronisation avec des données externes

Bien Enterprise Architect soit un outil central pour la gestion des projets Ingénierie Systèmes Modèles Basée , il existe
probablement un certain nombre d'autres outils qu'un bureau d'ingénierie aura en place ou acquerra dans le but de
garantir qu'une entreprise atteint ses résultats. Ceux-ci peuvent inclure des outils Gestion de Projet , des outils de
visualisation, des catalogues Gestion des Exigences , des systèmes de gestion de configuration et des logiciels de suivi
des problèmes.
Enterprise Architect , via Pro Cloud Server (un composant côté serveur sous licence distincte), fournit une intégration
bidirectionnelle avec un grand nombre d'outils, notamment :
· Portes Nouvelle Génération - utilisée pour Gestion des Exigences
· Wrike - utilisé à des fins générales Gestion de Projet
· Jira - utilisé pour le suivi des problèmes
· ServiceNow - utilisé pour la gestion de la configuration
· Share Point - utilisé pour la gestion de documents
· Team Foundation Server - utilisé pour Contrôle de Version dans la discipline logicielle
Les représentations des éléments provenant de ces sources de données externes peuvent être incluses dans diagrammes et
liées à d'autres éléments du référentiel. Cela permet à Enterprise Architect de devenir un centre d'informations
d'ingénierie, se connectant et s'intégrant à une large gamme d'outils pour fournir une vue unique d'un projet. Cette image
montre une liste actuelle des fournisseurs.

Exemple Modèle SysML

Le langage Modélisation système (SysML), comme tout langage, doit être appris. Nous n'avons pas la chance d'avoir
grandi en entendant nos parents parler la langue à la maison, mais un certain nombre de lecteurs la connaissent peut-être
déjà pour diverses raisons, notamment :
· Il a été utilisé par des collègues ou des partenaires dans des projets
· Il a été enseigné dans le cadre d'un cursus universitaire
· Vous avez suivi une formation ou lu ou consulté de la documentation
· Vous avez pris 6 semaines d'arrêt de travail et avez lu le cahier des charges d'un bout à l'autre
Si ce dernier est vrai, vous aurez probablement une connaissance approfondie du langage, mais vous aurez peut-être
besoin d'un peu de repos car il s'agit d'un document assez dense et vous aurez également besoin de vous plonger dans la
spécification Unified Modeling Language . Il est plus probable qu'un plus grand nombre de lecteurs auront peu ou pas
d'exposition au langage, et ce premier exemple est destiné à vous donner une vue rapide et de haut niveau de ce à quoi on
peut s'attendre lorsque l'on travaille dans Enterprise Architect pour modéliser une Ingénierie Systèmes Modèles Basée .
Projet Ingénierie Systèmes Modèles Basée utilisant le SysML. Il est basé sur l'exemple d'un véhicule hybride qui apparaît
dans l'exemple d'annexe de problème de la spécification.

Présentation Paquetage (Structure de l'exemple Modèle )

Le diagramme Paquetage montre une manière de visualiser le contenu du référentiel ; lorsque le contenu du diagramme
est affiché dans la fenêtre Navigateur d' Enterprise Architect la structure peut être parcourue. Il existe également
d'importantes relations structurelles et d'espace de noms qui peuvent être observées sur diagrammes Paquetage et
celles-ci aident à clarifier les relations importantes de haut niveau entre les groupes d'éléments dans le référentiel.

Diagramme Paquetage - Application du profil SysML

Comme le montre ce diagramme , le HSUV Modèle est un Paquetage qui représente le modèle utilisateur. Le profil
SysML est appliqué à ce Paquetage afin d'inclure les stéréotypes du profil. Le HSUVModel peut également nécessiter
des bibliothèques de modèles, telles que la bibliothèque de modèles SI Units Types. Les bibliothèques de modèles sont
importées dans le modèle utilisateur comme indiqué.

Diagramme Paquetage - Affichage de la structure

Paquetage du Modèle
Ce diagramme Paquetage montre la structure du modèle utilisé pour définir le système HybridSUV. Le diagramme
fournit un moyen utile de visualiser les conteneurs de haut niveau ( Paquetages ) utilisés pour structurer le référentiel et
définir la structure, le comportement et les exigences du système HybridSUV.

Les relations entre la Vue Opérationnelle et la Vue Performance et le reste du modèle utilisateur sont explicitement
exprimées à l'aide de la relation « importation ». Les Paquetages qui apparaissent dans le diagramme sont définis et
peuvent également être visualisés sous forme hiérarchique à l'aide de la fenêtre Navigateur .

Bien que la fenêtre Navigateur fournisse un mécanisme important pour naviguer dans le référentiel, il existe un large
éventail d'autres vues, y compris - dans ce cas - un diagramme . Enterprise Architect fournit également un moyen
pratique de créer diagrammes définis par l'utilisateur qui peuvent constituer un moyen alternatif de naviguer dans le
référentiel. Ce mécanisme permet aux ingénieurs système et autres de créer un nombre illimité de cellules de navigation
pour fournir un accès au modèle adapté au public, évitant ainsi à l'utilisateur d'avoir besoin de savoir ou de comprendre
comment parcourir le modèle.

Ceux-ci sont particulièrement utiles lors de la visualisation des modèles via un Web Navigateur .

Définir le contexte (limites et cas d'utilisation)

Le contexte d’un système est essentiel pour que toutes les parties prenantes puissent comprendre le système dans son
environnement. Le diagramme de cas d'utilisation est l'un des diagrammes les plus simples mais les plus descriptifs de la
boîte à outils SysML. Sa puissance réside dans le fait qu'il relie les entités qui résident en dehors du système (acteurs)
aux avantages qu'elles attendent du système (cas d'utilisation) sans expliquer comment le système fournira la valeur . Les
cas d'utilisation peuvent être rédigés à un niveau descriptif, mais si plus de détails sont nécessaires, le générateur de
scénarios d' Enterprise Architect peut être utilisé pour spécifier les étapes de chaque scénario, dans un outil qui simplifie
la documentation des cas d'utilisation. diagrammes de comportement tels que diagrammes d'activité et des documents de
cas d'utilisation peuvent également être générés automatiquement à partir de l'outil.

Modèle de domaine opérationnel - Définition du contexte

Ce diagramme Bloc interne décrit une utilisation définie par l'utilisateur du type diagramme , qui représente le système
dans le contexte de son environnement. Les stéréotypes « système » et « externe » sont définis par l'utilisateur et non
spécifiés dans SysML, mais aident l'ingénieur système à décrire le système qui l'intéresse par rapport à son
environnement.

Enterprise Architect permet également de remplacer les symboles conventionnels du SysML par des images plus
attrayantes et significatives qui facilitent l'acceptation du diagramme par un public non technique.

Ce changement d'apparence des éléments peut être appliqué à un niveau global (par défaut) ou à un niveau spécifique
diagramme , permettant de créer des présentations alternatives pour différents publics.

Diagramme de cas d'utilisation – Cas d'utilisation de

niveau supérieur
Le diagramme de cas d'utilisation décrit l'HybridSUV comme un système utilisé par un certain nombre de rôles externes.
Le diagramme aide à définir le contexte de tous les rôles (systèmes humains et autres) qui interagissent avec le système
ou en tirent de la valeur . Le diagramme de cas d'utilisation, bien qu'apparaissant simpliste, fournit un mécanisme
permettant de garantir que toutes les interactions potentielles du système sont définies et comprises. Le système
lui-même est représenté dans le diagramme par un élément Bordure , qui fait office de conteneur pour les cas
d'utilisation, les acteurs se trouvant en dehors de la Bordure . Dans ce diagramme il existe un certain nombre de rôles
externes - autres que le conducteur - qui interagiront avec le système HybridSUV, notamment le propriétaire enregistré,
l'entretien, la compagnie d'assurance et le département des véhicules automobiles.

Les cas d'utilisation apparaissent dans la fenêtre Navigateur et peuvent être facilement regroupés en acteurs et cas
d'utilisation. N'importe quel nombre de diagrammes de cas d'utilisation peut ensuite être défini pour permettre à
l'ingénieur système de visualiser les cas d'utilisation.

Enterprise Architect fournit également un certain nombre d'outils utiles et uniques pour aider l'ingénieur système à
décrire efficacement les cas d'utilisation et à définir des scénarios qui détaillent les étapes représentant l'interaction entre
l'acteur et le système. Une fois ceux-ci définis, l'outil peut générer automatiquement diagrammes comportementaux
directement à partir du modèle.

Une fois les étapes générées comme éléments de modèle alors la traçabilité peut être ajoutée :
· Les étapes des acteurs peuvent être attribuées aux modèles d'interface homme-machine
· Les étapes du système peuvent être attribuées aux modèles de composants.

Diagramme de cas d'utilisation - Cas d'utilisation

opérationnels
Les cas d'utilisation au niveau des objectifs associés à « Exploiter le véhicule » sont décrits dans le diagramme suivant.
Ces cas d'utilisation aident à étoffer les types spécifiques d'objectifs associés à la conduite et au stationnement du
véhicule. Le diagramme se concentre sur le conducteur du véhicule en tant qu'acteur central. Les cas d'utilisation de
niveau supérieur, tels que l'entretien, l'immatriculation et l'assurance du véhicule, sont définis dans un ensemble distinct
de cas d'utilisation contextuels.

En plus des fonctionnalités étendues décrites dans la section précédente pour articuler les scénarios et leurs étapes
détaillées, il existe un certain nombre d'autres fonctionnalités fournies par l'outil qui aident l'ingénieur système lorsqu'il
travaille avec des cas d'utilisation. L'une des fonctionnalités les plus utiles est la fenêtre de traçabilité, qui fournit une
visualisation convaincante de ce à quoi un cas d'utilisation donné est connecté et, par conséquent, de ce à quoi l'élément
connecté est lié. Au fur et à mesure que différents cas d'utilisation (ou tout autre élément) sont sélectionnés dans la
fenêtre Navigateur ou dans un diagramme , la fenêtre s'actualise pour afficher les connexions de l'élément sélectionné.

Élaboration du comportement ( Diagrammes Séquence et

Statemachine )
Ces sujets et sections montrent comment le comportement peut être représenté et élaboré à l'aide diagrammes Séquence
et Statemachine .

Diagramme de Séquence - Drive Black Box

Le diagramme Séquence est un type de diagramme d'interaction et décrit la manière dont le conducteur interagit avec le
véhicule dans un contexte particulier. Les éléments qui participent sont, par convention, répertoriés de gauche à droite
sur l'accès horizontal du diagramme , et le temps s'écoule verticalement dans le diagramme . Les lignes pointillées qui
émanent des objets sont appelées lignes de vie et représentent la durée d’existence des éléments.

Ce diagramme utilise un type d'élément appelé Référence, qui agit comme un espace réservé pour un autre Diagramme
de Séquence . Enterprise Architect permet facilement d'ouvrir ces diagrammes en double-cliquant sur l'élément « ref »
dans le diagramme .

Le diagramme utilise un fragment combiné parallèle (par) pour spécifier que les interactions de contrôle de vitesse et de
direction se produisent en même temps (en parallèle). Le diagramme utilise également un fragment combiné avec la
désignation Alternative (alt) qui spécifie un certain nombre de façons (alternatives) par lesquelles le conducteur peut
contrôler la vitesse.

Enterprise Architect permet au Diagramme de Séquence d'être défini comme un enfant du cas d'utilisation « Conduire le
véhicule », ce qui permet à un modélisateur d'accéder facilement au diagramme et de le visualiser dans le contexte de
l'objectif que le conducteur souhaite atteindre par rapport à le véhicule.

Diagramme Statemachine - States opérationnels HSUV

Ce diagramme Statemachine est utilisé pour décrire les états discrets que présente le SUV hybride pendant une partie
spécifiée de sa durée de vie. Un système ou une partie de système peut avoir un large éventail d'états en fonction du point
de vue de l'observateur. Un modélisateur doit donc toujours spécifier la perspective ou la vue utilisée pour le diagramme
. Le diagramme articule ensuite les conditions importantes et pertinentes au cours de la durée de vie spécifiée de l'entité.

Le message du diagramme Séquence Démarrer le véhicule est le déclencheur qui fera passer le véhicule de l'état Off à
l'état Operate (on). Enterprise Architect permet de définir ces transitions en détail.

Les States apparaissent dans la fenêtre Navigateur et sont regroupés de manière pratique sous le nœud Statemachine .

Diagramme de Séquence - Démarrer le véhicule Black Box

et White Box
Ce diagramme Séquence décrit l'interaction du conducteur démarrant le véhicule. Il utilise l'élément Interaction Use
indiqué par le (ref) pour faire référence à un autre diagramme Séquence . Le diagramme est intrinsèquement simple, mais
diagramme peut être complété par un certain nombre d'autres éléments et connecteurs qui élaborent les détails d'autres
interactions plus complexes.

Enterprise Architect fournit un mécanisme pratique permettant au modélisateur de cliquer sur le diagramme référencé,
dans ce cas le diagramme Démarrer Vehicle White Box .

Les éléments d' Enterprise Architect peuvent apparaître dans plusieurs diagrammes , permettant de construire des récits
expressifs dans un modèle et fournissant un mécanisme permettant aux modélisateurs de créer plusieurs vues du même
élément. Les éléments d'un diagramme peuvent être localisés dans la fenêtre Navigateur montrant leur relation
structurelle avec d'autres parties du modèle. Dans ce cas, les vues White Box de l'interaction Démarrer le véhicule sont
situées en tant qu'enfants du cas d'utilisation Démarrer le véhicule, ce qui facilite leur relation.

Etablir Exigences ( Diagrammes et Tableaux Exigences )

Le but de cette partie du modèle est de démontrer la modélisation visuelle des exigences. La spécification du système du
véhicule contient de nombreuses exigences basées sur du texte qui ont été recréées dans Enterprise Architect . Une série
d'exigences ont été modélisées, y compris l'exigence selon laquelle le véhicule doit satisfaire aux normes d'émissions, qui
est élargie à des fins d'illustration.
Enterprise Architect fournit une large gamme d'outils pour créer, développer, analyser, gérer et tester les exigences. Il
dispose également d'intégrations à l'outil de gestion des exigences DOORS .

Diagramme des exigences - Hiérarchie des exigences HSUV

Ce diagramme illustre la visualisation des exigences dans une hiérarchie à l'aide du connecteur de confinement (hachures
croisées) pour afficher la relation parent-enfant. Les exigences de niveau supérieur agissent comme une sorte de système
de regroupement ou de confinement et couvrent une gamme de préoccupations de haut niveau qui sont décomposées en
énoncés de niveau inférieur et vraisemblablement mesurables.

Diagramme d'exigences - Exigences dérivées

Ce diagrammes d'exigences montre qu'un certain nombre d'exigences ont été dérivées d'autres exigences. Cette relation
implique qu'une certaine analyse a été effectuée et que l'exigence dérivée représente un besoin qui peut répondre à
l'intention de l'exigence initiale. Par exemple, le freinage régénératif n'était pas une exigence, mais il découle de la
nécessité d'avoir à la fois un freinage et une économie de carburant, comme exprimé dans les exigences à l'extrémité de
la flèche de la relation.

Diagramme d'exigence - Relations d'exigence

d'accélération
Ce diagramme démontre un certain nombre de relations d'exigences qui apparaîtraient généralement sur un diagramme
d'exigences après qu'une analyse et modélisation aient été effectuées. L'élément central est l'exigence d'accélération et le
diagramme montre comment un certain nombre d'autres éléments sont liés à cette exigence. La relation d'affinement est
introduite comme un moyen de relier un cas d'utilisation portant un nom similaire à l'exigence d'accélération. Nous avons
une autre exigence dérivée qui est ensuite satisfaite par un Bloc . Un scénario Test « Accélération maximale » est
également présenté sur le diagramme et lié à l'exigence centrale par une relation de vérification. Le diagramme démontre
également que des éléments autres que les exigences peuvent être ajoutés et contribuer à rendre le diagramme plus
expressif.

Tableau - Exigences Tableau

Ces exemples démontrent la manière dont Exigences peuvent être affichées sous forme de tableau comme alternative à la
représentation graphique dans diagrammes . Il s'agit d'un style de présentation bienvenu pour un large éventail de parties
prenantes plus habituées à travailler avec des feuilles de calcul. Le premier tableau répertorie les exigences avec leurs
identifiants et leurs déclarations textuelles. Le deuxième tableau répertorie les exigences source et cible qui participent à
la relation de déduction.
Enterprise Architect fournit également une gamme d'outils et de moyens de visualiser les exigences (et d'autres
éléments), notamment Vues de liste, des tableaux Kanban, Vues Spécification , des diagrammes de Gantt, des graphiques
et bien plus encore.

Décomposer les morceaux ( Diagrammes de définition

Bloc , Diagrammes Bloc internes)
Les blocs sont les unités fondamentales de la structure et peuvent être utilisés à la fois dans la définition Bloc et
Diagrammes Bloc internes pour décrire les aspects structurels d'un système. Le diagramme de définition Bloc est souvent
un point de départ pour de nombreux ingénieurs souhaitant acquérir des connaissances sur un système et voir comment il
est structuré. Le Bloc lui-même est constitué de structure et celle-ci est représentée par Fonctionnalités , cela comprend
des Pièces qui sont elles-mêmes typées par d'autres blocs par exemple un assemblage de roue pourrait avoir une Partie
d'étrier à disque. Il existe également des propriétés de valeur, qui sont des éléments qui ont une quantité et qui
représentent des dimensions physiques et autres dimensions mesurables. Par exemple, une voiture peut avoir un poids et
une couleur et avoir un temps d'accélération de 0 à 100 km de 5 secondes. Il existe également des points d'interaction qui
montrent les points sur lesquels un bloc peut interagir avec son environnement.

Interrompre lorsqu'une Variable Change de Valeur -

Domaine Automobile
Ce diagramme montre l'utilisation d'un diagramme de définition Bloc pour décrire les pièces qui composent le domaine
automobile. Le domaine comprend des personnes qui, tout en jouant un rôle, interagiront avec le système, notamment un
conducteur, un passager et un mécanicien. Il pourrait donc y avoir un certain nombre de personnes spécifiques jouant le
rôle de conducteur et de mécanicien lors de l'exécution d'un test après la réparation du sous-système de freinage. déplacer
leur rôle de mécanicien à celui de conducteur.

Interrompre lorsqu'une Variable Change de Valeur -

Hybrid SUV
Tous les systèmes qui nécessitent une analyse et une conception techniques seront d'un niveau de complexité qui
nécessitera que le système soit décomposé en un certain nombre de parties pour aider à réduire la complexité et faciliter
la gestion du projet. Le premier niveau de panne est le plus souvent appelé sous-système et dans le cas du SUV hybride
ou de toute autre automobile, les sous-systèmes comprendraient des blocs tels que l'alimentation, les freins, l'éclairage et
le châssis.
Ces sous-systèmes seraient eux-mêmes décomposés en un certain nombre de parties constitutives. Par exemple, le
sous-système de freinage pourrait être décomposé en ensembles de disques et en parties hydrauliques.

Diagramme Interne de Bloc - SUV Hybride

Le diagramme Bloc interne fournit un mécanisme pour décrire comment les parties sont liées ou connectées les unes aux
autres dans le contexte du bloc entier ou propriétaire. Dans notre exemple du SUV hybride, nous pouvons voir une
connexion entre le sous-système de puissance et le sous-système de freinage, probablement pour modéliser le freinage
assisté. Ainsi, tandis que le diagramme de définition Bloc montre la structure en termes de composition, le Bloc interne
est capable de regarder à l'intérieur du bloc et de voir comment il est « câblé » ensemble.

Nous verrons dans une section ultérieure comment une forme spécialisée du diagramme Bloc Interne, à savoir le
diagramme Paramétriques , est utilisée pour modéliser des systèmes d'équations mathématiques.

Interrompre lorsqu'une Variable Change de Valeur -

Power Subsystem
Dans les deux sections précédentes, nous avons vu comment un système peut être décomposé en un certain nombre de
sous-systèmes et que cette décomposition peut être représentée sur un diagramme de définition Bloc . Nous avons
également vu comment les sous-systèmes peuvent être liés à chacun dans le contexte du système global et comment
ceux-ci peuvent être représentés sur un diagramme Bloc interne. Nous allons maintenant voir comment l'un de ces
sous-systèmes (le sous-système de puissance) peut être décomposé en un certain nombre de parties constitutives à l'aide
du diagramme de définition Bloc .

Diagramme Interne de Bloc pour le sous-système de

puissance
De la même manière que nous avons montré les connexions entre les sous-systèmes, en utilisant un diagramme Bloc
interne, nous pouvons faire la même chose pour représenter la manière dont les parties d'un sous-système sont
connectées entre elles. Nous voyons donc à nouveau comment les deux types diagramme , diagramme de définition Bloc
et le diagramme Bloc interne, peuvent être utilisés en tandem pour décrire la structure d'un système et comment nous
pouvons descendre dans la hiérarchie des parties jusqu'à un point où la complexité est comprise et comprise. ne nécessite
pas modélisation supplémentaire.

Définir les ports et les flux

Les diagrammes dans les sujets de cette section montrent comment les éléments qui circulent peuvent être modélisés, à
l'aide des diagrammes Ports, Flux et Spécification de flux sur la définition Bloc , Bloc interne et les paramètres
Paramétriques . La plupart des systèmes physiques comportent des éléments qui circulent, ce qui peut jouer un rôle
important dans le fonctionnement du système. Nous pourrions considérer un certain nombre d’exemples, notamment :
· Une usine de dessalement - où le sel, l'eau douce et l'électricité circulent dans le système
· Une ligne de production où les instructions d'assemblage, de pièces, d'alimentation et de contrôle du robot circulent
à travers le système
· Un système de transport urbain où circulent les trains, les tramways, les bus, les ferries et les passagers.
· Un avion dans lequel le carburant, l'air, les signaux de commande, le fluide hydraulique, les passagers et les agents
de bord circulent à travers le système.
Les diagrammes commencent par définir une architecture de bus CAN (Controller Area Network) et montrent comment
un certain nombre de spécifications de flux peuvent être utilisées pour définir la manière dont les éléments circulent entre
les parties du sous-système d'alimentation. Le flux de carburant est modélisé à l'aide d'un diagramme de définition Bloc
qui présente des ports de flux (obsolètes dans la version SysML 1.5) qui montrent le « conduit » logique permettant au
carburant de s'écouler depuis l'assemblage combustible et le moteur à combustion interne. diagrammes Bloc internes
vont plus loin et enfin un diagramme Paramétriques est utilisé pour montrer comment une équation mathématique pour le
débit de carburant, définie dans une contrainte, peut être utilisée pour modéliser l'équation. Les tracés simulés sont
ensuite visualisés à l'aide des capacités de simulation d' Enterprise Architect .

Interrompre lorsqu'une Variable Change de Valeur - ICE

Flow Propriétés
Ce diagramme montre les premières étapes (inachevées) de la définition et du raffinement d'une architecture de bus. Le
modélisateur a utilisé des spécifications de flux pour modéliser la manière dont les éléments circuleront à travers le
véhicule ; par exemple, une spécification de flux a été définie pour :
· Le moteur à combustion interne FS_ICE
· Le système de transmission
· Le contrôleur de puissance électronique

Le diagramme sera affiné au cours des itérations ultérieures du processus, et les ports et flux seront utilisés pour
modéliser les éléments qui circulent à travers et entre les différents sous-systèmes.

Diagramme Interne de Bloc - CAN Bus

Ce diagramme poursuit le perfectionnement de l'architecture du bus, en utilisant un diagramme Bloc interne pour
montrer comment les différents systèmes sont intégrés dans le bus CAN (Controller Area Network). Cette architecture de
bus CAN est un dispositif central pour contrôler et intégrer diverses parties des sous-systèmes du SUV hybride.

Interrompre lorsqu'une Variable Change de Valeur - Fuel

Flow Propriétés
Ce diagramme de définition Bloc continue modélisation la manière dont le carburant s'écoule de l'ensemble réservoir de
carburant au moteur à combustion interne, en élaborant la définition du débit de carburant. Le carburant lui-même est
modélisé sous forme de Bloc et possède deux propriétés valeur qui définissent les caractéristiques physiques importantes,
à savoir :
· Température du carburant
· Pression de carburant
Le Bloc du sous-système de puissance est divisé en deux de ses parties importantes, à savoir l'ensemble réservoir de
carburant et le moteur à combustion interne. Les deux parties ont des ports d'écoulement définis et un connecteur a été
dessiné entre les deux ports indiquant que l'élément « Carburant » peut s'écouler du réservoir de carburant vers le moteur.

Diagramme Paramétriques - Débit De Carburant

Ce diagramme Paramétriques montre comment des équations mathématiques peuvent être modélisées à l'aide de
ConstraintProperties et de paramètres liés au périmètre de ConstraintProperty. Dans ce diagramme nous voyons que le
débit est lié à la fois à la demande en carburant et à la pression du carburant, en utilisant l'équation :
{débit=presse/(4*injecteurDemand)}
La contrainte est modélisée dans le Constraint Bloc et peut être utilisée dans de nombreux contextes différents, à l'aide de
ConstraintProperties sur diagrammes Paramétriques . Enterprise Architect dispose d'une simulation avancée facilité qui
utilise OpenModelica ou Simulink pour créer des tracés d'équations modélisées.

Analyser les performances ( Diagrammes de contraintes,

Diagrammes , Vues )
Les diagrammes de cette section de l'exemple sont en grande partie diagrammes Paquetage qui décrivent les points de
vue et Vues utilisés pour répondre aux préoccupations des parties prenantes. Les sujets présentent également des mesures
d'efficacité (MOE) qui peuvent être utilisées dans les études commerciales pour évaluer les solutions et architectures
candidates. Les concepts de Viewpoint et Vue sont articulés dans la norme ISO-42010 (anciennement IEEE-1471) et les
constructions SysML Viewpoint et Vue sont cohérentes avec cette norme. Des exemples typiques de Vues incluent les
opérations, la fabrication ou la sécurité, et celles-ci sont ensuite liées aux éléments du modèle.
Il est préférable de considérer les modèles Viewpoint et Vue comme un modèle narratif ou de description, qui aide à
clarifier et à expliquer un modèle de système. Un modèle Viewpoint et Vue expose des éléments d'un ou plusieurs
modèles de système. Plus précisément, un point de vue est un cadre particulier à partir duquel visualiser les modèles de
système et constitue une spécification de règles permettant de construire une Vue pour répondre à un ensemble de
préoccupations importantes pour les parties prenantes. Par exemple, un architecte de performance aura des
préoccupations différentes de celles d'un architecte de sécurité. La Vue est destinée à visualiser le système à partir du
point de vue spécifié. Cela fournit un mécanisme permettant aux parties prenantes de spécifier les aspects du modèle de
système qui sont importants pour elles de leur point de vue, puis de représenter ces aspects du système dans une Vue
spécifique.
Le point de vue décrit le point de vue ou l'objectif à travers lequel un groupe de parties prenantes examine un modèle de
système et, en encadrant les préoccupations des parties prenantes ainsi que la méthode de production d'une Vue , leurs
préoccupations peuvent être prises en compte. La méthode décrit :
· L'attente de ce que les parties prenantes souhaitent voir exposé à partir du modèle
· Comment la partie prenante souhaite que les informations soient structurées et présentées
· Dans quel type d'artefact la partie prenante souhaite consommer l'information.
En d’autres termes, le processus est l’ensemble de règles qui décrivent comment Vue doit exprimer les informations du
modèle pour répondre aux préoccupations des parties prenantes. Lorsque les Vues et les points de vue sont modélisés
dans Enterprise Architect la relation avec les éléments modélisation peut être définie.

Interrompre lorsqu'une Variable Change de Valeur -

Contexte d'analyse
L’une des principales raisons de modélisation un système est de pouvoir effectuer une analyse sur les modèles, ce qui
constitue un moyen rentable d’avoir un aperçu de la façon dont le système construit fonctionnera in situ. Effectuer une
analyse sur un modèle est moins cher et plus pratique que de construire des prototypes. Ce diagramme de définition Bloc
définit les différents éléments du modèle qui seront utilisés pour effectuer l'analyse dans cet exemple. Il décrit chacun des
ConstraintBlocks et des équations associées qui seront utilisées pour l'analyse, ainsi que les relations clés entre eux. Il
existe deux types d'éléments présents sur le diagramme : les blocs et les contraintes. Le diagramme montre également la
relation Vérifier entre une exigence et un scénario Test .

Diagramme Paquetage - Définition Vue de performance

Le SysML permet à une équipe de définir ses propres points de vue ; dans cet exemple, nous voyons un point de vue
Performance défini par l'utilisateur et les éléments qui peuplent le Performance Vue spécifique à HSUV. La Performance
Vue elle-même peut contenir un certain nombre de diagrammes illustrant les éléments qu'elle contient. Nous pouvons
voir dans le diagramme qu'un certain nombre de vues ont été définies, notamment la vue Hybrid SUV Performance et
SUV Functional Vue . Chaque vue a une partie prenante définie et un point Vue . La relation d'exposition a été utilisée
pour relier Performance Vue au modèle SUV et la relation de conformité montre que Performance Vue est conforme au
Performance Viewpoint.

Diagramme Paquetage - Définition du point de vue

Ce diagramme Paquetage montre les définitions des points de vue Exigences et Verification et Validation (VnV) avec les
relations avec les parties prenantes, les préoccupations et les points de vue. La partie prenante et le point de vue partagent
la même préoccupation via des commentaires qui sont affichés textuellement comme valeurs de la propriété concernée.
Les commentaires pourraient être affichés graphiquement avec des relations d'annotation avec les parties prenantes et les
points de vue, si nécessaire. Note que la valeur de la propriété de la partie prenante est une instance du stéréotype et non
la classe à laquelle le stéréotype est appliqué.

Diagramme Paquetage - Définition Vue

Ce diagramme montre l'utilisation de la relation Expose, qui est un dispositif graphique permettant d'indiquer les
éléments (y compris Paquetages ) qui font partie de la vue. Les Exigences et les Vues Verification et Validation ont des
relations Expose sortantes qui ciblent un certain nombre d'éléments du modèle. Cela constitue un moyen utile d'indiquer
les éléments impliqués dans la vue ; par exemple, on peut voir sur le diagramme que la vue Exigences SUV hybrides
expose le cas d'utilisation du véhicule de conduite, une exigence de performance et un Paquetage contenant un groupe de
contraintes SUV.
En utilisant certains des outils de visualisation riches fonctionnalité , il serait également possible de visualiser à quelles
Vues un élément donné a participé, par exemple le cas d'utilisation du véhicule de conduite pourrait apparaître dans un
certain nombre de Vues différentes.

Diagramme Paquetage - Hiérarchie Vue

Ce diagramme Paquetage montre comment les vues, ou d'ailleurs tout autre élément ayant le même stéréotype, peuvent
être rassemblées dans un Paquetage et présentées visuellement.

Diagramme Paramétriques - Mesures d'Efficacité

La mesure de l'efficacité est un mécanisme permettant d'évaluer une solution en mettant en place un ensemble de
mesures qui permettront à l'équipe d'ingénierie d'évaluer deux ou plusieurs solutions à un problème. Cette technique est
généralement appelée étude commerciale et les mesures d'efficacité (MOE) sont calculées pour deux solutions ou plus et
comparées à l'aide d'une fonction d'utilité (objectif). Le MOE est un stéréotype défini par l'utilisateur et ne fait pas
officiellement partie du langage de base SysML ; il s'appuie sur le mécanisme d'extension des stéréotypes qui permet
d'étendre la grammaire du langage. Ce diagramme Paramétriques montre comment la rentabilité globale du HSUV sera
évaluée. Il montre les MOE particulières pour une alternative pour la conception HSUV et peut être réutilisé pour évaluer
d'autres alternatives.

Diagramme Paramétriques - Economie

Ce diagramme Paramétriques est utilisé pour modéliser l'économie de carburant car elle a été définie comme une
exigence de haut niveau importante pour le SUV et doit donc être évaluée pour garantir que le produit final fonctionnera
correctement. Le diagramme Paramétriques contient des propriétés de contraintes (instances des blocs de contraintes). Il
existe un certain nombre d'équations qui contribuent à l'évaluation de l'économie globale, notamment : l'équation de
traînée aérodynamique, l'équation d'efficacité de freinage régénérative, la dynamique du véhicule en ligne droite,
l'équation de friction de roulement et l'équation d'efficacité énergétique. Les propriétés de contrainte contiennent des
paramètres montés bordure qui sont connectés à d'autres paramètres par des connecteurs de liaison.

Diagramme Paramétriques - Dynamique

Dans ce diagramme Paramétriques , le Bloc de contraintes - Dynamique des véhicules en ligne droite - de l'exemple
précédent a été développé pour montrer comment il peut être modélisé avec un certain nombre de propriétés de
contraintes. La contrainte de dynamique de véhicule en ligne droite est représentée par le cadre diagramme et les
équations constitutives qui contribuent à l'équation globale sont modélisées dans le diagramme en tant que propriétés de
contrainte. Chaque contrainte sur laquelle sont basées les propriétés de contrainte a une équation de contrainte définie,
qui est affichée entre accolades {} sur le diagramme ; par exemple, l'équation d'accélération est définie dans le Bloc de
contraintes comme {a = (550/32)*tp(hp)*dt*tw}. Les connecteurs de liaison sont utilisés pour relier les paramètres
(variables) d’une équation aux paramètres (variables) d’une autre équation.

Diagramme de synchronisation (non normatif) -

Accélération de 100 ch
Enterprise Architect a la capacité de générer des tracés de diagrammes Paramétriques à l'aide de son intégration
OpenModelica ou Simulink. L'un des grands avantages de modélisation des systèmes physiques est de pouvoir analyser
la façon dont un système se comporterait dans un contexte réel, sans avoir besoin de construire des prototypes coûteux
ou d'effectuer le test sur le système construit lui-même. La capacité de modéliser des équations mathématiques qui
régissent le fonctionnement d'un système et de créer des modèles de celles-ci sous forme de contraintes à l'aide
diagrammes Bloc Definition et Paramétriques constitue les précurseurs de la simulation de modèles.
Enterprise Architect exploite la puissance d'un outil ouvert appelé OpenModelica, qui s'appuie sur le langage Modelica
pour générer des tracés et des représentations graphiques d'équations en mouvement.

Définir, décomposer et répartir les activités

Les exemples des sujets de cette section utilisent diagrammes d'activité qui décrivent les aspects comportementaux du
SUV hybride, en utilisant des actions chargées de définir le travail, qui est finalement effectué par des instances de blocs.
Il existe également un certain nombre de diagrammes Bloc internes qui démontrent la manière dont les allocations
peuvent être représentées.

Diagramme d'activité - Accélération (niveau supérieur)

Ce diagramme d'activité montre le comportement de niveau supérieur d'une activité représentant l'accélération du HSUV.
L'intention de l'ingénieur système dans cet exemple est d'attribuer ce comportement à des parties du sous-système
d'alimentation. Cependant, on constate rapidement que le comportement tel que décrit ne peut pas être alloué et doit être
davantage décomposé. Les stéréotypes sur les nœuds object entre les actions dans la figure s'appliquent aux paramètres
des comportements ou opérations appelés par les actions.

Interrompre lorsqu'une Variable Change de Valeur -

Accélération
Ce diagramme de définition Bloc montre la décomposition de l'activité Fournir de l'énergie à partir du diagramme de la
rubrique précédente. Il est important de note qu'il s'agit d'une décomposition fonctionnelle et, en tant que telle, elle
définit les relations structurelles entre les activités dans la hiérarchie et doit donc être modélisée sur un diagramme de
définition Bloc .

Diagramme d'Activité (EFFBD) - Accélération (détail)

Ce diagramme d'activité a l'activité Provide Power comme cadre diagramme , qui comprend des actions appelant les
activités décomposées et les nœuds Object du diagramme précédent. Il utilise également Allouer des partitions d'activité,
qui sont orientées verticalement dans le diagramme . Ces partitions comprennent l'unité de contrôle de puissance, le
moteur à combustion interne, le contrôleur de puissance électrique et le générateur de puissance électrique, qui sont
utilisés pour montrer quelle partie du système est responsable des actions définies dans le diagramme . Il existe
également une légende d'allocation pour allouer explicitement des activités et un flux object aux parties du Bloc du
sous-système de puissance.
L'ingénieur modélisation a utilisé des flux object entrants et sortants pour l'activité ProvidePower. Cela a été fait pour
distinguer le flux de puissance mécanique générée électriquement et de puissance mécanique générée par gaz, et pour
fournir davantage d'informations sur les conditions spécifiques du véhicule surveillées.

Diagramme Interne de Bloc - Power Subsystem

Comportementale and Flow Allocation
Ce diagramme Bloc interne partiellement complété développe certaines des relations d'allocation présentées dans
l'exemple précédent. Ici, nous voyons comment les blocs qui ont été ajoutés au diagramme en tant que propriétés
communiquent entre eux, et nous pouvons voir le flux d'éléments d'une instance d'un Bloc à une autre. Plus précisément,
le contrôleur de puissance électrique est connecté au moteur-générateur électrique et nous pouvons voir que le courant
électrique circule entre les deux propriétés.

Diagramme Interne de Bloc : Property Specific Values -

EPA Fuel Economy Test
Ce diagramme Bloc internes montre la manière dont les cas Test peuvent être modélisés dans le contexte de la
représentation de sous-systèmes. Les tests ont été effectués pour un exemplaire spécifique du SUV hybride qui est
vraisemblablement sorti de la chaîne de production et possède un VIN (numéro d'identification du véhicule) spécifique.
Le test qui a été effectué est le test d'économie de carburant de l'EPA. Les numéros de série de pièces pertinentes
spécifiques peuvent également être indiqués pour identifier tout problème que les instances des pièces pourraient
rencontrer.

Apprendre à connaître les Diagrammes SysML

Les diagrammes du SysML peuvent être considérés comme des types de canevas, dans lesquels un ingénieur créera des
représentations visuelles des concepts d'ingénierie qui font partie du modèle. Il existe neuf types diagramme SysML,
chacun axé sur un aspect particulier du problème ou de la solution. Bien que les types diagramme contiennent
généralement différents types d'éléments, ils sont tous conformes à une représentation standard composée de : un cadre
qui contient, un en-tête et une zone de contenu.

Cette section décrit certains des outils et fonctionnalités les plus utiles pouvant être utilisés lorsque vous travaillez avec
diagrammes , mais il en existe bien d'autres qui peuvent être utiles. Pour plus d'informations, voir les Model Diagrams
Rubrique d'aide.

Cadres Diagramme

Un Diagramme Frame est un dispositif visuel qui renferme les éléments et les relations sur un diagramme . Le cadre
comporte deux parties :
· Une zone d'en-tête qui contient un nom qualifié pour l'élément de modèle dans le cadre, qui est fourni s'il n'est pas
contenu dans l'espace de noms par défaut associé au cadre ; il a la forme :
diagrammeKind [modelElementType] modelElementName [diagramName]
· Une zone de contenu qui contient les éléments visuels qui composent le diagramme

Enterprise Architect affiche par défaut les cadres dans une fenêtre diagramme , mais conformément à la spécification
SysML, le cadre peut être supprimé pour créer une interface de création de diagrammes moins encombrée. (En rappelant
qu'Enterprise Enterprise Architect affiche facilement les informations d'en-tête du cadre dans l'en-tête diagramme ).

Un cadre peut être réactivé chaque fois que nécessaire, et diagrammes envoyés au presse-papiers ou à l'imprimante
peuvent être configurés pour afficher les cadres, qu'ils aient ou non été masqués dans l'interface utilisateur.

S'il est défini sur non sélectionnable, le cadre se redimensionnera automatiquement pour s'adapter aux limites du
diagramme , s'agrandissant à partir de sa taille par défaut mais sans se réduire. Ils peuvent cependant être sélectionnés et
ajustés en fonction des préférences du modéliste.

Note que diagrammes montrant des cadres Diagramme appliqués à l'aide de la version 14.0 ou ultérieure d' Enterprise
Architect dessineront l' object parent sur le diagramme lorsqu'ils seront ouverts à l'aide d'une version d' Enterprise
Architect antérieure à la version 14.0.

Descriptions Diagramme ( Notes )

En plus des méta-informations contenues dans l'en-tête, un diagramme peut avoir une description utile aux nouveaux
arrivants pour comprendre le but et l'intention du diagramme . La description peut être ajoutée, visualisée et conservée
dans la fenêtre notes du diagramme ,

Un diagramme est souvent créé pour décrire les aspects d'un modèle ou d'un système. Bien que le diagramme lui-même
et les éléments et connecteurs qu'il contient racontent une histoire, il est souvent nécessaire de l' diagramme avec des
informations supplémentaires sous la forme d'un texte descriptif. Ce texte pourrait par exemple :

· Décrire le but du diagramme ,

· Mettez en évidence comment interpréter le diagramme ,
· Contenir un lien vers d'autres informations dans le modèle,
· Fournissez une explication des symboles utilisés.
Les notes seront générées dans la documentation et sont visibles via l'interface WebEA .

Propriétés du Diagramme

Chaque diagramme possède une série de propriétés qui décrivent le diagramme à un niveau méta, y compris des éléments
tels que :

· Date de création du diagramme ,

· Date de modification du diagramme ,
· Auteur Modèle qui a créé le diagramme ,
· Mode Dessiné à la main et Tableau blanc
· Thème visuel, et bien d'autres.

De plus, il existe un onglet dédié à spécifier quels compartiments sont visibles dans le diagramme et un autre onglet
utilisé pour spécifier les matrices et les couloirs.

Changement de thèmes et d'apparence

Enterprise Architect fournit une facilité qui vous permet d'appliquer un thème sélectionné à tous diagrammes présentés
sur votre appareil. Vous pouvez l'utiliser pour créer un style particulier de diagramme et cela peut affecter la couleur, la
police, le dégradé, l'épaisseur de ligne et l'image d'arrière-plan (tuile). C'est un mécanisme utile pour donner plus d'attrait
à votre diagramme ou pour unifier son apparence.

Les couleurs et les styles peuvent également être définis pour chaque élément diagramme individuellement, soit par
défaut (chaque diagramme dans lequel l'élément apparaît) ou uniquement pour l'élément du diagramme actuel.

Visualisations alternatives des Diagrammes

Tout en étant conforme à la spécification SysML et en fournissant toutes les fonctionnalités diagramme attendues dans un
outil modélisation , Enterprise Architect propose aux modélisateurs un certain nombre de façons de visualiser le
diagramme différemment, apportant des visualisations riches du diagramme et de ses éléments. Ceux-ci inclus:
· Spécification Vue - présente les éléments dans un format familier de traitement de texte ou de feuille de calcul,
permettant la mise à jour des éléments et du texte
· List Vue - présente les éléments d'une liste qui peuvent être triés et regroupés, et les champs mis à jour
· Inline Spécification Vue - présente le diagramme avec une vue narrative similaire à Spécification Vue
· Gantt Vue - présente les éléments dans une vue Gantt montrant l'allocation des ressources et d'autres informations
temporelles

De plus, le diagramme peut être visualisé selon deux modes qui modifient l'apparence des diagrammes adaptés aux
présentations, ajoutant ainsi un grand attrait et atténuant l'accent mis sur la rigueur du langage modélisation sous-jacent.

Créer un attrait avec des images alternatives

Les diagrammes créés dans le cadre d'un modèle sont destinés à communiquer des idées à un public et l'intention du
diagramme est souvent mieux transmise à un public non technique ou commercial par l'utilisation d'une image.
Enterprise Architect fournit un mécanisme pour remplacer la notation graphique classique (et parfois) peu attrayante du
Langage Modélisation des Systèmes par une image dans une variété de formats, y compris des images vectorielles.

L'image peut être appliquée à chaque instance de l'image dans diagramme ou simplement pour un diagramme particulier.
Un ensemble d'images par défaut peut être importé dans Image Manager ou un utilisateur ou une équipe est libre de créer
ses propres images spécifiques à un domaine ou à une industrie particulière.

Filtres de Diagramme

Filtres de Diagramme fournissent un mécanisme permettant de filtrer les parties d'un diagramme ou d'une liste d'éléments
qui ne présentent pas d'intérêt, ne laissant que les éléments et connecteurs pertinents pour la vue. Les filtres peuvent être
définis pour des éléments ou des connecteurs et il existe un large éventail de critères qui peuvent être définis, tels que
filtrer tous les éléments qui n'ont pas le statut « Validé » et qui ont été créés depuis une date jalon. Plus simplement, un
type d’élément ou un stéréotype peut être filtré. Les éléments qui ne répondent pas aux critères peuvent être masqués,
mis en niveaux de gris ou simplement atténués (fondus) afin qu'ils soient visibles mais pas visibles.

Légendes Diagramme

Les légendes Diagramme permettent de décrire les éléments et les connecteurs utilisés dans le diagramme . Les légendes
peuvent modifier dynamiquement les aspects visuels des éléments et des connecteurs dans le diagramme , par exemple
en modifiant la couleur de remplissage, la couleur et la largeur des lignes en fonction des propriétés des éléments ou
Valeur Étiquetés .

N'importe quel nombre de légendes peut être créé et appliqué à un ou plusieurs diagrammes .

Aspects communs des Diagrammes

Diagrammes sont l'un des moyens les plus importants de visualiser le contenu d'un modèle et représentent l'expression
par l'auteur diagramme de ce qu'il considère comme important. Son attrait visuel convaincant et sa capacité à agir comme
un récit racontant une histoire sur certains aspects du système modélisé font du diagramme l'une des vues les plus
importantes. Chaque diagramme du SysML a des aspects (ou fonctionnalités ) communs, notamment :
· un cadre diagramme
· un diagramme
· un diagramme Zone de contenu (Toile)
· un diagramme Description ( Notes )
· une fiche Propriétés d'un diagramme
· Légende d'un diagramme
· Et plus
Il existe également un large éventail d'autres facilités qui aideront l'ingénieur lorsqu'il travaille avec diagrammes ,
notamment :
· Fenêtre de traçabilité
· Fenêtre Relations
· Pan et zoom
· Disposition Diagramme
· Filtres de Diagramme
· Feuilles de Route
· Kanban
· Options de zoom
· Outils d'apparence, d'alignement et de style

Cadre Diagramme

Le Diagramme Frame ressemble à un rideau enfermant les éléments qui font partie du diagramme . Bien que cela soit
plus important lors de la visualisation diagrammes conformément au texte écrit, certains modélisateurs préfèrent que le
diagramme soit visible lors de modélisation .

Le cadre peut être facilement affiché ou masqué pour chaque diagramme , et lorsqu'il est masqué, les informations
diagramme - telles que le type, le parent et le nom du diagramme - sont toujours visibles dans l'en-tête du diagramme .

Les préférences peuvent également être définies pour afficher le cadre Diagramme lorsque diagrammes sont exportés
dans le cadre de la documentation, vers le presse-papiers ou dans des images enregistrées. Ces options se trouvent sur la
page ' Diagramme ' de la dialogue 'Préférences'.

Le cadre contient un en-tête dans le coin supérieur gauche, qui contient des informations utiles sur le diagramme . Cette
syntaxe décrit le contenu de l'en-tête.
diagrammeKind [modelElementType] modelElementName [diagramName]

1. diagrammeKind - est un code pour le type de diagramme , tel que bdd ( Bloc Definition diagramme ),
2. modelElementType - est le type d'élément qui agit comme espace de noms du diagramme ,
3. modelElementName - est le nom de l'élément d'espace de noms,
4. diagrammeName - est le nom du diagramme , fourni par l'utilisateur.

Barre d'en-tête Diagramme

La barre d'en-tête diagramme fournit des informations utiles sur le diagramme et des outils permettant de travailler avec
tous diagrammes ouverts. Même lorsque le cadre n'est pas visible, l'en-tête affichera les détails des diagrammes .

Il comporte également un certain nombre d'autres icônes utiles qui sont utilisées pour contrôler certains aspects de
l'affichage, notamment :
· Boîte à outils Chevron - qui masque ou affiche la boîte à outils pour tous diagrammes affichés,
· Document Chevron - qui affiche ou masque la vue Inline Spécification du diagramme ,
· Flèche Diagrammes ouverts - qui affiche une liste de diagrammes ouverts, indiquant celui avec des modifications
non enregistrées,
· Fermer Diagramme Icône - permet de fermer le diagramme .

Contenu Diagramme

Le contenu diagramme est le canevas sur lequel vous visualisez et travaillez sur votre diagramme . Il s'agit d'un espace de
travail très flexible doté de nombreux outils utiles pour créer et visualiser diagrammes existants. Des images peuvent être
ajoutées et mélangées avec les éléments géométriques SysML standard, permettant ainsi diagrammes expressifs et
convaincants qui aident à transmettre des concepts d'ingénierie importants à un public technique et non technique.

Enterprise Architect étend la manière d'afficher un diagramme en utilisant un certain nombre de techniques de
visualisation. Ceux-ci vous fourniront d'autres moyens de travailler avec le contenu diagramme et sont bien accueillis par
les nouveaux arrivants qui pourraient être plus familiers avec l'utilisation d'éléments dans des feuilles de calcul, des listes
et des documents. Notez également dans ce diagramme que les images peuvent être utilisées comme alternative aux
formes Vanilla SysML.

Vue des documents

Il s'agit d'une vue pratique qui affiche les éléments du diagramme sous forme narrative dans un document. Il est
également connu sous le nom de panneau 'Inline Spécification ' et ne constitue pas une vue séparée mais un panneau lié
au diagramme sélectionné. Le document est commodément ouvert à droite du diagramme afin que diagramme et le
document puissent être visualisés simultanément. Chaque élément présent dans le diagramme aura un titre dans le
document avec les notes (description) de l'élément affichées en position sous le titre. Les éléments et leurs notes
présentés dans cette vue peuvent être facilement modifiés, tout en visualisant à la fois la vue du document et le
diagramme , et les deux restent synchronisés. Les éléments sont par défaut classés par ordre alphabétique mais cet ordre
de tri peut être modifié depuis le menu contextuel pour suivre de haut en bas ou de gauche à droite.

Liste Vue

Il s'agit d'un moyen utile de visualiser les éléments dans un diagramme tout en leur permettant d'être visualisés, mis à
jour et créés dans une vue familière de type feuille de calcul. Les propriétés des éléments, y compris les propriétés
standard, Valeur Étiquetés et notes peuvent être gérées, et des listes déroulantes pour les propriétés avec une liste discrète
de valeurs sont disponibles, offrant un moyen bienvenu de visualiser ces propriétés sur plusieurs éléments.

Spécification Vue

Le Gestionnaire de Spécification ressemble à la visionneuse de documents en ligne, mais offre plus de puissance et
s'ouvre dans une fenêtre ancrable séparée. Il s'agit de l'outil parfait, conçu pour les ingénieurs et autres parties prenantes
plus habitués à travailler avec des feuilles de calcul ou des documents. Il permet essentiellement à un modélisateur ou à
un visualiseur de visualiser le contenu d'un diagramme (ou Paquetage ) sous forme de document ou de feuille de calcul.
La vue du document ressemble au document de traitement de texte familier, qui peut être modifié en ligne pour créer de
nouveaux éléments et leurs descriptions. La visualisation peut être modifiée pour ressembler à une feuille de calcul où les
propriétés sont affichées en colonnes.

Il s'agit d'une vue très appréciée par ceux qui abandonnent les processus d'ingénierie système basés sur des documents, et
une vue préférée des ingénieurs qui saisissent des informations basées sur des tests, telles qu'un ensemble d'exigences,
d'activités, de composants et d'autres éléments.

Diagramme de Gantt

Cela fournit une vue typique d'un diagramme de Gantt des éléments du diagramme dans lequel l'allocation des ressources
a été appliquée aux éléments. Elle peut être visualisée pour donner à un ingénieur ou à un chef de projet une vue de
l'avancement du modèle.

Outils de création de diagrammes

Il existe également un large éventail d'autres outils qui peuvent être utilisés pour afficher les informations dans le
référentiel et qui aideront l'ingénieur lorsqu'il travaille avec des éléments dans diagrammes , notamment, mais sans s'y
limiter :

Fenêtre de traçabilité
Utilisé pour voir comment les éléments du modèle sont connectés dans un graphique d'éléments et leurs relations. Pour
plus d’informations, consultez la rubrique The Traceability Window .

Fenêtre Relations
Utilisé pour afficher la relation entre un élément sélectionné et d'autres éléments du modèle ; ces relations ne sont pas
visibles mais peuvent être facilement visualisées dans cette fenêtre séparée. Pour plus d’informations, consultez la
rubrique The Relationships Window .

Pan et zoom
Utilisé pour se déplacer dans un grand diagramme en utilisant un petit rectangle qui représente la fenêtre d'affichage et
pour zoomer à l'aide d'un curseur. Pour plus d’informations, consultez la rubrique Pan and Zoom .

Disposition Diagramme
Utilisé pour créer des mises en page attrayantes d'un diagramme , en utilisant motifs disposition visuelle sélectionnés tels
que des digraphes et des ressorts. Pour plus d’informations, consultez la rubrique Layout Diagrams .

Filtres de Diagramme
Utilisé pour filtrer les éléments de la vue dans un diagramme soit en les masquant, en les changeant en échelle de gris ou
en les estompant. Vous pouvez également inverser le comportement et sélectionner l'élément à inclure. Pour plus
d'informations, consultez la rubrique Diagram Filters .

Feuilles de Route
Utilisé pour créer des représentations d'éléments basées sur le temps, avec une échelle de temps appliquée qui peut être
configurée en fonction du projet ou du modélisateur pour afficher une feuille de route à des fins stratégiques et de
développement. Pour plus d'informations, consultez le sujet Roadmap Diagram .

Kanban
Utilisé pour gérer les éléments dans un diagramme Kanban traditionnel, où les éléments sont déplacés entre des colonnes
qui représentent leur ordre dans un processus par étapes ; les ressources travaillant sur les éléments peuvent être
visualisées, offrant ainsi à une équipe un moyen utile de gérer son développement de modèle ou de produit. Pour plus
d'informations, consultez la rubrique Kanban Boards .

Rubans et menus Diagramme

Il existe un certain nombre de rubans utiles lorsque vous travaillez avec diagrammes . Le point de départ, comme décrit
précédemment, est le panneau ' Diagramme ' du ruban Conception, qui vous permet d'insérer de nouveaux diagrammes et
d'éditer et de changer la vue des diagrammes existants.

Le panneau "Élément" du ruban Conception sera également utile lorsque vous travaillerez avec des éléments sur le
diagramme (ou sélectionnés dans la fenêtre Navigateur ) vous permettant d'insérer de nouveaux éléments, de modifier
ceux existants et de gérer les propriétés, fonctionnalités et responsabilités des éléments. Pour plus d'informations,
consultez la rubrique d'aide Design Ribbon .

Un autre ruban important est le ruban Disposition , qui contient un certain nombre de panneaux qui seront utiles pour
travailler avec diagrammes . Cela inclut le panneau ' Diagramme ', qui contient des options pour définir des thèmes et
changer le mode diagramme , par exemple en Dessiné à la main. Pour plus d’informations, consultez la rubrique Layout
Ribbon .

Le panneau « Style » permet de définir les propriétés de style visuel des éléments diagramme soit en tant que groupe, soit
pour des éléments individuels.

Le panneau « Alignements » fournit un riche ensemble d'outils pour aligner les éléments dans un diagramme . Celles-ci
sont très utiles et fournissent une gamme d'options d'alignement qui ne sont généralement pas disponibles dans la plupart
Paquetages de dessins, permettant aux éléments - par exemple - d'être espacés uniformément horizontalement ou
verticalement.
Le panneau "Outils" fournit une série d'outils pour travailler avec diagrammes , permettant de filtrer le contenu des

diagrammes - par exemple, permettant à un modélisateur d'afficher uniquement les éléments de contrainte avec un statut
spécifié, qui ont été créés après une date spécifiée - Pan et Zoom et Options Disposition . Le panneau Filtre offre un
moyen rapide et ponctuel de filtrer le contenu du diagramme sans avoir besoin de créer un filtre diagramme .

Une série d'assistants sont également disponibles pour travailler avec diagrammes et leurs éléments, contrôlant des
éléments tels que le maintien horizontal et vertical pour restreindre le mouvement diagonal des éléments.

Propriétés du Diagramme

Un diagramme dans Enterprise Architect possède un riche ensemble de propriétés, certaines étant descriptives - comme
le nom - et d'autres prescriptives, spécifiant comment le diagramme doit être affiché et quels éléments, compartiments et
autres fonctionnalités doivent être visibles, y compris les styles de ligne.
Beaucoup de ces propriétés peuvent être définies à la fois au niveau diagramme et au niveau des éléments ou des
connecteurs, permettant ainsi à des parties individuelles du diagramme d'être affichées différemment des autres.
La possibilité de définir la visibilité des compartiments d'éléments est particulièrement utile pour diagrammes
d'ingénierie, car SysML fournit un riche ensemble de compartiments pour un large éventail d'éléments. Ces
compartiments, s'ils ne sont pas gérés, peuvent encombrer un diagramme et atténuer la capacité du lecteur à comprendre
la signification du diagramme .
Les compartiments, comme pour d'autres propriétés, peuvent être définis au niveau d'un diagramme ou d'un élément, ce
qui permet à un modélisateur de sélectionner les compartiments à afficher pour des éléments spécifiques.

Interrompre lorsqu'une Variable Change de Valeur

Le diagramme Bloc Definition est le plus utilisé des diagrammes SysML ; il est utilisé pour modéliser les Blocs, leurs
relations avec d'autres éléments (y compris d'autres Blocs) et leurs fonctionnalités sous forme de Propriétés , Opérations
et Réceptions. Les blocs sont des unités modulaires de description du système et fournissent un moyen de modélisation
des systèmes sous forme de graphique ou d'arbre d'unités modulaires. D'autres éléments, tels que ConstraintBlocks et
Propriétés , peuvent également apparaître sur le diagramme et aider à décrire le système modélisé. Pour plus
d'informations, consultez la rubrique d'aide Block Definition Diagrams (BDDs) .

Éléments

Les principaux éléments pouvant apparaître dans diagrammes de définition Bloc sont fournis par la boîte à outils
Diagramme pour ce type diagramme :

Les principaux connecteurs qui peuvent apparaître dans diagrammes de définition Bloc sont les suivants :

Outils

Une variété d'outils peuvent être utilisés avec modélisation structurelle et diagrammes de définition Bloc , notamment :
· Filtres de Diagramme - qui permet à un utilisateur de filtrer des éléments hors du diagramme pour obtenir une
concentration plus spécifique
· Pan et zoom : permet à un modélisateur ou à un visualiseur de se déplacer facilement dans de grands diagrammes .
· Importation et exportation de feuilles de calcul (CSV) - qui permet d'importer ou d'exporter le contenu des feuilles
de calcul à partir du modèle

· Documentation - qui permet de générer une documentation formelle ou informelle à partir du modèle dans une
variété de formats
· Traçabilité - qui fournit une vue hiérarchique des relations d'un élément avec d'autres éléments du modèle
· Fenêtre de responsabilité - qui fournit une vue composite des responsabilités importantes d'un élément, y compris les
contraintes, Exigences et les scénarios
· Matrice de relations - qui permet de visualiser les connexions entre les blocs (ou d'autres éléments) et d'autres
éléments tels que Exigences et les cas d'utilisation dans une matrice

Usage

L' Interrompre lorsqu'une Variable Change de Valeur est un diagramme à usage général qui peut être utilisé pour décrire
les aspects structurels d'un système.

Diagramme des exigences

Le diagramme Exigences est utilisé pour créer et visualiser Exigences et leurs relations avec d'autres éléments, y compris
d'autres Exigences . Exigences peuvent être spécifiées à n'importe quel niveau, depuis les exigences stratégiques de
l'entreprise ou de l'entreprise jusqu'aux exigences des parties prenantes jusqu'à l'ingénierie de bas niveau et même aux
exigences en matière de logiciels et de transition. Pour plus d'informations, consultez la rubrique d'aide SysML
Requirements Modeling .

Les éléments contenus dans ce diagramme peuvent être visualisés de différentes manières, notamment :
· Spécification Vue - permettant d'afficher les éléments et leurs notes au format traitement de texte ou tableur dans une
fenêtre ancrable séparée
· Inline Spécification Vue - permettant de visualiser côte à côte le diagramme et une liste de ses éléments sous forme
narrative
· List Vue - permettant de visualiser les éléments diagramme dans une liste pouvant être triée et les éléments
regroupés par propriétés
· Gantt Vue - permettant aux éléments diagramme d'être représentés sur un diagramme de Gantt montrant comment
les ressources sont utilisées au fil du temps

Éléments

Les principaux éléments pouvant apparaître dans diagrammes Exigences sont :

· Exigence
· Cas Test
Les principaux connecteurs pouvant apparaître dans diagrammes Exigences sont :

· Endiguement
· Tracer
· Copie
· Dériver
· Vérifier
· Affiner
· Satisfaire

Outils

Une variété d'outils peuvent être utilisés avec modélisation des exigences, notamment :
· Gestionnaire de Spécification - qui permet à un utilisateur de travailler avec des exigences dans un format de type
tableur ou traitement de texte
· Importation et exportation de feuilles de calcul (CSV) - qui permet d'importer ou d'exporter le contenu des feuilles
de calcul à partir du modèle
· Documentation - qui permet de générer une documentation formelle ou informelle à partir du modèle dans une
variété de formats
· Traçabilité - qui fournit une vue hiérarchique des relations d'un élément avec d'autres éléments du modèle
· Fenêtre de responsabilité - qui fournit une vue composite des responsabilités importantes d'un élément, y compris les
contraintes, Exigences et les scénarios
· Matrice de relation - qui permet de visualiser les liens entre l'exigence (ou d'autres éléments) et d'autres éléments tels
que les besoins des parties prenantes dans une matrice
· Mind Mapping - qui permet d'enregistrer le déroulement d'une réunion, enregistrant ainsi - par exemple - les besoins
des parties prenantes
Le plus largement utilisé de ces outils d'exigences serait probablement le Gestionnaire de Spécification , qui fournira une
manière bienvenue et familière de travailler avec des spécifications textuelles telles que des exigences ou des contraintes.
Le Gestionnaire de Spécification peut être utilisé pour visualiser une liste d'éléments contenus dans un Paquetage ou un
diagramme .

Usage

Le diagramme Exigences peut être utilisé pour montrer une hiérarchie d'exigences en utilisant la relation de confinement
permettant à un spectateur de voir comment les relations structurelles des exigences. C'est cependant plus convaincant
lorsque Exigences sont vues dans un diagramme avec d'autres éléments utilisant d'autres relations, y compris d'autres
exigences. Un exemple de ceci est la relation entre Exigences et les cas Test ou Exigences et les composants d'une
solution.

Diagramme de cas d'utilisation

Le diagramme de cas d'utilisation est utilisé pour définir et visualiser les cas d'utilisation et les acteurs qui tirent de la
valeur du système. Le diagramme de cas d'utilisation décrit la relation entre les acteurs et les cas d'utilisation, enfermant
le cas d'utilisation dans une Bordure qui définit la frontière du système ; les Acteurs, par définition, se situent en dehors
de la Bordure . Bien que le diagramme de cas d'utilisation puisse paraître simpliste, il s'agit d'un outil de communication
utile qui décrit la valeur ou les objectifs que les rôles externes obtiennent en interagissant avec le système. Chaque cas
d'utilisation peut être détaillé avec des descriptions, des contraintes et un nombre illimité de scénarios contenant des
ensembles d'étapes exécutées alternativement par l'acteur et le système pour atteindre l'objectif souhaité.

Éléments

Les principaux éléments pouvant apparaître dans diagrammes de cas d’utilisation sont :

· Bordure
· Acteur
· Cas d'utilisation
· Scénario
Les principaux connecteurs pouvant apparaître dans diagrammes de cas d'utilisation sont :
· Voie Communication
· Généralisation

· Comprend
· Prolonge

Outils

Il existe une variété d'outils disponibles pour travailler avec des cas d'utilisation en plus du diagramme de cas
d'utilisation lui-même. Ceux-ci inclus:
· Fenêtre Scénario - qui permet de détailler les descriptions, les contraintes et l'étape de chaque scénario
· Générateur de documentation - qui permet de créer des documents d'entreprise, des rapports ou des documents ad
hoc dans une variété de formats, notamment docx, pdf et rtf.
· Traçabilité - qui fournit une vue hiérarchique des relations d'un élément avec d'autres éléments du modèle
· Fenêtre de responsabilité - qui fournit une vue composite des responsabilités importantes d'un élément, y compris
les contraintes, Exigences et les scénarios
· Matrice de relation - qui permet de visualiser les liens entre l'exigence (ou d'autres éléments) et d'autres éléments
tels que les besoins des parties prenantes dans une matrice
Le principal outil utilisé pour travailler avec les cas d'utilisation est la fenêtre Scénario, qui est une facilité complète et
spécialement conçue pour travailler avec des cas d'utilisation et des scénarios. L'outil peut être utilisé pour définir les
détails d'un cas d'utilisation, ainsi que ses scénarios et contraintes, ce qui constitue une alternative productive à
l'approche traditionnelle basée sur des documents texte pour définir des cas d'utilisation. Cela garantit que le diagramme
de cas d'utilisation et les détails textuels des cas d'utilisation et de ses scénarios et contraintes sont tous contenus dans le
même modèle et peuvent être tracés.
Si les cas d'utilisation sont requis dans un format de document pour des raisons contractuelles ou de processus, un
Rapport de cas d'utilisation peut être généré automatiquement à partir des modèles à l'aide du moteur de documentation
intégré.
Scenario Builder

Usage

Le diagramme de cas d'utilisation peut être utilisé pour définir les détails d'un cas d'utilisation ainsi que de ses scénarios
et contraintes. Il s’agit d’une alternative bienvenue à l’approche traditionnelle basée sur des documents texte
couramment utilisée pour définir les cas d’utilisation. Cela garantit que le diagramme de cas d'utilisation et les détails
textuels des cas d'utilisation et de ses scénarios et contraintes sont tous contenus dans le même modèle et peuvent être
tracés. Si les cas d'utilisation doivent être présentés sous forme de document pour des raisons contractuelles ou de
processus, un Rapport de cas d'utilisation peut être généré automatiquement à partir des modèles à l'aide du moteur de
documentation intégré.

Diagramme Paquetage
Le diagramme SysML Paquetage est utilisé pour définir ou visualiser les Paquetages qui fournissent l'organisation
fondamentale du référentiel. Ceux-ci peuvent inclure des espaces de noms et leurs sous-packages ainsi que d'autres
groupes d'éléments moins formellement définis. Les Paquetages qui apparaissent dans diagrammes peuvent également
être visualisés dans la fenêtre Navigateur et leur hiérarchie peut être parcourue en développant et en réduisant
l'arborescence.

L'élément principal représenté dans le diagramme Paquetage est le Paquetage lui-même, avec les éléments qu'il contient.
Il existe un certain nombre de relations importantes entre Paquetages , y compris les Dépendances qui montrent qu'un
Paquetage dépend d'un ou plusieurs autres Paquetages . Paquetages peuvent être organisés selon différents types de
hiérarchie.

Éléments

Les principaux éléments pouvant apparaître dans diagrammes Paquetage sont :

· Modèle
· Bibliothèque d'Équipe
· Paquetage
· Vue
· Point Vue
· Partie prenante
Les principaux connecteurs pouvant apparaître dans diagrammes Paquetage sont :
· Se conformer
· Dépendance
· Importer
· Endiguement
· La concrétisation
· Affiner
· Exposer

Outils

Une variété d'outils peuvent être utilisés avec modélisation structurelle et diagrammes de définition Bloc , notamment :
· Documentation - qui permet de générer une documentation formelle ou informelle à partir du modèle dans une
variété de formats
· Traçabilité - qui fournit une vue hiérarchique des relations d'un élément avec d'autres éléments du modèle
· Fenêtre de responsabilité - qui fournit une vue composite des responsabilités importantes d'un élément, y compris les
contraintes, Exigences et les scénarios
· Matrice de relations - qui permet de visualiser les connexions entre Paquetages (ou d'autres éléments) et d'autres
éléments tels que Exigences et les cas d'utilisation dans une matrice

Usage

Le diagramme Paquetage peut être utilisé pour décrire la relation entre Paquetages et les éléments qu'ils contiennent.
Bien que les informations structurelles soient visibles dans la fenêtre Navigateur , il existe une gamme de relations qui
peuvent exister entre Paquetages eux-mêmes et entre Paquetages et les éléments, qui ne peuvent pas être visualisées dans
la fenêtre Navigateur . diagrammes Paquetage peuvent également être inclus dans la documentation et peuvent aider à
orienter un public en lui donnant un aperçu d'une section de l'architecture ou de la conception de la même manière qu'en
fournissant un tableau du contenu dans une publication.

Diagrammes d'activités
Le diagramme d'activité est le diagramme de comportement le plus important et peut être utilisé pour modéliser un
comportement basé sur un flux (discret ou continu) où les entrées sont converties en sorties en parcourant une séquence
d'actions qui effectuent un travail sur les éléments. Ils sont analogues au diagramme de flux commun mais ont une
sémantique plus sophistiquée et permettent également de relier les activités et les actions à des éléments tels que les
blocs, Exigences et les cas d'utilisation.
Les actions qui apparaissent sur les diagrammes d'activité peuvent contenir pins d'entrée ou de sortie qui représentent les
points d'interaction où les entrées sont introduites dans une action et les sorties sont émises.

Usage

Le diagramme d'activité peut être utilisé pour modéliser un comportement basé sur le flux et est similaire aux
diagrammes de flux ou de flux fonctionnels largement disponibles qui avaient été largement utilisés avant la conception
de la spécification SysML. Ils sont généralement utilisés pour montrer le comportement de certaines parties du système,
y compris l'entrée et la sortie d'éléments et de signaux.

Éléments

Les principaux éléments pouvant apparaître dans diagrammes d’activités sont :

· Activité
· Action (divers types)
· Épingle Action
· Cloison
· Nœud Object

· Nœud tampon central

· Magasin de données
· Décision
· Fusionner
· Initial
· Final
Les principaux connecteurs pouvant apparaître dans diagrammes d'activités sont :
· Flux de contrôle
· Flux Object
· Flux d'interruption
· Dépendance

Outils

Une variété d'outils peuvent être utilisés avec modélisation comportementale et diagrammes d'activité, notamment :
· Filtres de Diagramme - qui permet à un utilisateur de filtrer des éléments hors du diagramme pour obtenir une
concentration plus spécifique
· Pan et zoom : permet à un modélisateur ou à un visualiseur de se déplacer facilement dans de grands diagrammes .
· Importation et exportation de feuilles de calcul (CSV) - qui permet d'importer ou d'exporter le contenu des feuilles
de calcul à partir du modèle
· Documentation - qui permet de générer une documentation formelle ou informelle à partir du modèle dans une
variété de formats
· Traçabilité - qui fournit une vue hiérarchique des relations d'un élément avec d'autres éléments du modèle
· Fenêtre de responsabilité - qui fournit une vue composite des responsabilités importantes d'un élément, y compris les
contraintes, Exigences et les scénarios
· Matrice de relations - qui permet de visualiser les connexions entre les activités (ou d'autres éléments) et d'autres
éléments tels que les blocs, Exigences et les cas d'utilisation dans une matrice

Diagramme Interne de Bloc

Le diagramme Bloc interne permet de visualiser la composition d'un bloc à l'aide des propriétés des pièces connectées
entre elles à l'aide de ports et de connecteurs. Le diagramme est utile pour montrer la composition d'un Bloc (représenté
par le cadre diagramme ) et le flux d'entrées et de sorties entre les différentes parties qui composent le bloc. Si nécessaire,
le sens du flux peut être indiqué sur les connecteurs.

Éléments

Les principaux éléments pouvant apparaître dans diagrammes de définition Bloc sont :
· Propriété
· Propriété du connecteur
· Propriété distribuée
· Propriété de flux
· Référence liée
· Multiplicité du chemin de fin
· Signal
· Port
Les principaux connecteurs pouvant apparaître dans diagrammes de définition Bloc sont :
· Flux Item
· Connecteur
· Connecteur de liaison
· Dépendance

Outils

Une variété d'outils peuvent être utilisés avec modélisation structurelle et diagrammes Bloc internes, notamment :
· Filtres de Diagramme - qui permet à un utilisateur de filtrer des éléments hors du diagramme pour obtenir une
concentration plus spécifique
· Pan et zoom : permet à un modélisateur ou à un visualiseur de se déplacer facilement dans de grands diagrammes .
· Importation et exportation de feuilles de calcul (CSV) - qui permet d'importer ou d'exporter le contenu des feuilles
de calcul à partir du modèle
· Documentation - qui permet de générer une documentation formelle ou informelle à partir du modèle dans une
variété de formats
· Traçabilité - qui fournit une vue hiérarchique des relations d'un élément avec d'autres éléments du modèle
· Fenêtre de responsabilité - qui fournit une vue composite des responsabilités importantes d'un élément, y compris les
contraintes, Exigences et les scénarios
· Matrice de relations - qui permet de visualiser les connexions entre les blocs (ou d'autres éléments) et d'autres
éléments tels que Exigences et les cas d'utilisation dans une matrice

Usage

Le diagramme Bloc interne est utilisé pour modéliser la structure interne d'un bloc, y compris ses parties et la relation
entre ces parties.

Diagramme Paramétriques
Le Diagramme Paramétriques SysML est un type de Diagramme Interne de Bloc (avec quelques restrictions) qui est
utilisé pour modéliser une équation avec des paramètres. Ils constituent un outil important qui peut être utilisé pour
décrire les équations et leurs paramètres et sont importants lors de l'analyse des compromis et de l'évaluation des
alternatives de conception, car ils peuvent être combinés dans des systèmes d'équations et liés aux mesures d'efficacité
des ME.

diagrammes Paramétriques décrivent l'utilisation de blocs de contraintes et fournissent un mécanisme d'intégration

d'analyses techniques telles que les performances et la fiabilité et d'autres facteurs d'intérêt avec d'autres modèles et
diagrammes SysML.
diagrammes Paramétriques définissent la manière dont les blocs de contraintes sont utilisés pour contraindre les
propriétés d'un autre bloc. On dit que l'utilisation d'une contrainte lie les paramètres de la contrainte (par exemple
F=m*a), tels que F, m et a, à des propriétés spécifiques d'un bloc, telles qu'une masse et une accélération, qui fournissent
des valeurs pour Les paramètres.

Éléments

Les principaux éléments pouvant apparaître dans diagrammes Paramétriques sont :

· Propriété de contrainte
· Propriété
· Fonction objectif
· Mesure de l'efficacité
Les principaux connecteurs pouvant apparaître dans diagrammes Paramétriques sont :
· Connecteur
· Connecteur de liaison
· Flux Item
· Dépendance

Outils

Une variété d'outils peuvent être utilisés avec modélisation structurelle et diagrammes Bloc internes, notamment :

· Modelica Integration - qui fournit un mécanisme de simulation,

· Filtres de Diagramme - qui permet à un utilisateur de filtrer des éléments hors du diagramme pour obtenir une
concentration plus spécifique,
· Pan et zoom - qui permettent à un modélisateur ou à un visualiseur de se déplacer facilement dans de grands
diagrammes ,
· Importation et exportation de feuilles de calcul (CSV) - qui permet d'importer ou d'exporter le contenu des feuilles
de calcul à partir du modèle,
· Documentation - qui permet de générer une documentation formelle ou informelle à partir du modèle dans une
variété de formats,
· Traçabilité - qui fournit une vue hiérarchique des relations d'un élément avec d'autres éléments du modèle,

Usage

Le diagramme Paramétriques peut être utilisé pour montrer comment les propriétés physiques d'un système sont
contraintes en spécifiant un réseau de contraintes qui représentent des expressions mathématiques telles que {F=m*a} et
{a=dv/dt}.
Ils peuvent également être utilisés pour l'analyse des compromis, où un Bloc de contraintes peut définir une fonction
objective utilisée pour effectuer une comparaison entre des solutions alternatives.
Les paramètres de performance critiques et leurs relations avec d'autres paramètres peuvent être modélisés, qui peuvent
ensuite être suivis tout au long du cycle de vie du système.

Diagramme de Séquence
Un diagramme Séquence est un type de diagramme d'interaction qui montre l'interaction ordonnée dans le temps entre
des objets. Le diagramme comporte deux axes ; l'axe vertical représente le temps et l'axe horizontal représente les objets
qui participent à l'interaction, généralement ordonnés de la manière qui éclaire le mieux l'interaction. Ces diagrammes
ont leur origine dans la modélisation des interactions logicielles, mais ils peuvent être utilisés avec l'ingénierie des
systèmes pour prescriptir la manière dont les éléments (tels que les blocs) doivent interagir, ou descriptifs pour montrer
comment ils interagissent, dans la pratique.
Ce diagramme Séquence montre les interactions et la séquence des flux de messages entre un conducteur et un véhicule.
Le diagramme exprime les interactions nécessaires pour le cas d'utilisation « Conduire le véhicule ». L'interaction
appartient au Bloc 'AutomotiveDomain'.

Éléments

Les principaux éléments pouvant apparaître dans diagrammes Paramétriques sont :

· Séquence
· Fragment
· Point de terminaison
· Porte Diagramme
· State /Suite
Les principaux connecteurs pouvant apparaître dans diagrammes Paramétriques sont :
· Message
· Message personnel
· Récursivité
· Dépendance

Outils

Une variété d'outils peuvent être utilisés avec modélisation comportementale et diagrammes d'activité, notamment :
· Filtres de Diagramme - qui permet à un utilisateur de filtrer des éléments hors du diagramme pour obtenir une
concentration plus spécifique,
· Pan et zoom - qui permettent à un modélisateur ou à un visualiseur de se déplacer facilement dans de grands
diagrammes ,
· Importation et exportation de feuilles de calcul (CSV) - qui permet d'importer ou d'exporter le contenu des feuilles
de calcul à partir du modèle,
· Documentation - qui permet de générer une documentation formelle ou informelle à partir du modèle dans une
variété de formats,
· Traçabilité - qui fournit une vue hiérarchique des relations d'un élément avec d'autres éléments du modèle,
· Fenêtre de responsabilité - qui fournit une vue composite des responsabilités importantes d'un élément, y compris les
contraintes, Exigences et les scénarios
Matrice de relations - qui permet de visualiser les connexions entre les activités (ou d'autres éléments) et d'autres
éléments tels que les blocs, Exigences et les cas d'utilisation dans une matrice.

Usage

Le fait même que l’on modélisation un système implique qu’il présente un degré de complexité qui ne peut être géré sans
l’utilisation d’outils. diagrammes Séquence peuvent être utilisés pour représenter des scénarios de système montrant
comment les parties d'un système interagissent entre elles pour atteindre un résultat spécifié. On dit que les messages
sont échangés entre lignes de vie représentant la durée de vie de l' object , les messages représentent des opérations ou
des signaux envoyés et reçus par les objets.

Diagramme Statemachine
Un diagramme Statemachine est un moyen efficace de présenter des informations sur la durée de vie d'un élément du
système tel qu'un Bloc . Il peut être utilisé pour décrire les conditions importantes ( States ) qui se produisent au cours de
la vie ou des cycles d'une entité. En règle générale, seules les entités qui comportent des étapes importantes dans leur vie
sont modélisées avec diagrammes Statemachine . On dit que l'entité passe d'un State à un autre comme spécifié par le
Statemachine . Déclencheurs et Événements peuvent être décrits qui permettent à la transition d'état de se produire et des
gardes peuvent être définies qui restreignent le changement d'état. Chaque State peut définir les comportements qui se
produisent à l'entrée, pendant et à la sortie de l' State .

Éléments

Les principaux éléments pouvant apparaître dans diagrammes Paramétriques sont :

· State
· Statemachine
· Initial
· Final
· Choix
· Histoire
· Fourche et Joindre
Les principaux connecteurs pouvant apparaître dans diagrammes Paramétriques sont :
· Transition
· Dépendance

Outils

Une grande variété d'outils sont disponibles pour travailler avec diagrammes Statemachine , en plus du diagramme
Statemachine lui-même. Ceux-ci inclus:
· State Tableau Editor - Qui permet de visualiser le diagramme Statemachine dans un tableau qui, pour certains
analystes, est plus facile à comprendre qu'un diagramme ; il contient les mêmes informations que le diagramme et
peut être visualisé de différentes manières
· Simulation Dynamique - Permet de visualiser Statemachines , montrant comment une entité passe d'un état à un
autre
· Statemachines Exécutables - En plus d'utiliser le moteur de simulation et de permettre la visualisation Statemachines
, fournissez une implémentation complète spécifique au langage qui peut former le « moteur » comportemental pour
plusieurs produits logiciels sur plusieurs plates-formes.

Usage

Les systèmes complexes sont souvent composés d'entités telles que des blocs qui ont un comportement complexe et
peuvent avoir des durées de vie difficiles à comprendre.
Statemachines peuvent être utilisées pour décrire les conditions importantes ( States ) qui se produisent au cours de la vie
ou des cycles d'une entité. En règle générale, seules les entités qui comportent des étapes importantes dans leur vie sont
modélisées avec diagrammes Statemachine . Ces diagrammes donnent un aperçu de la manière dont une entité passe d'un
état à l'autre, en ignorant les conditions qui ne sont pas importantes pour l'analyse.

Présentation Langage Modélisation des Systèmes

L'ingénierie système basée sur Modèle modèles annonce une nouvelle ère de communication et de collaboration sur des
modèles en temps réel. Il évoque le concept du modèle comme une machine plutôt que comme une armoire remplie de
documents. Une machine capable d'effectuer des travaux tels que valider des exigences, générer des simulations
paramétriques d'équations mathématiques et physiques complexes, donner vie à Statemachines et simuler une logique
commerciale et décisionnelle, évoluer en réponse aux révisions et créer de la documentation, pour n'en citer que
quelques-unes. Ces avantages sont réalisés grâce à la puissance d' Enterprise Architect et parce qu'un langage standard et
partagé est utilisé pour créer les modèles - le Langage Modélisation des Systèmes , communément abrégé en SysML .

SysML permet aux humains et aux machines de comprendre les modèles - les humains ajoutant de l'ingéniosité, de
l'ingénierie et de la conception et les machines effectuant les tâches fastidieuses et sujettes aux erreurs telles que la
validation, faisant le gros du travail comme la génération de simulations paramétriques et l'exécution d'analyses de
simulation, et effectuer les tâches les plus banales telles que la recherche et la génération de rapports.
L'acquisition d'une langue n'est pas quelque chose qui se fait gratuitement, mais c'est quelque chose qui peut se faire sans
douleur ni frustration et sans ce que certains sceptiques appellent un « flair pour les langues ». Enterprise Architect sera
également un ami qui vous aidera à formation le langage en fournissant de nombreux dispositifs intégrés pour vous aider
à la formation , ainsi qu'une bibliothèque riche et complète de motifs de modèles qui vous aideront à démarrer,
garantissant que vous créez le meilleur de l'industrie. -des modèles de pratique.

Lorsque vous commencez votre parcours avec Enterprise Architect vous faites immédiatement et sans effort partie d'une
vaste communauté internationale d'utilisateurs et de praticiens, qui travaillent avec l'outil jour après jour pour spécifier,
concevoir, mettre en œuvre et support des modèles d'ingénierie système utilisés pour résoudre des problèmes du monde
réel. Beaucoup de ces problèmes et opportunités sont complexes et souvent apparemment insolubles, mais peuvent être
résolus par la collaboration de modélisateurs appliquant SysML pour exprimer et résoudre les problèmes.

Enterprise Architect facilite cette collaboration de manière transparente grâce à ses riches plates-formes de bureau et
Cloud qui contribuent à garantir que les modèles sont à la fois robustes et expressifs, et sont le résultat non pas d'un mais
de plusieurs ingénieurs et autres parties prenantes, travaillant ensemble quelle que soit la langue naturelle qu'ils parlent. ,
quel appareil ils utilisent ou où ils se trouvent dans le monde.

Architecture du langage
Le Systems Modeling Language (SysML) est fondamentalement un ensemble de symboles conventionnels qui
permettent aux humains et aux outils de communiquer sur l'ingénierie des systèmes. Il s'agit d'une norme internationale
qui définit et décrit un langage modélisation à usage général pour l'ingénierie des systèmes. Enterprise Architect est l'un
des principaux outils au monde qui implémente cette norme et permet aux ingénieurs système d'appliquer l'approche
connue sous le nom Ingénierie Systèmes Modèles Basée . En outre, Enterprise Architect propose fonctionnalités d'outils
qui support un large éventail d'aspects auxiliaires de la pratique et de la gestion de l'ingénierie. Nous explorerons ces
fonctionnalités d’outils utiles et productives tout au long de ce guide.
Le SysML est basé sur une autre norme, le Unified Modeling Language (UML) , adopté et utilisé par les ingénieurs
logiciels depuis la fin des années 90. Ceci est important, car de nombreux projets Ingénierie des Systèmes impliquent à la
fois des aspects système et logiciels et ainsi les ingénieurs système et logiciels sont capables de comprendre les modèles
de chacun, ce qui conduit à une plus grande transparence, moins de risques d'erreurs et des constructions linguistiques
mutuellement intelligibles, résultant en un système qui est moins susceptible de tomber en panne ou de présenter des
défauts. Ce diagramme de Venn montre la relation entre les deux normes. SysML réutilise les Diagrammes de cas
d'utilisation, d'activité et Séquence .

Exigences motivées

La création du Systems Modeling Language (SysML) a été motivée par les besoins des utilisateurs ; la conception du
SysML répondait aux besoins énoncés dans la demande de propositions pour le Unified Modeling Language pour
Ingénierie des Systèmes . Ce document spécifie une personnalisation d' UML pour Ingénierie des Systèmes (SE) et exige
que cette personnalisation support modélisation d'une large gamme de systèmes, qui pourraient inclure du matériel, des
logiciels, des données, du personnel, des procédures et facilités . Le document précise :
« La personnalisation d' UML pour Ingénierie des Systèmes doit support l'analyse, la spécification, la conception et la
vérification de systèmes complexes en :

· Capturer les informations des systèmes d'une manière précise et efficace qui permet de les intégrer et de les réutiliser
dans un contexte plus large

· Analyser et évaluer le système spécifié, pour identifier et résoudre les exigences du système et les problèmes de
conception, et pour support les compromis
· Communiquer les informations sur les systèmes correctement et de manière cohérente entre les différentes parties
prenantes et participants.
Les concepteurs d' Enterprise Architect ont lu ces documents et la spécification SysML qui en résulte en détail et ont créé
un outil sophistiqué et hautement utilisable qui met en œuvre toutes ces exigences et ajoute un riche ensemble de
fonctionnalités supplémentaires pour garantir le succès technique et commercial d'une organisation.

Pour qu’une langue soit utile et pertinente, elle doit évoluer en réponse aux besoins de ses communautés d’utilisateurs.
Pour répondre ainsi, la spécification SysML est mise à jour régulièrement et les équipes de Sparx Systems mettent
également à jour et étendent Enterprise Architect pour garantir qu'il est conforme à la norme évolutive et, plus
fondamentalement, répond aux divers besoins de sa communauté d'utilisateurs.

Réutilisation et extensions Unified Modeling Language

Le Systems Modeling Language (SysML) est construit sur le Unified Modeling Language (UML) . L' UML a été ratifié
et adopté par l' Object Management Group (OMG), qui continue d'être le gardien de la spécification. En 2005, UML a
également été publié par l'Organisation internationale de normalisation (ISO) en tant que norme ISO approuvée. Le
langage a fourni une spécification pour les systèmes centrés sur les logiciels modélisation . Le langage SysML remonte à
2001 et trouve ses origines dans une spécification open source, mais lorsque le Conseil international de Ingénierie des
Systèmes (INCOSE) a commencé à travailler avec l'OMG, une version finale du SysML a été adoptée par l'OMG en
2006.
À bien des égards, SysML est théoriquement le langage le plus primitif car il s'agit d'un langage modélisation à usage
général, et UML est plus spécialisé, étant conçu pour modélisation de systèmes centrés sur les logiciels. Cependant,
l'histoire et la genèse des langues ont inversé cette position. En pratique, SysML a été créé à l'aide du système de
profilage UML et constitue un sous-ensemble étendu d' UML . Cela signifie que SysML n'a pas pris tout UML et a
également défini certaines constructions de langage supplémentaires. Le diagramme de Venn que nous avons vu dans une
section précédente décrit mathématiquement les deux ensembles de constructions linguistiques qui se croisent.
L'implémentation Enterprise Architect de la spécification SysML est hautement conforme, les développeurs travaillant en
étroite collaboration avec la spécification et en communication constante avec les experts du secteur, les leaders
d'opinion et les communautés d'ingénierie système dans un large éventail d'industries. Cela a abouti à un outil de classe
mondiale qui non seulement implémente la spécification, mais fournit également une large gamme d'outils
supplémentaires tels que Statemachines Exécutables , des simulations Paramétriques , des diagrammes de Gantt, des

tableaux Kanban, du Mind Mapping, des modèles stratégiques et littéralement des centaines d'autres fonctionnalités .
En outre, l'interaction entre les problèmes et les solutions de l'ingénierie système et logicielle continue de croître dans un
large éventail de disciplines, des systèmes ferroviaires aux systèmes aéronautiques, en passant par les systèmes
énergétiques et bien d'autres encore. Enterprise Architect occupe une position unique en raison de ses formidables
fonctionnalités prenant en charge ces deux disciplines et également de ses atouts en tant qu'outil architectural.

Partitionnement avec Paquetages

Paquetages sont l'unité fondamentale de partitionnement dans le langage et sont conçus pour éviter les dépendances
circulaires. Le langage est formellement divisé en ensembles d'éléments de modèle qui regroupent les éléments
logiquement et permettent à un utilisateur du langage de comprendre les éléments comme un ensemble d'unités
linguistiques.
Ils constituent également l'unité structurelle fondamentale des modèles définis par l'utilisateur et agissent comme un
mécanisme à usage général utilisé pour regrouper des éléments en fonction de facteurs définis par l'utilisateur.
Formellement, ils peuvent être utilisés pour spécifier un espace de noms, ce qui est important dans certaines
constructions modélisation telles que la définition de schémas XML ou la génération de code. Paquetages peuvent être
créés et visualisés soit dans la fenêtre Navigateur , soit dans diagrammes , et les deux emplacements proposent
différentes manières de travailler avec les Paquetages . Diagrammes sont utiles pour afficher visuellement le contenu des
Paquetages ou pour décrire les relations qui existent entre Paquetages .

Architect propose de nombreuses façons d'afficher Paquetages dans diagrammes qui aideront les utilisateurs à
comprendre les relations structurelles entre Paquetages et les éléments et diagrammes qu'ils contiennent. Lorsqu'un

Paquetage est inclus dans un diagramme , l'outil permet à l'utilisateur de choisir parmi un certain nombre d'options
d'affichage et la visibilité du compartiment peut être modifiée pour afficher le contenu du Paquetage . Dans ce
diagramme l'auteur souhaite montrer le contenu de deux Paquetages qui ont une signification dans le cas peu probable
d'une collision. L'option « Afficher le contenu Paquetage » a été sélectionnée dans la visibilité du compartiment des
éléments, ce qui indique clairement quels éléments sont contenus dans chaque Paquetage .

Les mêmes Paquetages et leur contenu peuvent être visualisés dans la fenêtre Navigateur , il est important de rappeler
que s'il est possible d'inclure les diagrammes dans des publications telles que des rapports, le contenu de la fenêtre du
Navigateur ne serait pas visible dans ces documents.

Interopérabilité et Échange de Modèles

Enterprise Architect est l'un des principaux outils SysML doté d'un ensemble de fonctionnalités requis, mais les
concepteurs sont conscients que les organisations devront utiliser une variété d'outils pour accomplir les tâches
commerciales et d'ingénierie complexes auxquelles est confrontée chaque organisation du XXIe siècle. Siècle. Pour
garantir que les informations d'ingénierie et commerciales importantes sont disponibles pour être échangées avec d'autres
outils et plates-formes, il existe un riche support pour l'échange de modèles conformément à la norme d'échange de
données ISO 10303-233 pour support l'interopérabilité entre d'autres outils d'ingénierie. Ceci est implémenté sur la base
de la capacité d'échange UML XMI, qui est prise en charge dans l'outil au niveau du Paquetage , permettant à n'importe
quel Paquetage et à sa hiérarchie contenue d'être échangé avec d'autres outils conformes.

Enterprise Architect va plus loin et fournit des mécanismes d'échange avec une grande variété d'outils commerciaux, de
gestion de projet, d'analyse et de réalisation de projets. Ceci est réalisé au niveau de l'outil modélisation avec la
possibilité d'échanger des données contenues dans des feuilles de calcul au format de fichier CSV et du texte dans des
traitements de texte. Les données de référence telles que les listes de priorités, de statuts, de complexités, de contraintes
et d'autres données telles que les glossaires, les rôles et les auteurs, les calendriers et bien plus encore peuvent toutes être
importées et exportées depuis le référentiel.

Les informations géospatiales constituent un ensemble de données essentielles dans un monde où la géolocalisation est
un aspect important de presque tous les projets et initiatives. Enterprise Architect fournit un échange de données avec les
principaux outils modélisation géospatiale, permettant de visualiser et de gérer ensemble deux ensembles de données
auparavant disparates et hétérogènes.

Concepts grammaticaux clés

Le SysML, comme son parent l' UML , est un langage visuel où diagrammes sont au cœur de la stratégie de
communication du langage. Même si l'accent est mis sur la codification visuelle et la transmission des idées, le langage
offre également facilités pour exprimer les idées textuellement, ce qui constitue un complément important aux
mécanismes visuels. Un certain nombre d'éléments, tels que l'élément Exigence, ont une forme visuelle, mais les détails
de l'Exigence sont écrits dans une propriété appelée « texte » de l'Exigence, comme le montre ce diagramme .

Enterprise Architect a également été soigneusement conçu pour respecter la manière dont les différents utilisateurs
travaillent avec les informations. L'équipe de conception travaille en étroite collaboration avec sa communauté
d'utilisateurs et est consciente que certains utilisateurs travaillent mieux avec la visualisation schématique et d'autres avec
le texte. De nombreux outils disponibles dans Enterprise Architect ont été conçus en pensant à ces différents types
d'utilisateurs. Par exemple, dans la discipline Gestion des Exigences , les utilisateurs sont souvent plus habitués à
travailler sur des documents et des tableurs. Pour répondre à cela, Enterprise Architect dispose d'un certain nombre de
vues vers lesquelles les utilisateurs peuvent basculer, qui leur permettent de saisir, de modifier et de gérer Exigences via
ces types d'interface. L'un de ces outils est le Gestionnaire de Spécification , qui offre une manière flexible et familière de
travailler avec Exigences à la fois à partir d'une vue basée sur des documents et d'une feuille de calcul, permettant
Exigences d'être visualisées, créées et gérées en toute simplicité.

Modèles, Diagrammes , éléments et Vues

Des modèles

Le mot modèle est assez galvaudé et surchargé de sens. Certaines personnes utilisent modèle pour désigner un référentiel
entier tandis que d'autres l'utilisent pour faire référence à une section d'un référentiel complet. Les modèles sont les
divisions structurelles du référentiel.

Diagrammes

La spécification SysML définit neuf types diagramme . Il s'agit de la liste canonique et le SysML définit en plus les
éléments qui sont généralement utilisés sur chaque diagramme . De nombreux nouveaux arrivants et même certains
utilisateurs expérimentés ne savent pas que même si ces listes d'éléments décrivent les éléments couramment utilisés
pour un type diagramme particulier, cela n'empêche pas un modélisateur d'utiliser d'autres éléments sur ces diagrammes .
En fait, l'utilisation d'un certain nombre de types d'éléments sur le même diagramme aboutit à un modèle expressif et
permet aux parties prenantes et aux ingénieurs de différentes disciplines de comprendre les connexions inter-diagrammes
entre les modèles.
Dans cette section, nous apprendrons également qu'il existe un certain nombre d'éléments de modèle « universels » qui,
selon la spécification, peuvent être incorporés dans n'importe quel diagramme , notamment les commentaires, les
contraintes et les justifications. Ce diagramme montre une gamme de types d'éléments, notamment un Bloc , un Cas
d'Utilisation, une Exigence et un Cas Test , tous exprimés sur une Interrompre lorsqu'une Variable Change de Valeur
(BDD).

Comme indiqué précédemment, le Langage Modélisation des Systèmes spécifie neuf types différents de diagramme .

Éléments

Les neuf diagrammes décrits précédemment sont spécifiés individuellement pour transmettre un aspect particulier d'une

opportunité ou d'une solution d'ingénierie ; par exemple, le diagramme Paramétriques est destiné à montrer comment les
équations sont construites. Il existe cependant un certain nombre de types d'éléments qui sont universels dans le cadre de
la modélisation et peuvent apparaître sur n'importe quel type de diagramme . Beaucoup de ces éléments sont utilisés sur
diagrammes pour transmettre des annotations importantes à un modèle ou pour aider à expliquer un aspect particulier du
modèle. Ils incluent des éléments tels que Notes , Contraintes, Justifications et Vues . Dans ce diagramme une partie
prenante qui a consulté le modèle a ajouté un commentaire pour remettre en question une partie du modèle.

Pour plus d’informations, consultez la rubrique d’aide Common Pages .

Bien Enterprise Architect soit hautement conforme à la spécification SysML, il dispose d'un certain nombre de
fonctionnalités collaboratives qui permettent de gérer de tels commentaires, par exemple via sa fonctionnalité
Discussion. Cela permet de séparer les discussions des éléments proprement dits qui composent le modèle. Cette image
d'écran montre le même commentaire ajouté à l'aide de la fonctionnalité Discussion, qui permet des réponses et une
gamme d'autres appareils collaboratifs.

Pour plus d’informations, consultez la rubrique d’aide Discussions .

Le répondant aurait également pu envoyer un message Mail de Modèle , qui pourrait inclure un lien vers un élément ou
diagramme Enterprise Architect , comme indiqué.

Pour plus d'informations, consultez la rubrique d'aide Model Mail .

Lorsque l'utilisateur ouvre le message électronique, il peut suivre le lien et ouvrir le diagramme référencé dans le lien. Il
s'agit d'un mécanisme utile permettant de référencer et d'accéder à des vues dynamiques et en temps réel des
informations modélisation plutôt qu'à une image envoyée dans un document statique. Cette image montre le diagramme
qui serait affiché dans l'outil lorsque le lien est ouvert.

La capacité de relier des éléments de différents domaines modélisation est l'une des grandes forces d' Enterprise Architect
en tant que plate-forme unificatrice pour les équipes et les disciplines, et cela est particulièrement vrai dans la relation

entre la stratégie commerciale et l'ingénierie, et entre le développement logiciel et l'ingénierie. Le résultat est un modèle
cohérent et harmonisé où la possibilité de défauts résultant de coutures entre différentes équipes est considérablement
réduite. Pour plus d'informations, consultez la rubrique d'aide Traceability Window .

Vues

Fondamentalement, un système est conçu, analysé, conçu et construit pour ses parties prenantes. Les ingénieurs système
recueillent les préoccupations et les intérêts des parties prenantes et appliquent l’analyse pour créer des exigences et des
contraintes. Ceux-ci sont utilisés comme entrées pour l’analyse et la conception et avant que le système ne soit livré pour
validation et vérification. Les parties prenantes doivent être capables de visualiser comment leurs intérêts sont pris en
compte à différentes étapes du processus d'ingénierie et cette visualisation peut être fournie par des vues et des points de
vue. Les concepts de point de vue et de vue sont articulés dans la norme ISO-42010 (anciennement IEEE-1471) et la
spécification SysML a été écrite pour être cohérente avec la norme ISO-42010. Il existe un certain nombre de points de
vue couramment utilisés, notamment :
· Opérationnel
· Performance
· Fabrication
· Sécurité
Un point de vue est une prescription permettant de construire une vision qui répondra aux besoins, aux intérêts et aux
préoccupations d’une partie prenante donnée. Une vue est ce que la partie prenante voit d'un point de vue donné et doit
lui permettre de visualiser les parties du système qui les concernent tout en laissant de côté ou en masquant les aspects du
système qui ne les intéressent pas.

En plus du mécanisme formel décrit par la spécification SysML sous la forme d'éléments Vue et Viewpoint, Enterprise

Architect dispose d'une large gamme d'outils pour aider à la création et à la gestion de points de vue, de vues et de
représentations. Il existe plusieurs outils qui peuvent être utilisés pour créer différentes vues des éléments du référentiel ;
il s'agit notamment des Working Ensembles et des Modèle Vues . Ensembles de travail permettent de sauvegarder et de
rouvrir une collection de diagrammes , de matrices, de bibliothèques Modèle et d'autres éléments sous forme d'ensemble,
ce qui est utile lorsque vous travaillez avec différents groupes de parties prenantes. Pour plus d'informations, consultez la
rubrique d'aide Working Sets
Modèle Vues permet de créer des vues d'éléments regroupés quel que soit leur emplacement dans la fenêtre Navigateur .
Il existe également plusieurs outils permettant de masquer ou d'obscurcir des parties d'un diagramme pour le rendre plus
attrayant pour un public particulier. L'apparence des diagrammes peut être modifiée en modifiant l'apparence des
éléments, notamment en utilisant une image, et Filtres de Diagramme peuvent masquer ou masquer des éléments. Pour
plus d’informations, consultez la rubrique d’aide Visual Filters . Le moteur de documentation peut créer des publications
de haute qualité directement à partir du modèle aux formats pdf ou docx. Pour plus d’informations, consultez la rubrique
d’aide Documentation .

Vous aimerez peut-être aussi

Chapitre 7 Architecture Fonctionnelle ADAS
Pas encore d'évaluation
Chapitre 7 Architecture Fonctionnelle ADAS
39 pages
Prise en Main de Caméo
Pas encore d'évaluation
Prise en Main de Caméo
27 pages
Introduction à UML et diagrammes clés
Pas encore d'évaluation
Introduction à UML et diagrammes clés
15 pages
Modélisation UML pour un Système de Restaurant
Pas encore d'évaluation
Modélisation UML pour un Système de Restaurant
21 pages
Ingénieuriedesmodeles
Pas encore d'évaluation
Ingénieuriedesmodeles
60 pages
Analyse UML du Paradigme Orienté Objet
Pas encore d'évaluation
Analyse UML du Paradigme Orienté Objet
29 pages
Introduction au langage UML
Pas encore d'évaluation
Introduction au langage UML
79 pages
Cours UML
Pas encore d'évaluation
Cours UML
63 pages
Model Based Systems Engineering (MBSE) - SysML
Pas encore d'évaluation
Model Based Systems Engineering (MBSE) - SysML
48 pages
Cours UML SysML Diego
Pas encore d'évaluation
Cours UML SysML Diego
51 pages
Introduction au Génie Logiciel
Pas encore d'évaluation
Introduction au Génie Logiciel
68 pages
Introduction au Génie Logiciel et Projets
Pas encore d'évaluation
Introduction au Génie Logiciel et Projets
39 pages
Cours Uml Info 3
100% (1)
Cours Uml Info 3
258 pages
COURS Arbaoui CP P3 2021 Slides
Pas encore d'évaluation
COURS Arbaoui CP P3 2021 Slides
50 pages
Cours UML Par6
Pas encore d'évaluation
Cours UML Par6
12 pages
Résumé Les Neufs Diagrames de SYSML
0% (1)
Résumé Les Neufs Diagrames de SYSML
16 pages
Uml2 PDF
Pas encore d'évaluation
Uml2 PDF
50 pages
Introduction à l'Ingénierie Système et SysML
Pas encore d'évaluation
Introduction à l'Ingénierie Système et SysML
25 pages
MDE Notes
Pas encore d'évaluation
MDE Notes
4 pages
Introduction au Génie Logiciel UML
Pas encore d'évaluation
Introduction au Génie Logiciel UML
25 pages
Cours IDM Chap1, 2-1
Pas encore d'évaluation
Cours IDM Chap1, 2-1
11 pages
1SI A1 Ingénierie - Système SysMl
Pas encore d'évaluation
1SI A1 Ingénierie - Système SysMl
17 pages
Introduction à l'ingénierie logicielle et UML
Pas encore d'évaluation
Introduction à l'ingénierie logicielle et UML
54 pages
Cours7 Initial
Pas encore d'évaluation
Cours7 Initial
51 pages
Les Diagrammes UML (Première Partie)
Pas encore d'évaluation
Les Diagrammes UML (Première Partie)
3 pages
Genie Logiciel
100% (1)
Genie Logiciel
202 pages
Guide UML et PowerAMC pour Concepteurs
Pas encore d'évaluation
Guide UML et PowerAMC pour Concepteurs
42 pages
Introduction à UML 2.0 et modélisation
Pas encore d'évaluation
Introduction à UML 2.0 et modélisation
173 pages
Cours SI Chap3
Pas encore d'évaluation
Cours SI Chap3
30 pages
Introduction à la modélisation UML
100% (1)
Introduction à la modélisation UML
162 pages
Ingénierie Dirigée Par Les Modèles Des Concepts À La Pratique
Pas encore d'évaluation
Ingénierie Dirigée Par Les Modèles Des Concepts À La Pratique
106 pages
Introduction à UML et ses Diagrammes
Pas encore d'évaluation
Introduction à UML et ses Diagrammes
67 pages
Introduction à la Modélisation UML
100% (2)
Introduction à la Modélisation UML
171 pages
Crise du logiciel et ingénierie moderne
Pas encore d'évaluation
Crise du logiciel et ingénierie moderne
6 pages
Notation SysML pour la construction de systèmes
Pas encore d'évaluation
Notation SysML pour la construction de systèmes
20 pages
App 5
Pas encore d'évaluation
App 5
10 pages
Chap 4 Modelisation Metier Avec Uml - 085054
Pas encore d'évaluation
Chap 4 Modelisation Metier Avec Uml - 085054
9 pages
AL
Pas encore d'évaluation
AL
2 pages
1-Diagrammes Des Cas D'utilisation
Pas encore d'évaluation
1-Diagrammes Des Cas D'utilisation
38 pages
Exercices D'application SOA
100% (1)
Exercices D'application SOA
19 pages
Cours-Uml Laurent Audibert
Pas encore d'évaluation
Cours-Uml Laurent Audibert
178 pages
Cours Uml
Pas encore d'évaluation
Cours Uml
178 pages
Définition iDM
Pas encore d'évaluation
Définition iDM
8 pages
Chapitre2 Mpssi1
Pas encore d'évaluation
Chapitre2 Mpssi1
55 pages
Introduction à UML et Modélisation OO
Pas encore d'évaluation
Introduction à UML et Modélisation OO
57 pages
Diagrammes SysML avec Enterprise Architect
Pas encore d'évaluation
Diagrammes SysML avec Enterprise Architect
2 pages
Modélisation UML : Méthodes et Phases
Pas encore d'évaluation
Modélisation UML : Méthodes et Phases
18 pages
V123
Pas encore d'évaluation
V123
293 pages
Rapport de Stge
Pas encore d'évaluation
Rapport de Stge
29 pages
COMILOG Ortega Lettre de Motivation 1
Pas encore d'évaluation
COMILOG Ortega Lettre de Motivation 1
1 page
Explications Chap 1 - 19 Mars
Pas encore d'évaluation
Explications Chap 1 - 19 Mars
51 pages
Licence en Kinesitherapie 2025
Pas encore d'évaluation
Licence en Kinesitherapie 2025
2 pages
Outils ARS et Carbures : Guide Complet
Pas encore d'évaluation
Outils ARS et Carbures : Guide Complet
7 pages
Exam 19 20 Ensam Copie
Pas encore d'évaluation
Exam 19 20 Ensam Copie
15 pages
S Sciences Ingenieur 2018 Centres Etrangers Sujet Officiel
Pas encore d'évaluation
S Sciences Ingenieur 2018 Centres Etrangers Sujet Officiel
28 pages
SI12 CorrecExos
Pas encore d'évaluation
SI12 CorrecExos
53 pages
Projet MEF UIC 25
Pas encore d'évaluation
Projet MEF UIC 25
2 pages
Chapitre 1 (2) - Merged
Pas encore d'évaluation
Chapitre 1 (2) - Merged
78 pages
Correction TD 1 de Révision TS
Pas encore d'évaluation
Correction TD 1 de Révision TS
11 pages
Cours MAtériaux de L'ingénieur - Partie 1
100% (1)
Cours MAtériaux de L'ingénieur - Partie 1
93 pages
Transformation de Fourier: Non P Eriodique Continu
Pas encore d'évaluation
Transformation de Fourier: Non P Eriodique Continu
13 pages
Projet MEF UIC 25
Pas encore d'évaluation
Projet MEF UIC 25
2 pages
Série de TD Pour Révision TS: Exercice 01
Pas encore d'évaluation
Série de TD Pour Révision TS: Exercice 01
2 pages
TD 1 Et 2
Pas encore d'évaluation
TD 1 Et 2
15 pages
Travaux Dirigés - Séquence N°2: Exercice 1
Pas encore d'évaluation
Travaux Dirigés - Séquence N°2: Exercice 1
4 pages
SysML : Analyse fonctionnelle d'un radioréveil
Pas encore d'évaluation
SysML : Analyse fonctionnelle d'un radioréveil
6 pages
Exercices sur la traction des matériaux
Pas encore d'évaluation
Exercices sur la traction des matériaux
3 pages
Étude et conception d'une éolienne
Pas encore d'évaluation
Étude et conception d'une éolienne
102 pages
TD Outil
Pas encore d'évaluation
TD Outil
2 pages
Corrigé Bac 2015 : Physique-Chimie S
Pas encore d'évaluation
Corrigé Bac 2015 : Physique-Chimie S
6 pages
Cours1 Grafcet
Pas encore d'évaluation
Cours1 Grafcet
114 pages
Introduction à la Mécanique des Fluides
Pas encore d'évaluation
Introduction à la Mécanique des Fluides
70 pages
Mesures et Incertitudes en Physique
Pas encore d'évaluation
Mesures et Incertitudes en Physique
11 pages
TDN 4. Sous Espaces Vectoriels de R - Familles Libres, G en Eratrices. Notion de Dimension
Pas encore d'évaluation
TDN 4. Sous Espaces Vectoriels de R - Familles Libres, G en Eratrices. Notion de Dimension
3 pages
Composantes Du Système D'information Marketing
Pas encore d'évaluation
Composantes Du Système D'information Marketing
27 pages
Business Intelligence (BI) : Chabamouna - Mustapha@univ-Blida - DZ
Pas encore d'évaluation
Business Intelligence (BI) : Chabamouna - Mustapha@univ-Blida - DZ
35 pages
UDEMY Hadoop BigData Pascal Lochert
Pas encore d'évaluation
UDEMY Hadoop BigData Pascal Lochert
316 pages
Architecture WMI
Pas encore d'évaluation
Architecture WMI
3 pages
Apache Kafka
Pas encore d'évaluation
Apache Kafka
34 pages
Rib - 2025 3 1 - 15 19 46
Pas encore d'évaluation
Rib - 2025 3 1 - 15 19 46
26 pages
Technicien Réseaux et Bases de Données
Pas encore d'évaluation
Technicien Réseaux et Bases de Données
1 page
Introduction aux Systèmes de Gestion de Bases de Données
Pas encore d'évaluation
Introduction aux Systèmes de Gestion de Bases de Données
20 pages
INFO TCD Fin Trim2 CBCG
Pas encore d'évaluation
INFO TCD Fin Trim2 CBCG
3 pages
Brochure TopKapi - FR
Pas encore d'évaluation
Brochure TopKapi - FR
6 pages
La Triade CIA
Pas encore d'évaluation
La Triade CIA
6 pages
SEC Dictionnaire LCD Oracle PDF
Pas encore d'évaluation
SEC Dictionnaire LCD Oracle PDF
7 pages
Introduction aux bases de données actives
Pas encore d'évaluation
Introduction aux bases de données actives
8 pages
Analyse des incidents de cybersécurité
Pas encore d'évaluation
Analyse des incidents de cybersécurité
40 pages
Introduction aux bases de données relationnelles
Pas encore d'évaluation
Introduction aux bases de données relationnelles
122 pages
Présentation Du Big Data
100% (1)
Présentation Du Big Data
38 pages
Devoir de Contrôle N°2
Pas encore d'évaluation
Devoir de Contrôle N°2
4 pages
Supports Cours Bases de Donnees
Pas encore d'évaluation
Supports Cours Bases de Donnees
6 pages
Procédures de Test de Contrôle
Pas encore d'évaluation
Procédures de Test de Contrôle
13 pages
Système d'Information Géographique en Hydrogéologie
Pas encore d'évaluation
Système d'Information Géographique en Hydrogéologie
77 pages
Introduction aux Bases de Données Relationnelles
Pas encore d'évaluation
Introduction aux Bases de Données Relationnelles
27 pages
Cours: Bases de Données et MERISE
Pas encore d'évaluation
Cours: Bases de Données et MERISE
162 pages
Test en ligne AWS - Promo 3
Pas encore d'évaluation
Test en ligne AWS - Promo 3
4 pages
MODULE 1 Introduction Aux Bases de Donnees
Pas encore d'évaluation
MODULE 1 Introduction Aux Bases de Donnees
6 pages
TDR - Digitalisation Des Services Municipaux de La Mairie d'ANEHO
Pas encore d'évaluation
TDR - Digitalisation Des Services Municipaux de La Mairie d'ANEHO
9 pages
Introduction aux SGBD avec Access
Pas encore d'évaluation
Introduction aux SGBD avec Access
44 pages
Prise de décision en entreprise au Congo
Pas encore d'évaluation
Prise de décision en entreprise au Congo
12 pages
Referentiel Bts Sam Cse-2
Pas encore d'évaluation
Referentiel Bts Sam Cse-2
90 pages
Cours 3 BD Indus
Pas encore d'évaluation
Cours 3 BD Indus
25 pages
TD Info
Pas encore d'évaluation
TD Info
24 pages