Jean-Marc CIEUTAT Enseignant-Chercheur ESTIA/LIPSI Processus unifié de développement orienté objet de logiciels : Utilisation du langage de modélisation unifié (UML : Unified Modeling Language) Jean-Marc CIEUTAT Enseignant-Chercheur ESTIA/LIPSI

Plan À quoi sert une méthode de développement de logiciels ? Les objets et les classes La genèse d'un standard : UML La phase d'analyse : Les cas d'utilisation Les diagrammes de séquence Les diagrammes de collaboration Les diagrammes de classes Les diagrammes d'états-transitions

Pourquoi une méthode de développement de logiciels ? Optimisant Encadré Défini Reproductible Initial « Une méthode est une démarche reproductible permettant d’obtenir des résultats fiables » Le Capability Maturity Model (CMM) défini par le Software Engineering Institute (SEI)

Pourquoi l’approche objet ? Représentatif de la réalité Construction itérative (évolutif) Réutilisation (effort de codage et de tests en moins) Simplicité (nombre d’instructions par méthode)

Le cycle de vie itératif Codage Tests Conception n fois Analyse Grâce à la programmation orientée objet, on ajoute des propriétés aux classes déjà introduites, ou on ajoute de nouvelles classes, sans avoir à modifier l'existant

L’approche orientée objet Illustration de Jean-Marc Estay (IMA)

Les objets et les classes Le terme Orienté Objet signifie l'organisation du logiciel en un ensemble d'objets incorporant à la fois les structures de données et le comportement. Alors que la programmation conventionnelle n'établit qu'une faible connexion entre structure de données et comportement. C'est la classe qui sert à regrouper sous un même terme générique les objets partageant la même structure de données et le même comportement. On dit qu'un objet est une instance d'une classe. La classe est séparée en deux parties : la spécification de la classe qui décrit le domaine de définition et les propriétés des instances de la classe la réalisation de la classe qui décrit comment la spécification est réalisée

Que sont les objets ? Les objets du monde réel nous entourent ; ils naissent, vivent et meurent. En orienté objet, ils sont alloués, changent d'états et se comportent en conséquence, et sont désalloués. Ce sont les instances des classes. Les objets informatiques définissent une représentation simplifiée des entités du monde réel. Ils peuvent représenter des entités concrètes (avec une masse), et même des êtres vivants, ou des entités abstraites (concept).

Les objets sont des abstractions Une abstraction est un résumé, un condensé qui met en avant les caractéristiques essentielles et qui dissimulent les détails. Les caractéristiques essentielles d'un objet sont celles qui sont précisées lors de la spécification de la classe dont il est une instance. Les détails, qui sont les détails d'implémentation, sont précisés au moment de la définition des opérations de la classe. Une abstraction se définit par rapport à un point de vue. Quel sont les utilisateurs en présence et quel est leur point de vue ?

Exemples de caractéristiques Pour une voiture : la marque, la puissance, la couleur, le nombre de places assises, … Le point de vue est exprimé par qui ? Le propriétaire, le mécanicien, le vendeur, …

Des caractéristiques aux attributs et aux méthodes Approche fonctionnelle : Créer une structure qui représente un nombre complexe Créer une fonction qui retourne un complexe à partir de sa partie imaginaire et de sa partie réelle passées en arguments Créer une fonction qui additionne deux nombres complexes ... Approche objet : Créer une classe NombreComplexe qui contient : . Ses attributs : partie réelle et partie imaginaire . Ses méthodes : création à partir de sa partie réelle et de sa partie imaginaire, s’additionne à un autre nombre complexe, ...

Du type abstrait à la classe La classe Point La classe Vecteur La classe Polygone La classe Pile La classe File ...

Les caractéristiques fondamentales des objets L'identité L'état Le comportement

L'identité Chaque objet a sa propre identité ; deux objets sont distincts même si toutes les valeurs de leurs attributs sont identiques. Cela se comprend aisément puisque la place mémoire occupée par chaque objet est distincte. Pour reconnaître un objet et lever toute ambiguïté, on utilise, en général, un identifiant particulier : notre numéro de sécurité sociale par exemple, le numéro de la plaque d'immatriculation, une clé utilisée dans une base de données, …

