UML Tutoriel - La partie 2

Nous avons établi dans la Partie 1 que l’UML est une langue pour spécifier les artefacts et les interactions d’un système logiciel. Nous avons aussi vu qu’il traite 6 domaines majeurs - du modèle de Cas d’Utilisation par des modèles dynamiques et logiques au modèle de déploiement physique final. - et ces mécanismes d’extension ont été inclus pour tenir compte de compléments spécialisés à la notation modèle.

Ainsi... Comment utilisez-vous l’UML ?

L’UML est typiquement utilisé comme une partie d’un processus de développement logiciel , avec le support d’approprié l’outil de CAS, définir les exigences, les interactions et les éléments du système logiciel proposé. La nature exacte du processus dépend de la méthodologie de développement utilisée. Un processus d’exemple pourrait regarder quelque chose comme la chose suivante:

1. Un capturé Modèle de Processus Métier sera utilisé pour définir les activités économiques de haut niveau et les processus, qui arrivent dans une organisation. Et fournir une base pour le modèle de Cas d’Utilisation. Le Modèle de Processus Métier capturera typiquement plus, qu’un système logiciel mettra en ouvre (c’est-à-dire. Il inclut le manuel et d’autres processus).
2. Liez un Modèle de Cas d’Utilisation avec le Modèle de Processus Métier définir exactement quelle fonctionnalité vous avez l’intention de fournir de la perspective d’utilisateur de métiers. Comme chaque Cas d’Utilisation est ajouté, créer un lien clair des processus métier appropriés au Cas d’Utilisation (c’est-à-dire, une connexion de réalisation). Cette cartographie expose clairement quelle fonctionnalité le nouveau système fournira pour respecter les exigences opérationnelles décrits dans le modèle de processus. Il assure aussi que les Cas d’Utilisations existent sans une objective.
3. Affinez les Cas d’Utilisation - incluent des Exigences, des Contraintes, l’Évaluation de Complexité, des Notes et des Scénarios. Cette information décrit clairement ce que le Cas d’Utilisation fait. La façon dont il est exécuté et les contraintes sur son exécution. Assurez-vous que le Cas d’Utilisation respecte toujours aux exigences de Processus Métier. Inclure la définition de tests de système pour chaque Cas d’Utilisation pour définir les critères acceptante pour chaque Cas d’Utilisation. Inclure aussi quelques scripts de tests d’acceptation des utilisateurs pour définir comment l’utilisateur va tester cette fonctionnalité et ce que les critères d’acceptation sont.
4. De les entrées et les sorties du Modèle de Processus Métier et les détails des Cas d’Utilisation, commencez à construire un modèle de domaine (objets métiers de haut niveau), les Diagrammes de Séquence, Diagrammes de Collaboration et des modèles d’Interface Utilisateur. Ceux-ci décrivent ’les choses’ dans le nouveau système, la façon dont ces choses interagissent et l’Interface Utilisateur utilisera pour exécuter des Scénarios d’Utilisation.
5. A partir du modèle de domaine, le modèle d’interface utilisateur et les diagrammes de scénarios créer le Modèle de Classe. Ceci est une spécification précise des objets dans le système, les données ou les attributs et leur comportement ou opérations. Objets de domaine peuvent être extraites dans des hiérarchies de classes en utilisant l’héritage. Les messages de diagramme de scénario seront généralement mapper à ses opérations de classe. Si un cadre existant ou de la conception existante doit être utilisé, il peut être possible d’importer des éléments de modèle existants pour pour l’utilisation dans le nouveau système. Pour chaque classe définit des tests unitaires et tests d’intégration de tester en profondeur i) que les fonctions de classe comme spécifié à l’interne et que ii) la classe interagit avec d’autres classes liées et des composants comme attendu.
6. Comme le Modèle de Classe se développe, il peut être fait irruption des paquetages et des composants discrets. Un composant représente un morceau déployable de logiciel, qui recueille le comportement et les données d’une ou plusieurs classes et expose une interface stricte à d’autres consommateurs de ses services. Donc, à partir du Modèle de Classe d’un Modèle de Composant est conçu pour définir le paquetage logique de classes. Pour chaque composant définir des tests d’intégration pour confirmer que l’interface du composant répond à la spécification donné par rapport aux autres éléments logiciels.
7. Concurrent avec le travail, que vous avez déjà fait, des exigences supplémentaires devraient avoir été capturées et documentées. Par exemple - les Exigences Non Fonctionnelles, les Exigences de Performance, les Exigences de Sécurité, les Responsabilités, les Plans de Libération & etc. Rassemblez ceux dans le modèle et tenez à jour comme le modèle mûrit.
8. Le Modèle de Déploiement définit l’architecture physique du système. Ce travail peut être commencé tôt pour capturer les caractéristiques de déploiement physiques - ce matériel, systèmes d’exploitation, les capacités du réseau, des interfaces et des logiciels de soutien fera le nouveau système. Où il sera déployé et quels paramètres appliquer à la reprise après sinistre, la fiabilité, des sauvegardes et le support. Comme le modèle développe l’architecture physique sera mis à jour pour refléter le système actuel est proposé.
9. Construire le système: Prenez les pièces discrètes du modèle et assignez à un ou plusieurs développeurs. Dans un Cas d’Utilisation conduit construisent ceci aura l’intention d’assigner un Cas d’Utilisation en équipe de développement. Leur faisant construire les écrans, objets métiers, des tables de base de données, et des composants connexes nécessaires pour exécuter ce Cas d’Utilisation. Comme chaque Cas d’Utilisation est construit il devrait être accompagné par l’unité complétée, l’intégration et des tests de système. Une accumulation de composants entraîné peut voir composants logiciels discrets affectés aux équipes de développement pour la construction.
10. Construire le système: Prenez les pièces discrètes du modèle et assignez à un ou plusieurs développeurs. Dans un Cas d’Utilisation conduit construisent ceci aura l’intention d’assigner un Cas d’Utilisation en équipe de développement. Leur faisant construire les écrans, objets métiers, des tables de base de données, et des composants connexes nécessaires pour exécuter ce Cas d’Utilisation. Comme chaque Cas d’Utilisation est construit il devrait être accompagné par l’unité complétée, l’intégration et des tests de système. Une accumulation de composants entraîné peut voir composants logiciels discrets affectés aux équipes de développement pour la construction.
11. Mettre à jour et d’affiner le modèle comme travail produit - toujours évaluer l’impact des changements et des améliorations apportées aux modèles de travail postérieur. Utilisez une approche itérative de travailler à travers le design en morceaux discrets, toujours évaluer la version actuelle, les exigences en avant et n’importe quelles découvertes qui émergent pendant le développement.
12. Livrer le logiciel complet et testé dans un environnement de production de test. Si une livraison progressive est en cours, cette migration des téléchargements construit à partir de test pour la production peut se produire plusieurs fois au cours de la vie du projet.

Note: que le processus ci-dessus est nécessairement le dossier dans la description, laisse beaucoup de non-dits et peut ne pas être la façon dont vous travaillez ou suivez le processus, que vous avez adopté. Il est donné comme un exemple de la façon dont l’UML peut être utilisé pour supporter un projet de développement logiciel.