Modélisation du comportement du système

Avant d’introduire des diagrammes, UML spécifie en premier lieu des concepts permettant d’exprimer des caractéristiques dynamiques. On fait la distinction entre les actions, les activités, les états, les interactions et les cas d’utilisation. Nous allons passer brièvement en revue leur utilisation pendant le processus de modélisation et indiquer les liaisons effectuées avec le modèle structurel pour maintenir la cohérence globale du modèle. L’objectif ici est de pouvoir détailler le comportement de tous les éléments décrits de façon statique dans la structure du système et de montrer comment ils interagissent pour réaliser les fonctions attendues de l’ensemble. Les actions. Comme précisé dans le standard, une action représente l’unité élémentaire des spécifications comportementales d’un système. Elle possède un ensemble d’entrées et active ou envoie un certain nombre de sorties en fonction du traitement qu’elle effectue. Tout le travail de description du comportement des éléments structurels va donc consister à organiser ces actions au sein de diagrammes de comportement de façon à produire le comportement dynamique souhaité pour l’élément étudié. Les activités. Un peu à l’image des structures composites, une activité contient un ensemble d’actions reliées entre elles qui permettent de réaliser le comportement global de l’activité, sa réaction aux sollicitations extérieures, l’envoi ou le stockage d’informations. Les activités sont décrites dans des diagrammes d’activité. Lorsqu’une; activité est exécutée, les actions internes de l’activité vont être exécutées une ou plusieurs fois selon la façon dont elles sont connectées entre elles et avec les entrées et les sorties de l’activité parente. Les partitions. Elles permettent d’intégrer un niveau de description supérieur en regroupant les actions ou activités qui ont des caractéristiques communes par exemple si elles sont réalisées dans un même contexte particulier. Les partitions sont très pratiques, par exemple pour modéliser un flux d’information entre différents services ou sites géographiques d’une société. On partitionne alors selon les services et on intègre les actions de chacun en définissant les flux de contrôle et les flux d’objets correspondant aux échanges entre les différents services (par exemple envoi de mails dans le cas d’un flux d’objets, ou ordre simple dans un flux de contrôle). Les interactions. Alors que les activités et les actions vont souvent être utilisées pour décrire le comportement interne d’un élément structurel, les interactions ont pour vocation de permettre à l’utilisateur de représenter les échanges et les sollicitations qui vont être effectués entre ces éléments structurels. De plus, les diagrammes proposés pour spécifier ces interactions vont permettre d’introduire des contraintes de séquencement entre ces interactions pour que la description du comportement des échanges entre les objets soit précisément modélisée. 40 Il existe cinq diagrammes permettant la modélisation des interactions d’un système, le diagramme de séquence (sequence diagram), le diagramme de vue générale des interactions (interactions overview diagram), le diagramme de communication (communication diagram), le diagramme temporel (timing diagram) et le diagramme de tables d’interaction (interaction tables). Il n’est pas obligatoire de tous les utiliser dans une même spécification; le choix sera à effectuer en fonction des attentes de l’utilisateur au niveau de la forme de représentation et du type de comportement dynamique qu’il veut décrire [Mul 00].

Rational Unified Process (RUP)

Historique

Le processus unifié est le résultat de la fusion des méthodes Objectory d’Ivar Jacobson, Booch de Grady Booch et OMT de James Rumbaugh, enrichi de nombreux apports issus des travaux d’élaboration du standard UML. La figure 2.13 retrace la succession des produits qui en sont issus, depuis le processus Objectory, dont la première version est sortie en 1987, jusqu’au Rational Unified Process (sortie en 1998) en passant par le Rational Objectory Process (1997). Le Rational Unified Process a évolué au fil des années pour finir par incarner l’expérience de milliers de projets dans tous les domaines imaginables. Historiquement, le RUP est le successeur direct de Rational Objectory Process (version 4) (Figure 2.13). 

Le RUP et le Développement Itératif

La plupart des équipes de développement logiciel continuent à appliquer un processus en cascade, dans lequel chaque phase observe une séquence stricte : spécification, analyse et conception, implémentation et intégration, et enfin les tests. On rencontre couramment une méthode en cascade modifiée, qui ajoute des boucles de rétroaction à ce flux global. De tell d’inactiv ont ten sérieuse démarc itération (spécific Elle a u partielle dans les es approch vité, et diffè ndance à êt es menaces he itérative, n compren cation, analy un ensemble e du systèm s précédente Figure 2.13 es forcent rent les test re plus diffi par rapport , autrement nd la plup yse, concept e d’objectifs me final. Cha es, le produit 3 Historique des memb s en fin de c iciles et plu t aux délais dit une suite art des di ion, implém s bien défini aque itératio t final évolue e du RUP [K res clés de cycle de vie d s coûteux à de livraison e d’étapes in isciplines d entation, etc i et produit on successive e et se raffine Kru 00] e l’équipe à du projet, mo à résoudre. n. A l’invers ncrémentale du développ c.), comme l une implém e s’appuyan e jusqu’à ce à de longue oment où le Ils constitue e, le RUP a es, ou itératio pement, sin le montre la mentation fo t sur le trav qu’il soit par 41 es périodes s problèmes ent ainsi de pplique une ons. Chaque non toutes figure 2.14. onctionnelle vail effectué rachevé.