L'état et le comportement Les attributs d'un objet peuvent contenir différentes valeurs. Ce sont les différents états que peut prendre l'objet. Le comportement regroupe toutes les compétences d'un objet, sous la forme d'opérations. C'est l'ensemble des actions et des réactions d'un objet. Avion en vol Atterrir L'état et le comportement sont liés : - le comportement dépend de l'état - l'état est modifié par le comportement Décoller Avion au sol Tour de contrôle

Communication entre objets Une application, en orienté objet, est une société d'objets collaborant. Comment, dans ces conditions, sont réalisées les fonctions de l'application ? Ce sont les objets, qui travaillent en synergie, pour parvenir à les réaliser. Donc, l'achèvement d'une tâche par une application repose sur la communication entre les objets qui la composent. L'unité de communication entre les objets est le message. Plus spécialisé et plus coopératif que l'objet, l'agent (implémentation partielle des agents possible en Java). L'agent est plus adapté que l'objet pour représenter des êtres intelligents.

Les objets ne vivent pas en ermites Message B Message A Message C Message D Message E

Le concept de message Il existe cinq catégories principales de messages : les constructeurs qui créent des objets les destructeurs qui détruisent des objets (pas en Java) les sélecteurs qui renvoient tout ou partie de l'état d'un objet les modificateurs qui changent tout ou partie de l'état d'un objet les itérateurs qui visitent l'état d'un objet ou le contenu d'une structure de données qui contient plusieurs objets

La programmation orientée objet On dit d'un langage de programmation qu'il est un langage orienté objet quand il supporte les mécanismes : d'héritage de polymorphisme d'encapsulation Smalltalk, Eiffel, C++, Java, ...

L’héritage Les hiérarchies de classes (classification) permettent de gérer la complexité en ordonnant les objets au sein d’arborescence de classes d’abstraction croissante. Les classes descendantes héritent des propriétés des classes ancêtres (exemple : vertébrés, mammifères, hominidés, hommes). généraliser spécialiser Une classe descendante (une sous-classe) peut être également vue comme un sous-type du type défini par la classe ancêtre (la sur-classe) (exemple : ensembles et sous-ensembles mathématiques).

Exemples d’héritage Véhicule Bateau Navire Navire de guerre Navire de pêche Véhicule aérien Véhicule roulant Avion Hélicoptère Voiture Camion

Autre exemple d’héritage Bicyclette VTT VTC VéloDeCourse VéloDeVille

Héritage et redéfinition Une sous-classe peut spécialiser les fonctionnalités de sa super-classe en définissant de nouveaux attributs et/ou de nouvelles méthodes dont elle hérite de deux manières : en remplaçant complètement la méthode héritée par une nouvelle implémentation en spécialisant la méthode héritée en proposant une nouvelle implémentation qui réutilise celle héritée Exemple : calculer la surface d’un polygone, d’un quadrilatère, d’un triangle, d’un carré, d’un rectangle, d’un triangle isocèle, d’un triangle rectangle, ...

Redéfinition : réutilisation Etudiant Nom Prenom Age Affiche() EtudiantSportif SportPratique

Redéfinition : substitution Polygone CalculSurface() Quadrilatere Rectangle Carre Triangle TriangleRectgle TriangleIsocele

Le polymorphisme Le polymorphisme signifie qu'une même opération peut se traduire différemment selon l'objet sur laquelle elle s'applique : Capacité d’un objet à prendre plusieurs formes. On parle également de liaison dynamique. Le polymorphisme associé à la liaison dynamique offre une plus grande simplicité du code (plus besoin de distinguer les cas en fonction des classes) et une plus grande facilité d’évolution du code (les programmes sont plus facilement extensibles comme on peut redéfinir une opération appartenant à une classe dont on hérite, appartenant à une sur-classe).

Liaison dynamique : revenons à l’exemple précédent Polygone CalculSurface() Quadrilatere Rectangle Carre Triangle TriangleRectgle TriangleIsocele

Polymorphisme : classes abstraites Pour exploiter pleinement le polymorphisme, il est courant de définir des classes dont le seul rôle est de spécifier une interface (un ensemble de méthodes) commune pour toutes les classes qui en seront dérivées. Dans de telles classes, les méthodes qui servent à définir cette interface commune sont le plus souvent muettes (elles ne contiennent pas de code effectif).

L’encapsulation Il existe trois niveaux de visibilité : privé protégé public Cela permet de limiter les effets de bord.

