1. Introduction

Depuis sa standardisation par l’Object Management Group (OMG) en 1997, l’Unified Modeling Language (UML [RTF 99]) s’impose rogressivement comme un standard de fait pour la modélisation à objets de systèmes, qu’ils soient logiciels, matériels ou organisationnels. La notation UML est suffisamment complète pour pouvoir remplacer ou compléter les notations à objets l’ayant précédée, et sa souplesse permet de l’utiliser pour modéliser toutes les facettes d’un système, depuis la phase d’identification des besoins jusqu’au test et au déploiement final du système opérationnel. Bien sûr, plus un système est complexe et plus la nécessité de le valider et de le tester se fait pressante. Tel est le cas notamment des systèmes répartis, dans lesquels la concurrence et l’asynchronisme rendent la compréhension du système particulièrement ardue. L’utilisation de méthodes formelles est un moyen efficace d’améliorer la fiabilité et la qualité des systèmes concurrents. Le secteur des télécommunications est particulièrement en pointe dans ce domaine, grâce aux diverses techniques de descriptions formelles ayant été développées pour faire face à ces exigences de qualité. Ces techniques sont basés sur des notations telles que Estelle, Promela, SDL [CCI 87] ou LOTOS [ISO 85], ayant une sémantique précise et pour lesquelles l’utilisateur dispose d’outils permettant d’aborder la vérification automatique.

2. UML dans le cycle de développement logiciel

2.1.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 niveaux d’abstraction (analyse, conception), chacun donnant lieu à un modèle particulier. Chaque modèle contient une description du système proprement dit, ainsi qu’une description de son environnement, notamment les acteurs qui interagissent avec le systè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 considérerons que la spécification UML ne contient qu’un système, vu à un seul niveau d’abstraction donné (donc un seul modèle).

2.2.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 de cas d’utilisation et  l’opérations portant 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ée qui décrit comment les cas d’utilisation et les opérations globales 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.

2.3.Identification des besoins
La première étape de la modélisation consiste généralement à déterminer précisé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 possible 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

étendentl’utilisation nominale).

2.4.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..

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Méthodes formelles avec UML (219 KO) (Cours PDF)