Présentation
Dans ce guide d'utilisation de l'outil, les étapes suivantes sont exécutées pour chaque cas d'utilisation à concevoir
dans l'itération en cours :
Informations supplémentaires sur l'outil
Les éléments de conception significatifs du point de vue architectural peuvent être consignés dans une vue logique
séparée, qui est maintenue au fur et à mesure que les éléments de conception sont identifiés. La recommandation
générale est d'utiliser des packages de <<perspective>>. Voir Instructions relatives aux structures de modèles pour RSx pour plus d'informations
sur ce sujet.
Les caractéristiques des événements, aussi appelés déclencheurs dans UML 2.0, doivent être consignées selon les besoins
pour identifier les éléments de conception qui les traitent. Ces informations peuvent être consignées de manière
informelle, par exemple dans un document séparé, au lieu de faire partie d'un modèle.
Les événements de communication asynchrone peuvent être modélisés sous forme de signaux pour spécifier les données
contenues ou les relations entre les signaux, comme par exemple la généralisation. Les sous-étapes suivantes expliquent
comment modéliser les signaux :
-
Créez des diagrammes de classes selon les besoins. Voir
Adding Class Diagrams to Model Elements (Ajout de
diagrammes de classes aux éléments de modèle).
-
Ajoutez des signaux. Voir
Creating and Modifying Class Diagrams (Création et modification des diagrammes de classes).
-
Ajoutez une brève description à chaque élément de conception. Voir
Documenting Model Elements (Documentation des éléments de
modèle).
-
Ajoutez des relations de généralisation entre les signaux, si cela est utile.
Pour plus d'informations sur les diagrammes de classes, voir Modeling Static Structure by Using Class Diagrams
(Modélisation de la structure statique à l'aide de diagrammes de classes).
Les éléments de conception sont généralement créés des trois manières suivantes :
-
Extension d'un pattern
-
Modélisation
-
Codage et génération de code
Ces approches sont expliquées dans les sections ci-après.
Extension d'un pattern
Un pattern est un type spécifique de transformation optimisé pour une élaboration interactive, par morceaux,
principalement dans un seul métamodèle, de niveau d'abstraction équivalent, et souvent au sein du même modèle. Pour
plus d'informations, Voir Mécanismes
d'analyse.
Voir Authoring Patterns
(Création de patterns) et Applying Patterns (Application de patterns) dans l'aide en ligne.
Modélisation
Cet outil prend en charge une approche guidée par modèle pour le développement logiciel (Voir Développement guidé par modèle et architecture guidée par modèle et Mécanismes d'analyse), dans laquelle vous construisez un ensemble de modèles qui
inclut un modèle de conception et génère des artefacts d'implémentation comme le code 3GL, les descripteurs etc. Ces
derniers sont dérivés à partir du modèle de conception à l'aide des transformations. Dans certains cas, les
transformations qui génèrent les codes prendront comme entrée les classes d'analyse, mais ils seront principalement
guidés par les éléments de conception. Pour plus d'informations, voir : Applying Transformations (Application des
transformations).
Dans une approche de développement traditionnelle, vous créez des diagrammes de classes dans le modèle de conception
afin de consigner les éléments de conception. Si vous décidez de maintenir les classes d'analyse, vous souhaiterez
peut-être établir une traçabilité en utilisant des dépendances de "trace" par rapport aux classes d'analyse.
-
Créez des diagrammes de classes selon les besoins. Voir
Adding Class Diagrams to Model Elements (Ajout de
diagrammes de classes aux éléments de modèle).
-
Ajoutez des sous-systèmes et des classes. Voir
Creating and Modifying Class Diagrams (Création et
modification de diagrammes de classes).
-
Ajouter une brève description à chaque élément de conception. Voir
Documenting Model Elements (Documentation des éléments de
modèle).
-
(facultatif) Ajoutez une traçabilité aux classes d'analyse, en utilisant des dépendances de "trace" de vos éléments
de conception aux classes d'analyse sur lesquelles elles se basaient. Voir
Abstraction Relationships in UML Modeling (Relations
d'abstraction dans la modélisation UML).
-
Organisez les éléments de conception en sous-systèmes et en packages. Consultez le livre blanc Instructions relatives aux structures de modèles pour RSx.
Pour plus d'informations sur les diagrammes de classes, Voir Modeling Static Structure with Class Diagrams (Modélisation
de la structure statique avec des diagrammes de classes).
Code et génération de code
Remarque : certaines fonctions de l'outil mentionnées dans cette section ne sont pas prises en charge dans RSM.
Une approche différente est l'approche orientée code : le code est le moteur principal, soit parce qu'il existe déjà
(par exemple dans un cycle de développement déjà existant), soit parce que l'équipe doit traiter des risques liés au
projet en codant un prototype pour valider un concept complexe. Dans le cadre de la prise en charge de la
reconnaissance et de la récupération de l'architecture (voir les instructions relatives à la reconnaissance, à l'analyse et au contrôle de
l'architecture), la fonction de l'outil qui permet de visualiser le code peut remplir automatiquement les
diagrammes de rubrique, comme la structure de package, les éléments internes de classe, les arborescences d'héritage et
les collaborations. L'objectif de cette tâche n'est pas seulement de comprendre le code existant, mais également
d'extraire un modèle de l'application, qui peut être utilisé en relation avec d'autres modèles spécifiques pour générer
la nouvelle version de l'application, en utilisant des transformations.
Après avoir généré ou composé un diagramme UML de code existant, plusieurs options s'offrent à vous pour tirer parti
des représentations de code dans le cadre de votre modèle de conception :
-
Recueillez une représentation UML d'un élément de code dans votre modèle de conception en tant que véritable
élément de modèle sémantique. Cela crée un nouvel élément UML dans le modèle de conception qui n'a pas de lien avec
l'élément de code recueilli. Il a cependant des propriétés (d'attributs et d'opérations d'instance) qui reflètent
les propriétés de l'élément de code recueilli. Dans la mesure où il s'agit d'un véritable élément sémantique UML,
on peut générer un nouveau code à partir de cet élément (c'est-à-dire qu'il a le même statut dans le modèle de
conception que tout élément de conception défini par le processus de modélisation inédit décrit ci-dessus.)
-
Appliquez une référence visuelle à l'élément de code dans un diagramme situé dans le cadre de votre modèle de
conception. Cette référence n'a pas de signification sémantique dans le modèle de conception et aucun nouveau code
ne sera généré à partir d'elle. Il ne s'agit, comme son nom l'indique, que d'une référence au véritable élément de
code. Cependant, vous pouvez dessiner des relations entre la référence de code et les éléments de conception
sémantiques dans le modèle de conception. Ces relations ont une signification sémantique dans le modèle de
conception, et elles ont une influence sur la génération de code.
Pour plus d'informations, consultez la rubrique Modeling Static Structure with Class Diagrams (Modélisation
d'une structure statique avec des diagrammes de classes) dans l'aide en ligne.
Les étapes suivantes s'appliquent aux systèmes à forte granularité :
-
Pour chaque sous-système, identifiez un ensemble d'interfaces potentielles. Si vous avez précédemment créé des
classes d'analyse et effectué des réalisations de cas d'utilisation de niveau d'analyse, vous devez à présent
choisir la façon dont les opérations doivent être regroupées et décrites en tant qu'interfaces de composants ou de
services spécifiques. Ajoutez des interfaces à un diagramme de composants existant ou créez des nouveaux diagrammes
de composants si nécessaire. Voir
Adding Interfaces to Modeling Diagrams (Ajout d'interfaces aux diagrammes de modélisation).
-
Ajoutez des dépendances d'interface.
-
Mappez les sous-systèmes aux interfaces en ajoutant une relation de réalisation du sous-système à l'interface.
-
Documentez l'interface en incluant le comportement requis. Voir
Documenting Model Elements (Documentation des éléments de
modèle).
-
Ajoutez des opérations à l'interface. Voir
Adding Operations to Classifiers in Diagrams (Ajout
d'opérations aux discriminants dans les diagrammes).
-
Ajoutez une description à chaque opération. Voir
Documenting Model Elements (Documentation des éléments de
modèle).
-
Ajoutez des paramètres à chaque opération. Voir
Adding Operations to Classifiers in Diagrams (Ajout
d'opérations aux discriminants dans les diagrammes).
-
Organisez les interfaces en packages.
Dans UML 2.0, les sous-systèmes sont des composants de grande taille et doivent être représentés comme des classes
structurées avec des ports et/ou des interfaces. Voir les rubriques de l'aide en ligne spécifiques à UML 2.0.
La modélisation de capsule et de protocole n'est pas prise en charge.
Tutoriels :
-
Apply a Pattern
(Appliquer un pattern)
Exemples :
-
Patterns - Simple
UML Model (Patterns - Modèle UML simple)
|