Les autres différences La surcharge (prototype de fonctions : plusieurs méthodes portant le même nom à l’intérieur d’une classe) Les pré-conditions, les post-conditions, les invariants La généricité (« template » en C++) Le traitement des situations exceptionnelles (« throw », « try » et « catch » : lever et attraper une exception)

La genèse d'un standard : UML Standardisation par l'OMG UML 2.0 depuis 2003 Soumission à l'OMG UML 1.0 en Janvier 97 Version bêta UML 0.9 Consortium en Juin 96 Draft en 95 Méthode unifiée 0.8 OOSE OMT BOOCH NB : La notation UML est un langage de modélisation objet et non pas une méthode objet. UML peut se substituer aux méthodes Booch, OMT (Object Modelling Technique) et OOSE (Object Oriented Software Engineering) sans perte d’informations.

La phase d'analyse Décrire les cas d'utilisation. Pour chaque cas d'utilisation, réaliser de un à n diagrammes d’interactions (les diagrammes de séquence en premier pour statuer sur les fonctionnalités avec le client ; puis, passer aux diagrammes de collaboration pour continuer l’analyse avec l’équipe projet). À chaque diagramme de collaboration correspond une ébauche de diagramme de classes. Préciser lors de la création d’une classe à quel package elle appartient. Faire la synthèse des diagrammes de classes pour un package donné. Pour chaque classe du diagramme de classes, faire un diagramme d'états-transitions (optionnel).

Les apports de la modélisation visuelle Meilleure appréhension des besoins Facilite la compréhension du problème Facilite la communication entre les personnes (client, experts du domaine, analystes, concepteurs, ...) Support pour le raisonnement Améliore la lisibilité des schémas de conception Prépare la documentation et les programmes Facilite la maintenance

Guide pour appliquer la méthode Recueillir les besoins de l'utilisateur final Adopter le point de vue de l'utilisateur final Penser à la réutilisation Ne préciser que les caractéristiques utiles des classes Généralement dans le cahier des charges, les noms sont des classes ou des attributs de classes et les verbes sont des méthodes Raffiner la modélisation en éliminant les redondances dues aux synonymes, les informations dérivées qui peuvent être déduites, et en s'efforçant de ne pas introduire de détails d'implémentation

Les cas d’utilisation Les cas d'utilisation décrivent, Système Cas d'utilisation X Cas d'utilisation Y Conduire Réparer Vendre Client Mécanicien Vendeur Les cas d'utilisation décrivent, sous la forme d'actions et de réactions, le comportement d'un système du point de vue de l'utilisateur, encore appelé acteur. On recense, de la sorte, l'ensemble des fonctionnalités d'un système en examinant les besoins fonctionnels de chaque acteur.

Les acteurs dans les cas d'utilisation Il existe 4 grandes catégories d'acteurs : - les acteurs principaux. Cette catégorie regroupe les personnes qui utilisent les fonctions principales du système. Dans le cas d'un distributeur de billets, il s'agit des clients. - les acteurs secondaires. Cette catégorie regroupe les personnes qui effectuent des tâches administratives ou de maintenance. Dans le cas d'un distributeur de billets, il s'agit de la personne qui recharge la caisse du distributeur. - le matériel externe. Cette catégorie regroupe les dispositifs matériels autres que les ordinateurs comme les périphériques. Dans le cas d'un distributeur de billets, il s'agit de l'imprimante, du lecteur de carte, de la trieuse de billets. - les autres systèmes. Cette catégorie regroupe les systèmes avec lesquels le système interagit. Dans le cas d'un distributeur de billets, il s'agit du groupement bancaire qui gère l'ordinateur central qui relie tous les distributeurs.

Les relations entre les cas d'utilisation Déclenche relation de communication avec le système relation d'utilisation entre cas relation d'extension entre cas << Utilise >> Cas d'utilisation A Cas d'utilisation B Cas d'utilisation A Cas d'utilisation B << Etend >> Retrait au guichet Client distant Client local Identification Retrait au distributeur << Etend >> << Utilise >>

Description des cas d'utilisation On précise le contenu d'un cas d'utilisation en déroulant tous les scénarios possibles. Un scénario est un chemin particulier au travers de la description abstraite et générale fournie par le cas d'utilisation. En pratique, on ne décrit que les scénarios les plus représentatifs. On peut décrire un scénario à l'aide d'un diagramme de d’interaction (diagramme de séquence, diagramme de collaboration) où un acteur est un objet particulier.

