Support de cours les méthodes formelles avec UML, tutoriel & guide de travaux pratiques UML en pdf.

UML dans le cycle de développement logiciel

Modélisation d’un système de contrôle aérien
Dans cette section, nous allons présenter comment un système se modélise en UML. La notation UML sera introduite progressivement lors de la présentation. Afin d’illustrer concrètement notre propos, nous avons choisi de modéliser un système de contrôle aérien (ATC), qui servira de cas d’étude tout au long de cet article.
Un tel système peut être modélisé selon plusieurs points de vue ou à divers ni-veaux d’abstraction (analyse, conception), chacun donnant lieu à un modèle particu-lier. Chaque modèle contient une description dusystème proprement dit, ainsi qu’une description de son environnement, notamment les acteurs qui interagissent avec le sys-tème. Si le système est complexe, il est possible de décomposer hiérarchiquement un modèle en sous-modèles et un système en sous-systèmes. Pour simplifier, nous consi-dérerons que la spécification UML ne contient qu’un système, vu à un seul niveau d’abstraction donné (donc un seul modèle).
Spécification extérieure et détaillée d’un (sous-)système
La description d’un (sous-)système se divise en deux parties complémentaires :
Une partie spécification vis-à-vis de l’extérieur qui décrit ce que le système doit être capable de faire en termes decas d’utilisation et d’ opérationsportant sur le sous-système dans sa globalité. Les concepts manipulés sont représentés par des classes ou des types UML.
Une partie détailléequi décrit comment les cas d’utilisation et les opérations glo-bales sont réalisés au sein du sous-système. En général, un sous-système est réalisé par un ensemble d’objets coopérants entre eux, et toute opération sur le sous-système se traduit par un ensemble d’opérations implicant les objets qui le composent. La partie détaillée comportera donc aussi des classes (qui raffinent les classes de la partie spécification) et les machines d’états associées, ainsi que des collaborations et interactions explicitant leur comportement.
Identification des besoins
La première étape de la modélisation onsistec généralement à déterminer préci-sément les besoins des utilisateurs du système. Pour ce faire, UML propose les cas d’utilisations, hérités de la méthode OOSE. Chaque utilisation possible du système se traduit par une ellipse etiquetée avec le nom du cas d’utilisation, à laquelle est connecté le ou les acteurs concernés par cette interaction avec le système. Il est pos-sible de raffiner les cas d’utilisation : une action complexe peut être réalisée par une combinaison d’actions plus simples (on dit que le cas d’utilisation complexe inclut les cas plus simples). Une action alternative ou exceptionnelle peut aussi avoir lieu au cours d’une utilisation complexe si certaines conditions sont remplies (on dit alors que les cas alternatifs ou exceptionnels étendent l’utilisation nominale).
Si l’on souhaite tendre vers plus de rigueur, il est possible de compléter cette vi-sion graphique des besoins par l’utilisation pertinente de pré et post conditions ex-primées textuellement. UML fournit à cette fin un langage dédié : l’Object Constraint Language (OCL) [WAR 98]. OCL est un langage ensembliste permettant d’écrire des contraintes sous forme d’expressions pouvant référencer les entités définies dans la spécification UML. Ces contraintes textuelles définissent le contrat qui lie le système aux acteurs présents dans son environnement [MEY 92].
Le système et son environnement : vue statique
Les diagrammes de classes de UML présentent la structure statique du système et de son environnement. Y figurent la signature des classes des objets impliqués, les relations d’héritage éventuelles entre classes, ainsi que les associations qui les unissent. Les classes dont le bord est plus épais signalent des objets actifs.
Dans la figure 2, le sous-système représentant l’ATC dans sa globalité a été éclaté, laissant apparaitre la structure interne de celui-ci. La classe FlightPlan représente les plans de vol pré-établis des différents avions. La classeFlight représente les vols sous la responsabilité de cet ATC, l’attributcallsign permettant de faire le lien avec le plan de vol. La classe FlightPlanManager représente les gestionnaires de plans de vol. Enfin, la classe ControllerWorkingPosition représente la partie du système chargée de coordonner les informations provenant des radars et des controlleurs aé-riens. L’environnement est modélisé par trois acteurs qui peuvent interagir avec l’ATC en échangeant des messages avec lui : L’acteurcontroller représente le controleur aérien, l’acteur PTGfacade représente le système radar fournissant la position des avions dans l’espace aérien de l’ATC, et enfin le CCGFacade représente un autre ATC.

……….