Processus unifié de développement orienté objet de logiciels : Utilisation du langage de...
-
Upload
eustacia-mas -
Category
Documents
-
view
120 -
download
0
Transcript of Processus unifié de développement orienté objet de logiciels : Utilisation du langage de...
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 foisAnalyse
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
Atterrir
Décoller
Tour de contrôle
Avion
en vol
Avion
au sol
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.
L'état et le comportement sont liés :- le comportement dépend de l'état- l'état est modifié par le comportement
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
Objet 1
Objet 3 Objet 4
Objet 2
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èreVoiture 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
NomPrenom
Age
Affiche()
EtudiantSportif
SportPratique
Affiche()
Redéfinition : substitution
Polygone
CalculSurface()
Quadrilatere
CalculSurface()
Rectangle
CalculSurface()
Carre
CalculSurface()
Triangle
CalculSurface()
TriangleRectgle
CalculSurface()
TriangleIsocele
CalculSurface()
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
CalculSurface()
Rectangle
CalculSurface()
Carre
CalculSurface()
Triangle
CalculSurface()
TriangleRectgle
CalculSurface()
TriangleIsocele
CalculSurface()
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.0depuis 2003
Soumission à l'OMG UML 1.0en Janvier 97 Version bêta UML 0.9 Consortiumen 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
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
Retrait au guichet
Client distant
Client local
Identification
Retrait au distributeur
<< Etend >>
<< Utilise >>
Cas d'utilisation
Déclenche
Cas d'utilisation B
<< Utilise >>
Cas d'utilisation A
Cas d'utilisation A Cas d'utilisation B
<< Etend >>
relation de communication avec le système
relation d'utilisation entre cas
relation d'extension entre cas
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 A1Avion A340-001
Demande décollage
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
Un autre objetCréer
Détruire
Un objet peut s'envoyer un message
Un message peut entraîner la création ou la destruction d'objets
L'ajout de pseudo code dans les diagrammes
Objet A
[X] Message
Objet B Objet C
[non X] Message
Objet A
Message
Objet B Objet C
Message
if X
else
end if
Les diagrammes de collaboration
:Personne :Ascenseur
:Cabine
1: Venir me chercher au RDC
2: Ajouter destination RDC
1: Entrer dans la cabine
3: Ouvrir
:Personne :Cabine
:Lumière
:Porte
2:Allumer
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.
Une interaction est réalisée par un groupe d'objets qui collaborent en échangeant des messages.
Le temps est matérialisé ennumérotant les messages.
Les spécificités des diagrammes de collaboration
A B {nouveau}
C {transitoire}
D {détruit}
Instituteur
:Elève
*[tous] : Debout
Durée de vie des objets
Cardinalité
A
B
A.1,B.3 / Message
Plusieurs flots d’exécution
A
:X
*[i := 1..n] : Message
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
Classe Objet
Association Lien
Relie 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épartarrivée
composé deVol
NuméroEscaleNom
Heure de départ
AéroportNom
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
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é
Aéroport
VilleNom
OuvrirEmbarquement()FermerEmbarquement()
nom
attributs
méthodes
Les attributs et les méthodes
• Attributs - 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
<<Utilitaire>>
Math
Les classes paramétrables (généricité)
Les classes utilitaires (modules non instanciables)
Les associations
est employé par
est employeur de
Compagnie Aérienne
Personneemploie
Compagnie Aérienne
Personne
Avion Personne
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
1
0..*0..*10..*
Diplôme
Mention
Etudiant Travail
Chambre
Numéro
{Ou-exclusif}Université Personne
enseignants
Etudiants
Spécification de contraintes
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
Personne
CalculPrime()
Personne naviguant
CalculPrime()
Personne au sol
CalculPrime()
Classe AbstraiteLes classes abstraites : ce sont des classes qui n'ont pas d'instances mais dont les descendants ont des instances
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
0..11
Classe A AutomateLe 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.
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
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, …)
Transition d'état
Un objet Un autre objet
La réponse
La question
Autorisation décollage [check-list avion OK] / décoller
Au sol En vol
La communication entre automates peut également être de type synchrone
Les gardes, les actions et les activités
Points d'exécution des opérations
En activité
entry : Op2do : Op3
exit : Op4on 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.