Sommaire: La modélisation objet

1 Introduction à la modélisation objet
1.1 Le génie logiciel
1.1.1 L’informatisation
1.1.2 Les logiciels
1.1.3 Le génie logiciel
1.1.4 Notion de qualité pour un logiciel
1.2 Pourquoi et comment modéliser ?
1.2.1 Notions de modèle et de modélisation
1.2.2 Le cycle de vie d’un logiciel
1.2.3 Modèles de cycles de vie d’un logiciel
1.2.4 Méthodes d’analyse et de conception
1.3 De la programmation structurée à l’approche orientée objet
1.3.1 Méthodes fonctionnelles ou structurées
1.3.2 L’approche orientée objet
1.3.3 Approche fonctionnelle vs. approche objet
1.3.4 Concepts importants de l’approche objet
1.3.5 Historique la programmation par objets
1.4 UML
1.4.1 Introduction
1.4.2 Histoire des modélisations par objets
1.4.3 UML en œuvre
1.4.4 Comment présenter un modèle UML ?
2 Diagramme de cas d’utilisation
2.1 Introduction
2.2 Éléments des diagrammes de cas d’utilisation
2.2.1 Acteur
2.2.2 Cas d’utilisation
2.2.3 Représentation d’un diagramme de cas d’utilisation
2.3 Relations dans les diagrammes de cas d’utilisation
2.3.1 Relations entre acteurs et cas d’utilisation
2.3.2 Relations entre cas d’utilisation
2.3.3 Relations entre acteurs
2.4 Notions générales du langage UML
2.4.1 Note
2.4.2 Stéréotype
2.4.3 Classeur
2.4.4 Paquetage
2.4.5 Espace de noms
2.5 Modélisation des besoins avec UML
2.5.1 Comment identifier les acteurs ?
2.5.2 Comment recenser les cas d’utilisation ?
2.5.3 Description textuelle des cas d’utilisation
2.5.4 Description avec des diagrammes dynamiques simples
2.5.5 Remarques
2.5.6 Les Use case Realization
3 Diagramme de classes
3.1 Introduction
3.2 Les classes
3.2.1 Notions de classe et d’instance de classe
3.2.2 Notions de propriétés
3.2.3 Représentation graphique
3.2.4 Encapsulation, visibilité, interface
3.2.5 Nom d’une classe
3.2.6 Les attributs
3.2.7 Les méthodes
3.2.8 Classe active
3.3 Relations entre classes
3.3.1 Généralisation et Héritage
3.3.2 Association
3.3.3 Multiplicité ou cardinalité
3.3.4 Navigabilité
3.3.5 Qualification
3.3.6 Classe-association
3.3.7 Agrégation
3.3.8 Composition
3.3.9 Dépendance
3.4 Interfaces
3.5 Élaboration d’un diagramme de classes
3.6 Diagramme d’objets
3.6.1 Présentation
3.6.2 Représentation
3.6.3 Relation de dépendance d’instanciation
4 Object constraint langage (OCL)
4.1 Expression des contraintes en UML
4.1.1 Introduction
4.1.2 Écriture des contraintes
4.1.3 Représentation des contraintes et contraintes prédéfinies
4.2 Intérêt d’OCL
4.2.1 OCL – Introduction
4.2.2 Illustration par l’exemple
4.3 Typologie des contraintes OCL
4.3.1 Diagramme support des exemples illustratifs
4.3.2 Contexte
4.3.3 Invariants (inv)
4.3.4 Préconditions et postconditions (pre, post)
4.3.5 Résultat d’une méthode (body)
4.3.6 Définition d’attributs et de méthodes (def et letin)
4.3.7 Initialisation (init) et évolution des attributs (derive)
4.4 Types et opérations utilisables dans les expressions OCL
4.4.1 Types et opérateurs prédéfinis
4.4.2 Types du modèle UML
4.4.3 OCL est un langage typé
4.4.4 Collections
4.5 Accès aux propriétés et aux objets
4.5.1 Accès aux attributs et aux opérations (self )
4.5.2 Navigation via une association
4.5.3 Navigation via une association qualifiée
4.5.4 Navigation vers une classe association
4.5.5 Navigation depuis une classe association
4.5.6 Accéder à une propriété redéfinie (oclAsType())
4.5.7 Propriétés prédéfinies sur tous les objets
4.5.8 Propriétés sur les classes
4.6 Opérations sur les collections
4.6.1 Introduction : «.», «->», «: :» et self
4.6.2 Opérations de base sur les collections
4.6.3 Opération sur les éléments d’une collection
4.6.4 Règles de précédence des opérateurs
4.7 Exemples de contraintes
5 Diagramme d’états-transitions
5.1 Introduction au formalisme
5.1.1 Présentation
5.1.2 Notion d’automate à états finis
5.1.3 Diagrammes d’états-transitions
5.2 État
5.2.1 Les deux acceptions du terme état
5.2.2 État initial et final
5.3 Événement
5.3.1 Notion d’évènement
5.3.2 Événement de type signal (signal)
5.3.3 Événement d’appel (call)
5.3.4 Événement de changement (change)
5.3.5 Événement temporel (after ou when)
5.4 Transition
5.4.1 Définition et syntaxe
5.4.2 Condition de garde
5.4.3 Effet d’une transition
5.4.4 Transition externe
5.4.5 Transition d’achèvement
5.4.6 Transition interne
5.5 Point de choix
5.5.1 Point de jonction
5.5.2 Point de décision
5.6 États composites
5.6.1 Présentation
5.6.2 Transition
5.6.3 État historique
5.6.4 Interface : les points de connexion
5.6.5 Concurrence
6 Diagramme d’activités
6.1 Introduction au formalisme
6.1.1 Introduction
6.1.2 Action
6.1.3 Activité
6.1.4 Groupe d’activités
6.1.5 Nœud d’activité
6.1.6 Transition
6.2 Nœud exécutable
6.2.1 Nœud d’action
6.2.2 Nœud d’activité structurée
6.3 Nœud de contrôle
6.3.1 Nœud initial
6.3.2 Nœud final
6.3.3 Nœud de décision et de fusion
6.3.4 Nœud de bifurcation et d’union
6.4 Nœud d’objet
6.4.1 Introduction
6.4.2 Pin d’entrée ou de sortie
6.4.3 Pin de valeur
6.4.4 Flot d’objet
6.4.5 Nœud tampon central
6.4.6 Nœud de stockage des données
6.5 Partitions
6.6 Exceptions
7 Diagrammes d’interaction
7.1 Présentation du formalisme
7.1.1 Introduction
7.1.2 Classeur structuré
7.1.3 Collaboration
7.1.4 Interactions et lignes de vie
7.1.5 Représentation générale
7.2 Diagramme de communication
7.2.1 Représentation des lignes de vie
7.2.2 Représentation des connecteurs
7.2.3 Représentation des messages
7.3 Diagramme de séquence
7.3.1 Représentation des lignes de vie
7.3.2 Représentation des messages
7.3.3 Fragments d’interaction combinés
7.3.4 Utilisation d’interaction
8 Diagrammes de composants et de déploiement
8.1 Introduction
8.2 Diagrammes de composants
8.2.1 Pourquoi des composants ?
8.2.2 Notion de composant
8.2.3 Notion de port
8.2.4 Diagramme de composants
8.3 Diagramme de déploiement
8.3.1 Objectif du diagramme de déploiement
8.3.2 Représentation des nœuds
8.3.3 Notion d’artefact (artifact)
8.3.4 Diagramme de déploiement
9 Mise en œuvre d’UML
9.1 Introduction
9.1.1 UML n’est pas une méthode
9.1.2 Une méthode simple et générique
9.2 Identification des besoins
9.2.1 Diagramme de cas d’utilisation
9.2.2 Diagrammes de séquence système
9.2.3 Maquette de l’IHM
9.3 Phases d’analyse
9.3.1 Modèle du domaine
9.3.2 Diagramme de classes participantes
9.3.3 Diagrammes d’activités de navigation
9.4 Phase de conception
9.4.1 Diagrammes d’interaction
9.4.2 Diagramme de classes de conception
9.5 Phase d’implémentation
9.5.1 Implémentation en Java
9.5.2 Implémentation en SQL
Bibliographie

