Jean-Marc CIEUTAT Enseignant-Chercheur ESTIA/LIPSI

Présentation au sujet: "Jean-Marc CIEUTAT Enseignant-Chercheur ESTIA/LIPSI"— Transcription de la présentation:

1 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

2 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

3 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)

4 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)

5 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

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

7 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

8 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).

9 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 ?

10 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, …

11 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, ...

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

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

14 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, …

15 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

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

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

18 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

19 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, ...

20 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).

21 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

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

23 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, ...

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

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

26 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).

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

28 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).

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

30 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)

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

32 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).

33 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

34 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

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

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

37 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 >>

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

39 Les diagrammes de séquence
Tour de contrôle Roissy Avion A Piste A1 Avion A 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.

40 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

41 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

42 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

43 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

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

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

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

47 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

48 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é

49 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 (-)

50 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

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

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

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

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

55 La relation de composition
Voiture Moteur Cylindre Carburateur

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

57 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

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

59 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 Statecharts : A Visual Formalism for Complex Systems. Science of Computer programming vol. 8.

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

61 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

62 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, …)

63 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

64 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)

65 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

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

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