Diagrammes UML - Free

24
Diagrammes UML : Anthony Médassi La modélisation objet

Transcript of Diagrammes UML - Free

Diagrammes UML :

An

tho

ny

Méd

assi

La modélisation objet

Pourquoi modéliser? 1 logiciel est développé par:

1 personne

1 équipe

Plusieurs équipes coordonnées

En 1995, une étude établit:

16% des projets conformes aux prévisions

53% ont dépassé en coût et délais (2 ou 3 fois)

31% abandonnés

Échecs provenant de la maîtrise d’ouvrage

Nouvelle discipline : Le génie logiciel

Le génie logiciel

Domaine dédié à:

L'étude de programmes informatiques

La conception de programmes informatiques

La réalisation de programmes informatiques

Ensemble composé :

D'une méthode

De modèles

D'outils d'aide au développement et de critères d'évaluation de la qualité

Le génie logiciel : Acteurs

Permet à un maître d'œuvre de produire un logiciel

Ce logiciel doit répondre aux besoins exprimés par un maître d'ouvrage.

Maître d'ouvrage

Donneur d'ordre

Client qui commande le logiciel à développer

Peut être l'un des futurs utilisateurs du logiciel

Maître d'œuvre

Responsable de la production du logiciel.

Génie logiciel : Méthode 3 aspects :

Des modèles,

Une démarche

Une documentation

Génie logiciel : Méthode Des Modèles pour :

comprendre,

représenter

et communiquer les différents éléments entrant dans la composition d'un logiciel,

Une démarche indique: les étapes à suivre

les opérations à réaliser afin d'aboutir au logiciel souhaité dans les délais prévus,

Une documentation type: Mémorise les éléments techniques et organisationnels qui ont

permis d'aboutir au logiciel.

Les outils Appelés AGL (Atelier de Génie Logiciel)

Permet de suivre le cycle de vie du logiciel:

Analyse

Conception

Réalisation

Maintenance

Les outils pour : Représenter les modèles (dessin des diagrammes)

Produire la documentation technique,

Normaliser les noms

Générer le code des programmes ( souvent mal optimisés)

Aider à la conduite de projet

Aider à la maintenance

Aider au suivi d'exploitation,

Aider au contrôle de la qualité.

Notion de qualité logiciel 1/2 Validité : respect des fonctions définies par le cahier

des charges.

Extensibilité: facilité de maintenance

Modification

Ou extension des fonctions

Réutilisabilité : dans de nouvelles applications

Compatibilité : combiné avec d’autres logiciels

Efficacité : optimisation des ressources matérielles.

Notion de qualité logiciel 2/2 Portabilité : matériels et logiciels (OS).

Vérifiabilité : facilité de préparation des procédures de test.

Intégrité : protection du code et données

Facilité d’emploi (d’apprentissage, d’utilisation, de préparation des données, d’interprétation des erreurs et de rattrapage en cas d’erreur d’utilisation.)

QQs Rappels (La classe) L’approche objet rapproche les données et leurs

traitements.

Classe :

Une classe est un type de données abstrait qui précise des caractéristiques (attributs et méthodes) communes à toute une famille d’objets

Une classe permet de créer (instancier) des objets possédant ces caractéristiques.

QQs Rappels (Encapsulation) Encapsulation:

Masque les détails d’implémentation d’un objet

Définit une interface qui est la vue externe d’un objet

Définit les services accessibles (offerts) aux utilisateurs de l’objet

L’encapsulation facilite l’évolution d’une application en stabilisant l’utilisation des objets : Modification d’implémentation des attributs d’un objet

sans modifier son interface

Garantit l’intégrité des données en interdisant l’accès aux attributs

QQs Rappels (Héritage) Mécanisme de transmission des caractéristiques d’une

classe (ses attributs et méthodes) vers une sous-classe.

Ajout de caractéristiques dans la sous classe.

Généralisation/Spécialisation

Héritage simple ou multiple (pas Java)

Permet des hiérarchies de classe

QQs Rappels (Polymorphisme) Représente la faculté d’une méthode à pouvoir

s’appliquer à des objets de classes différentes.

Augmente la généricité, et donc la qualité, du code.

QQs Rappels (Agrégation) Relation entre deux classes spécifiant que les objets

d’une classe sont des composants de l’autre classe.

Définir des objets composés d’autres objets.

Permet l’assemblage d’objets de base, afin de construire des objets plus complexes.

Et l’UML dans tout ça! POO fait ressortir un travail conceptuel, les définitions:

Des classes

De leurs relations

Des attributs

Des méthodes

Des interfaces

etc.

Avant programmation, organisation des idées -> Modélisation

UML : terrain d’entente entre MOe et Moa

Provenance d’UML Avant POO, méthodes séparent traitements et données

(MERISE)

En 1990 : environs 50 méthodes

En 1994 : Consensus autour de:

OMT de James Rumbaugh : Représentation graphique des aspects statiques, dynamiques et fonctionnels d’un système

OOD de Grady Booch introduit le concept de paquetage (package)

OOSE d’Ivar Jacobson fonde l’analyse sur la description des besoins des utilisateurs (use cases)

James Rumbaugh

Grady Booch

Ivar Jacobson

Unified Modeling Language Uml n’est pas une méthode

Uml est un Langage

1995 : Boogh et Rumbaugh pour Unified Method 0.8

1996 : + Jacobson pour UML 0.9

1997: L’OMG adopte UML 1.1

Actuellement UML 2

UML – Structure/Statique Diagramme de classes (Class diagram)

Diagramme d’objets (Object diagram)

Diagramme de composants (Component diagram)

Diagramme de déploiement (Deployment diagram)

Diagramme de paquetages (Package diagram)

Diagramme de structures composites (Composite structure diagram)

UML – Comportement/Dynamique Diagramme de cas d’utilisation (Use case diagram)

Diagramme d’activités (Activity diagram)

Diagramme d’états-transitions (State machine diagram)

Diagramme de séquence (Sequence diagram)

Diagramme de communication (Communication diagram)

Diagramme global d’interaction (Interaction overviewdiagram)

Diagramme de temps (Timing diagram)

FIN