♣ Extrait du cours

Chapitre 1 Introduction à la modélisation objet
1.1 Le génie logiciel
1.1.1 L’informatisation
L’informatisation est le phénomène le plus important de notre époque. Elle s’immisce maintenant dans la pluspart des objets de la vie courante et ce, que ce soit dans l’objet proprement dit 1 , ou bien dans le processus de conception ou de fabrication de cet objet.
Actuellement, l’informatique est au cœur de toutes les grandes entreprises. Le système d’information d’une entreprise est composé de matériels et de logiciels. Plus précisément, les investissements dans ce système d’information se réparatissent généralement de la manière suivante : 20% pour le matériel et 80% pour le logiciel. En effet, depuis quelques années, la fabrication du matériel est assurée par quelques fabricants seulement. Ce matériel est relativement fiable et le marché est standardisé. Les problèmes liés  à l’informatique sont essentiellement des problèmes de logiciel.
1.1.2 Les logiciels
Un logiciel ou une application est un ensemble de programmes, qui permet à un ordinateur ou à un système informatique d’assurer une tâche ou une fonction en particulier (exemple : logiciel de comptabilité, logiciel de gestion des prêts).
Les logiciels, suivant leur taille, peuvent être développés par une personne seule, une petite équipe, ou un ensemble d’équipes coordonnées. Le développement de grands logiciels par de grandes équipes pose d’importants problèmes de conception et de coordination. Or, le développement d’un logiciel est une phase absolument cruciale qui monopolise l’essentiel du coût d’un produit 2 et conditionne sa réussite et sa pérennité.
En 1995, une étude du Standish Group dressait un tableau accablant de la conduite des projets informatiques. Reposant sur un échantillon représentatif de 365 entreprises, totalisant 8380 applications, cette étude établissait que :
– 16, 2% seulement des projets étaient conformes aux prévisions initiales,
– 52, 7% avaient subi des dépassements en coût et délai d’un facteur 2 à 3 avec diminution du nombre des fonctions offertes,
– 31, 1% ont été purement abandonnés durant leur développement.
1.1.3 Le génie logiciel
Le génie logiciel est un domaine de recherche qui a été défini (fait rare) du 7 au 11 octobre 1968, à Garmisch-Partenkirchen, sous le parrainage de l’OTAN. Il a pour objectif de répondre à un problème qui s’énonçait en deux constatations : d’une part le logiciel n’était pas fiable, d’autre part, il était incroyablement difficile de réaliser dans des délais prévus des logiciels satisfaisant leur cahier des charges. L’objectif du génie logiciel est d’optimiser le coût de développement du logiciel. L’importance d’une approche méthodologique s’est imposée à la suite de la crise de l’industrie du logiciel à la fin des années 1970. Cette crise de l’industrie du logiciel était principalement due à :
– l’augmentation des coûts ;
– les difficultés de maintenance et d’évolution ;
– la non fiabilité ;
– le non respect des spécifications ;
– le non respect des délais.
La maintenance est devenue une facette très importante du cycle de vie d’un logiciel. En effet, une enquête effectuée aux USA en 1986 auprès de 55 entreprises révèle que 53% du budget total d’un logiciel est affecté à la maintenance. Ce coût est réparti comme suit :
– 34% maintenance évolutive (modification des spécifications initiales) ;
– 10% maintenance adaptative (nouvel environnement, nouveaux utilisateurs) ;
– 17% maintenance corrective (correction des bogues) ;
– 16% maintenance perfective (améliorer les performance sans changer les spécifications) ;
– 6% assistance aux utilisateurs ;
– 6% contrôle qualité ;
– 7% organisation/suivi ;
– 4% divers.
1.1.4 Notion de qualité pour un logiciel
En génie logiciel, divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui dépendent, entre autres, du domaine de l’application et des outils utilisés. Parmi ces derniers nous pouvons citer :
Validité : aptitude d’un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications.
Fiabilité ou robustesse : aptitude d’un produit logiciel à fonctionner dans des conditions anormales.
Extensibilité (maintenance) : facilité avec laquelle un logiciel se prête à sa maintenance, c’est-à-dire à une modification ou à une extension des fonctions qui lui sont demandées.
Réutilisabilité : aptitude d’un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications.
1.2 Pourquoi et comment modéliser ?
1.2.1 Notions de modèle et de modélisation
Qu’est-ce qu’un modèle ?
Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d’une entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, de l’expliquer ou de le prévoir. Modèle est synonyme de théorie, mais avec une connotation pratique : un modèle, c’est une théorie orientée vers l’action qu’elle doit servir.
Concrètement, un modèle permet de réduire la complexité d’un phénomène en éliminant les détails qui n’influencent pas son comportement de manière significative. Il reflète ce que le concepteur croit important pour la compréhension et la prédiction du phénomène modélisé, les limites du phénomène modélisé dépendant des objectifs du modèle.
Voici quelques exemples de modèles prédictifs :
Modèle météorologique – à partir de données d’observation (satellite . . .), il permet de prévoir les conditions climatiques pour les jours à venir.
Modèle économique – peut par exemple permettre de simuler l’évolution de cours boursiers en fonction d’hypothèses macro-économiques (évolution du chômage, taux de croissance . . .).
Modèle démographique – définit la composition d’un panel d’une population et son comportement, dans le but de fiabiliser des études statistiques, d’augmenter l’impact de démarches commerciales, etc.

………………………….