Les diagrammes de séquence Tour de contrôle Roissy Avion A340-002 Piste A1 Avion A340-001 Demande décollage Attente décollage Réservation piste Confirmation Libération piste Fin décollage Autorisation décollage Les diagrammes de séquence montrent la succession des interactions entre les objets dans le temps. On distinguer les messages synchrones ( ) des messages asynchrones ( ) pour lesquels l'émetteur n'est pas bloqué et peut continuer son exécution.

Les spécificités des diagrammes de séquence Un objet Message réflexif Un objet peut s'envoyer un message Un message peut entraîner la création ou la destruction d'objets Un objet Un autre objet Créer Détruire

L'ajout de pseudo code dans les diagrammes Objet A Message Objet B Objet C if X else end if Objet A [X] Message Objet B Objet C [non X] Message

Les diagrammes de collaboration Dès lors que les besoins utilisateurs ont été recensés et validés, il s'agit maintenant de mettre en œuvre le système qui va satisfaire ces besoins utilisateurs. La transition est assurée par les diagrammes de collaboration qui montrent les interactions entre les objets du système. :Personne :Ascenseur :Cabine 1: Venir me chercher au RDC 2: Ajouter destination RDC Une interaction est réalisée par un groupe d'objets qui collaborent en échangeant des messages. Le temps est matérialisé en numérotant les messages. 1: Entrer dans la cabine 3: Ouvrir :Personne :Cabine :Lumière :Porte 2:Allumer

Les spécificités des diagrammes de collaboration B {nouveau} C {transitoire} D {détruit} A B A.1,B.3 / Message Plusieurs flots d’exécution Durée de vie des objets A :X *[i := 1..n] : Message Instituteur :Elève *[tous] : Debout Cardinalité Clause d’itération

Exemples de messages 4 : Afficher (x,y) // message simple 4.2 : âge := Soustraire (Jour, DateNaissance) // message imbriqué 6.2 : [Age >= 18] Voter () // message conditionnel

Guide méthodologique Les diagrammes de collaboration sont une extension des diagrammes objets, d'où une cohésion forte de la méthode. Dès qu'un diagramme de collaboration est établi, on réalise une ébauche du diagramme de classes correspondant. Pour que cela soit constructif, il faut préciser les attributs, les opérations et la cardinalité des associations entre les classes au fur et à mesure qu'on les met en évidence. Sur le plan de l'architecture logicielle, il faut ensuite déterminer à quel package appartient une classe (IHM, objets du domaine, utilitaires, …), de manière à pouvoir faire une synthèse des ébauches de classe par package. Les packages offrent un mécanisme général pour la partition des modèles et le regroupement des éléments de modélisation.

Les diagrammes de classes Objet Association Lien Relie Diagramme de classes Diagramme d'objets Une classe décrit un ensemble d'objets ayant des propriétés similaires (attributs), des comportements communs (opérations) et partageant les mêmes liens avec les autres objets.

Exemple de diagramme de classes départ arrivée composé de Vol Numéro Escale Nom Heure de départ Aéroport Paris_Nouméa : Vol AF-5177 Paris_Singapour : Escale 23h15 Singapour Sydney : Escale 10h50 Sydney_Nouméa : Escale 15h30 Roissy : Aéroport Shangi : Aéroport Sydney_Airport : Aéroport Nouméa_Airport : Aéroport

Les attributs et les méthodes Aéroport Ville Nom OuvrirEmbarquement() FermerEmbarquement() nom attributs méthodes Syntaxe des attributs et des méthodes : Nom_Attribut : Type_Attribut = Valeur_Initiale Nom_Méthode (Nom_Argument : Type_Argument = Valeur_Par_Défaut, …) : Type_Retourné

