Upload
others
View
17
Download
0
Embed Size (px)
Citation preview
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 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)
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)