Les attributs et les méthodes Un attribut est une donnée propre aux objets d'une classe particulière Chaque nom d'attribut est unique à l'intérieur d'une classe Chaque attribut a une valeur pour toute instance. Méthodes Une méthode est une fonction ou transformation qui peut s'effectuer sur les objets d'une classe ou être effectuée par ces objets Tous les objets partagent les mêmes méthodes Les règles d’encapsulation (de visibilité) : public qui rend l'élément visible à tous les éléments de la classe (+) protégé qui rend l'éléments visibles aux classes dérivées de la classe (#) privé qui rend l'élément visible à la classe seule (-)

Les stéréotypes de classes Table générique Elément Les classes paramétrables (généricité) Les classes utilitaires (modules non instanciables) <<Utilitaire>> Math

Les associations est employé par est employeur de Compagnie Aérienne Personne emploie Avion est piloté par transporte Une association décrit un groupe de liens ayant une structure et une sémantique commune. Elles expriment les relations structurelles entre les classes.

Cardinalité des associations 1 Un et un seul 0..1 Zéro ou un M..N De M à N (entiers naturels) * De zéro à plusieurs 0..* De zéro à plusieurs 1..* D'un à plusieurs La cardinalité spécifie combien d'instances d'une classe peuvent être en relation avec une instance de la classe associée. Elle est à préciser pour chaque rôle.

Multiplicité des associations 1 0..* Diplôme Mention Etudiant Travail Chambre Numéro Spécification de contraintes {Ou-exclusif} Université Personne enseignants Etudiants

Les types d'associations : L'agrégation Classe A Classe B Une agrégation représente une association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l'autre extrémité. On applique les critères suivants : une classe fait partie d'une autre classe, les valeurs d'attributs d'une classe se propageant dans les valeurs d'attributs d'une autre classe, une action sur une classe implique une action sur une autre classe, les objets d'une classe sont subordonnés aux objets d'une autre classe.

La relation de composition Voiture Moteur Cylindre Carburateur

Les types d'associations : la généralisation Personne Personne naviguante Personne au sol Les descendants héritent des propriétés de leurs ancêtres. On va du général au particulier.

Le polymorphisme Les classes abstraites : ce sont des classes qui Personne CalculPrime() Personne naviguant au sol Les classes abstraites : ce sont des classes qui n'ont pas d'instances mais dont les descendants ont des instances Classe Abstraite

L'héritage multiple Avion Hydravion Moyen Courrier Navire Cargo

Les diagrammes d'états-transitions Cas d'utilisation Diagrammes d'interactions (diagrammes de séquence ou diagrammes de collaborations) Diagrammes de classes Diagrammes d'états-transitions Validation de la phase d'analyse Le formalisme retenu est celui des statecharts : Harel, D. 1987. Statecharts : A Visual Formalism for Complex Systems. Science of Computer programming vol. 8.

Description des diagrammes d'états-transitions Le comportement des objets d'une classe est décrit de manière formelle en termes d'états et d'événements, au moyen d'un automate relié à la classe considérée. 0..1 1 Classe A Automate Un état Un autre état Etat final Les états Le passage d'un état à un autre s'effectue lorsqu'une transition est déclenchée par un événement qui survient dans le domaine du problème.

Exemple de diagramme d'états-transitions Atterrit Fin de service S'écrase Décolle Mis en service Au sol En vol Etat initial Etat final

Les événements Embauche Perte d'emploi Plus de 60 ans En activité A la retraite Au chômage Un événement est par nature une information instantanée qui doit être traitée sans attendre. Il sert de déclencheur pour passer d'un état vers un autre. Sa syntaxe est : Nom_Evénement (Nom_Paramètre : Type, …)

Autorisation décollage [check-list avion OK] / décoller Transition d'état Un objet Un autre objet La réponse La question La communication entre automates peut également être de type synchrone Les gardes, les actions et les activités Autorisation décollage [check-list avion OK] / décoller Au sol En vol

Points d'exécution des opérations En activité entry : Op2 do : Op3 exit : Op4 on UnEvt : Op5 / Op1 / Op6 l'action associée à la transition d'entrée (Op1) l'action d'entrée de l'état (Op2) l'activité dans l'état (Op3) l'action de sortie de l'état (Op4) l'action associée aux événements internes (Op5) l'action associée à la transition de sortie de l'état (Op6)

La généralisation d'états Arrêt Fin embarquement Entretien Opérationnel Fin de service Atterrit Décolle Mis en service En vol Immobilisé Roulement Embarquement Au sol Crash

L'agrégation d'états Avion Moteur Train d'atterrissage Décollage Sorti Entré Max Croisière En vol

Guide méthodologique Les diagrammes d'états-transitions permettent d'effectuer une vérification du système sous forme textuelle. On déclenche un événement, et on observe les changements d'états des objets du système. En cas d'incohérence, il faut recommencer l'analyse. Dans un contexte temps-réel, il est possible d'utiliser des "run-time" pour générer un prototype du système.