Si Analyse-Conception Objet L3 - Partie 1

1
SYSTÈME D’INFORMATION
ANALYSE/CONCEPTION OBJET
2
 Objectifs du cour :
 Acquérir les compétences sur les méthodes et outils d'analyse et de conception
de systèmes d'information.
 Savoir Modéliser avant d’entreprendre la construction d’un Système
d’Information
 Connaitre et savoir utiliser le langage de modélisation objet UML décrire les
aspects fonctionnel et statique d’un systèmes d'information.
 Savoir faire le lien entre les modèles et les bases de données.
 Connaitre et appliquer les principes et patrons de conception
3
 Sommaire :
 Notion de Système d’Information
 Concept et Thèmes de l’Orienté Objet
 Méthodes – Processus- Langages
 UML
 Mapping Objet-Relationnel
 Ex de méthodes Objet (Processus Unifié)
 Principes de Conception- Patrons d’Architecture – Patrons de Conception
4
NOTION DE SYSTÈMES
D’INFORMATION(SI)
NOTION DE SYSTÈMES
D’INFORMATION
5
• Qu’est-ce qu’un SI ?
• Un SI est une combinaison de
personnes, de technologies de
l’information et de processus
métiers pour accomplir un
objectif métier.
• Un SI est une collection de Personnes
composants qui collecte, traite, Acteurs impliqués
stocke des données, et qui fournit dans un Processus
l’information nécessaire à métier
l’exécution des tâches métiers.
Processus Métier Technologie de

l’Information
Activités orientés
par un objectif Matériels/Logiciels
utilisés
NOTION DE SYSTÈMES
D’INFORMATION
6
 Informatique et SI ?
 Le système d’information est (en général) partiellement informatisé.
SI Opérationnel
SI Informatisé
 Les SI sont utilisés dans chaque domaine fonctionnel du métier (marketing, gestion,
finance, banque, etc.)
 Les SI sont généralement constitués de plusieurs applications exploitant des informations
communes. Il sont des tailles et d’envergure variables (de modeste à gigantesque):
 Facebook, > 1 000 000 000 de comptes, des centaines de milliards de mises à jours
 Google > 100 000 000 000 de documents indexés
NOTION DE SYSTÈMES
D’INFORMATION
7
 Typologies des SI
 Il existe plusieurs types de SI. Exemple
NOTION DE SYSTÈMES
D’INFORMATION
8
 Base de Données
 Une base de données est ensemble de données mémorisées sur des supports
accessibles par un ordinateur et simultanément par plusieurs utilisateurs de
façon sélective et en temps très court.
 Les BD constituent le cœur du système d’information. Elles sont utilisées à
travers des applications de Bases de données.
 Il existe plusieurs types de bases de données
 BD Hiérarchiques ou Réseaux : fondées sur une modélisation arborescente des données (≈ 1960)
 BD Relationnelles : organisation des données sous forme de tables et exploitation à l’aide d’un
langage déclaratif (≈ 1970/1980)
 BD Déductives : organisation de données sous forme de table et exploitation à l’aide d’un langage
logique (≈ 1970/1980).
 BD Objets : données sous forme d’instances de classes hiérarchisées (≈ 1990).
 XML :structure arborescente (≈ 2000), NOSQL, etc
NOTION DE SYSTÈMES
D’INFORMATION
9
 Système de Gestion de Bases de Données (SGBD)
 Un SGBD est un ensemble d’outils permettant la création, la manipulation
et l’administration des BD. Exemple : ORACLE, POSTGRESQL.
 Principes Fondamentaux
 Conforme à la réalité
 Unicité: Pas de redondance
 Indépendance: Indépendant du modèle de stockage
 Concurrence: Gestion des accès simultanés à une même donnée
 Performance: Temps d’exécution satisfaisant
 Confidentialité: Accessibilité des données dépendant de l’utilisateur
 Intégrité: garantie la fiabilité et la cohérence des données
 Robustesse: Tolérant aux pannes (problèmes matériels, logiciels ou humains)
NOTION DE SYSTÈMES
D’INFORMATION
10
 Conception des BD Relationnelles :
 La conception des BD relationnelles suit une démarche en étapes (différents
modèles pour représenter les objets qui composent les systèmes
d’information, les relations existantes entre ces objets ainsi que les règles
sous-jacentes)
 Trois étapes principales qui correspondent à trois niveaux d’abstraction
différents : Conceptuel, Logique, Physique
 Le niveau conceptuel (e.g. modèle Entité-Association, diagramme de classe
UML) permet l’identification des concepts concrets et abstraits de la réalité
 Le niveau logique (e.g. modèle relationnel) permet la formalisation de la
structure des données
 Le niveau physique (e.g. système de fichiers, index) concerne le stockage
physique des données, gérée par le SGBD
 Le niveau externe (sous-schémas conceptuels) concerne la définition des
« interfaces » d’accès aux données
NOTION DE SYSTÈMES
D’INFORMATION
11
 Conception des BD Relationnelles :
Vues Informationnelles
Analyse
Spécification V1 V2 V3
Niveau Externe
Intégration
Normalisation
Modèle Conceptuelle des Données
Optimisation
Dénormalisation
Modèle Logique des Données
Mise en œuvre
Modèle Physique des Données
Les niveaux de modélisation des données

12
Concept et Thèmes
de l’Orienté Objet
Concept et Thèmes de l’Orienté Objet
13
 Orienté Objet:
 Le paradigme « Orienté Objet » consiste en une Organisation du
logiciel sous la forme d’une collection d’objets indépendants
incorporant structure de données et comportement.
 Objet
 Un objet est une entité discrète et distinguable, concrète ou abstraite
ayant des limites claires et un sens précis dans le contexte du problème
étudié.
 Ex: la voiture FF 12567, le PSGE, l'étudiant Pierre KOUMBA
 Un objet est caractérisé par :
 Une identité qui le distingue logiquement et physiquement des autres.
 Un état : valeurs des attributs + liens avec d’autres objets
 Un comportement: l’ensembles des opérations applicables à l'objet.
14
 Classification:
 La classification implique le regroupement des objets ayant même structure de
données(attributs) et même comportement(opérations)
 Classe:
 Une classe est une abstraction décrivant un ensemble d’objets potentiellement
infini ayant des propriétés similaires (attributs), un comportement commun
(opérations), des relations communes avec les autres objets ainsi qu’une même
sémantique
 Une classe définit des attributs et des opérations
 Instances de la classe : Les objets de la classe
 Attributs
 Un attribut (aussi appelé variables d’instance) est une caractéristique d’un objet
désignée par un nom permettant de mémoriser une ou plusieurs valeurs, ou un ou
plusieurs identifiants d’objets.
15
 Classe:
 Opérations
 Une opération est une action, fonction ou transformation qui peut être
appliquée aux objets ou par les objets dans une classe.
 Ex: embaucher, licencier, rémunérer sont des opérations de la classe
Société
 Méthode :
 Une Méthode est une implémentation d’une opération par une classe.
 Une méthode est caractérisée par un en-tête appelé signature
définissant son nom, ses paramètres d’appel et ses paramètres de retour
et par son code
 Ex: embaucher(Personne p, String poste )
16
 Héritage :
 L’héritage est le partage de propriétés entre classes sur la base d’une
relation hiérarchique
 Super-classe (classe mère)
 Sous-classe(classe fille) : spécialisation de la super-classe avec héritage
des propriétés de la super-classe.
 Polymorphisme
 possibilité de gérer des comportements différents d’une même
opération dans différentes classes
 Constituants du Label « Orienté Objet »

 identité, classification, héritage , polymorphisme
17
 Méthodes – Processus- Langages

Méthodes – Processus- Langages
18
 Méthode:
 Le Développement d’un SI avec de bonnes garanties de succès
implique l'utilisation dune démarche méthodologique adéquate
(Méthode de Développement).
 Une Méthode de développement comporte un Processus de
développement, utilise un ou plusieurs Langages de Modélisation et un
ensemble d’Outils.
Notation (Langage de
Modélisation)
Processus Outils
19
 Processus de Développement :
 Un processus de développement est un ensemble d’étapes à exécuter
selon un ordonnancement permettant d’analyser, et/ou de concevoir,
et/ou d’implémenter des systèmes logiciels.
 Un ordonnancement d’étapes peut être en tout ou partie séquentiel, et/ou
parallèle et/ou itératif.
20
 Etapes générales de développement SI – Approche Objet

 Le développement d'un SI est une activité complexe qui implique
plusieurs étapes dont les principales sont:
 1. Spécification initiale:
 collaboration entre les analystes métier et les utilisateurs pour la genèse de
l’application
 2. Analyse:
 Étude et (re)formulation des besoins : collaboration avec le client pour
comprendre le problème
 Modèles d’analyse :
 abstraction concise et précise de l’objectif du système à développer(pas
de la façon de le construire) et du domaine
 Modèle de domaine: description des objets du monde réel manipulés par le
système
 Modèle de l'application: parties du système visibles par l’utilisateur
21
 Etapes générales de développement SI – Approche Objet

 3. Conception:
 Stratégie de haut niveau (architecture du système) pour résoudre le
problème posé:
 Établissement des stratégies de conception générales
 Allocations prévisionnelles des ressources
 4. Conception des classes:

 Détails des structures de données et des méthodes de chaque classe
 5. Implémentation
 6. Test
22
 Modélisation
 Le développement d’un système logiciel industriel nécessite la création de
plusieurs modèles
 Modèle : Un modèle est une Vue abstraite (Simplifiée) d’un système, d’un
problème. Un modèle décrit le système par rapport à un point de vue
spécifique et à un certain niveau d’abstraction .
 Un système complexe s’appréhende mieux à travers un petit ensemble de
vues indépendantes
 Intérêt des Modèles:
 Gérer la complexité du système;
 Assurer une cohérence architecturale
 Faciliter la communication entre les membres du Projet.
23
 Langage de Modélisation
 Les modèles s'expriment à l’aide d’un ou plusieurs langages de modélisation
 Un langage de modélisation rigoureux comporte:
 des éléments de modélisation : les concepts de modélisation fondamentaux et leur
sémantique ;
 Une Notation : le rendu visuel des éléments de modélisation ;
 Des directives : des idiomes pour le bon usage du langage.
 Exemples de Langages de Modélisation (LM):

 Entité-Association,
 LM de MERISE,
 LM de SADT,
 UML, etc.
24
25
 UML
Les Grandes lignes de UML
26
 Unified Modelling Language (UML)

 UML est un langage de modélisation
 pour spécifier, visualiser, construire et documenter les éléments d’un
système logiciel.
 adopté en 1997 par l’Object Management Group(OMG http://www.omg.org/)
 Révision des spécifications initiales en 2001 –UML 1
 Approbation de la version UML 2.0 en 2004
 Depuis 2017 : UML 2.5.1
 UML est le langage de modélisation visuel le plus utilisé pour
construire les systèmes Orientés Objets .
 UML Fusionne des Concepts de trois méthodes : OMT, BOOCH et
OOSE
27
 Contenu UML
 La Sémantique UML
 Le Guide Notation UML
 Profils :
 Processus de Développement,
 Modélisation Métier,…
 Object Constraint Language (OCL)

28
 Éléments de Base de UML

 Éléments de Modélisation:
 classes, interfaces, cas d’utilisation, etc.
 Relations :
 association, généralisation, dépendances, etc.
 Diagrammes
 diagramme des cas d’utilisation, des classes, d’interaction, etc.
29
 Les Diagrammes UML

 Les diagrammes UML permettent de définir une application selon
plusieurs points de vue
 Fonctionnel (cas d'utilisation)

 Statique (classes, objets, structure composite)
 Dynamique (séquence, états, activité, interaction, communication, temps)
 Implémentation (composants, déploiement, paquetage)
 Les diagrammes seuls ne permettent pas de définir toutes les contraintes

de spécification requises
 Utilisation du langage textuel de contraintes OCL en complément pour
définir des contraintes s'appliquant aux éléments des diagrammes.
UML – Les Grandes lignes
30

 UML permet de modéliser différents aspects d’un système a travers
plusieurs types de modèles:
 Le diagramme de Classes.
 Montre les classes du système avec leurs attributs et méthodes ainsi que les
relations et dépendances
 Le diagramme d’Objets.
 Montre des graphes d’instances (objets) qui peuvent exister pendant
l’exécution du système. Sert à Illustrer des structures de classes
compliquées.
 Les diagrammes de Package.

 Organisent les éléments de modélisation en groupes avec pour objectif de
rendre les diagrammes plus simples et plus faciles à comprendre.
31

 Les diagrammes de Structure Composite
 Explorent les instances des classes collaborant à travers des liens de
communications.
 Les diagrammes de cas d’utilisation
 Montrent les utilisateurs et leurs interactions avec le système. Structurent les
fonctionnalités offertes par le système.
 Les diagrammes de séquence.
 Montrent des exemples d’historique de communication entre les objets ou les
utilisateurs.
 Les diagrammes de Communication (collaboration)
 sont une forme spéciale de diagramme d’objets enrichis avec des
informations sur le flot des messages entre objets et sur la
création/destruction des objets.
32

 Diagramme Global d’Interaction (Overview Interaction)
 Une variante du diagramme d’activité qui donne une vue globale d’un flot de
contrôle.
 Diagramme de Temps (Timing Diagram)

 Explore le comportement d’un ou plusieurs objets pendant une période de
temps donnée.
 Diagrammes d’Etats des Classes

 Utilisés pour modéliser l’état des données et leurs changements durant le
cycle de vie des objets instances des classes du diagramme de classe.
 Diagrammes d’Activités
 Une forme spéciale de diagramme de transition d’états utilisé pour modéliser
l’état du contrôle
33

 Les diagrammes des composants.
 Montrent la structure du code et son partitionnement en composants.
 Les diagrammes de déploiement

 Montrent la structure de l’implémentation en Exécution et la distribution des
objets et composants sur les nœuds physiques .
34
 Modèle des Cas d’Utilisation

Modèle des Cas d’Utilisation
35
 Modèle des Cas d’Utilisation :

 C’est un modèle fonctionnel, une Vue du Système qui montre le
comportement du système tel qu’il est perçu par les utilisateurs
externes.
 Il Détermine et Partitionne les fonctionnalités du système en
transactions (cas d’utilisation) significatives pour les utilisateurs.
 Il constitue un Vecteur de communication entre clients, utilisateurs
finals et développeurs sur les fonctionnalités et comportement du
système.
S. KOUSSOUBE
36
 Les Concepts du Modèle

 Acteur
 Un acteur représente un ensemble cohérent de rôles qu’un utilisateur ou
une entité externe peut jouer en interagissant avec le système
 Un acteur peut consulter et/ou modifier directement l’état du système
 Les acteurs sont (principalement):
 Les utilisateurs humains directs : il faut Identifier tous les profils
(administrateur, opérateur,…)
 les autres systèmes connexes qui interagissent directement avec le système
étudié, souvent par le biais de protocoles bidirectionnels.
S. KOUSSOUBE
37
 Les Concepts:
 Acteur (Notation)
« actor »
Opérateur
SYSCOMPTA
Client
S. KOUSSOUBE
38
 Les Concepts du Modèle

 Acteur
 Exemples de questions pour répertorier les acteurs:
 Qui s’intéresse à tel besoin ?
 Dans quelle partie de l’organisation le système sera utilisé?
 Qui doit profiter de l’utilisation du système?
 Qui va fournir telle information au système?
 Qui utilise, ou supprime telle information?
 Qui va maintenir le système?
 Le système utilise-il une ressource externe?
 Une personne joue t-elle plusieurs rôles?
 Plusieurs personnes jouent-elle le même rôle?
 Le système doit-il interagir avec une ancienne application?
 etc.
S. KOUSSOUBE
39
 Les Concepts:
 Cas d’Utilisation:
 Un cas d'utilisation est unité cohérente de fonctionnalité offerte par le
système; il modélise un service rendu par le système
 Un cas d’utilisation comprend :
 séquence de messages échangés entre le système et des agents externes aux
systèmes (acteurs),
 un ensemble d’actions réalisées par le système
Ouvrir un Compte
<nom cas utilisation>

Fermer un Compte
S. KOUSSOUBE
40
 Les Concepts:
 Cas d’Utilisation:
 Problèmes récurrents lors de l'identification des cas d’utilisation:
 Qu’est-ce qu’un Bon Cas d’Utilisation?
 Quel niveau de détail dans un Cas d’Utilisation?

 Un Cas d’utilisation doit correspondre à une séquence de transactions
réalisées par le système et qui a un résultat significatif et mesurable pour un
acteur particulier.
 Un Cas d’Utilisation représente une unité majeure de fonctionnalité qui est
complète.
 Un cas d’utilisation est constitué de plusieurs scénarii.

S. KOUSSOUBE
41
 Les Relations:
 spécialisation/généralisation d’acteurs
 Une généralisation de A vers B spécifie que l’acteur A est une spécialisation
de l’acteur B. : une instance de A peut communiquer avec les mêmes C.U.
que les instance de B.
Agent
Chef Service
S. KOUSSOUBE
42
 Les Relations:
 communication, association entre acteurs et cas d’utilisation
 Cette relation indique qu’un acteur participe à un cas d'utilisation. La
navigation (si elle existe) indique qui de l’acteur ou du C.U. initie la
communication
A « acteur »
SYSCOMPTA
Agent B
C
Chef Service
S. KOUSSOUBE
43
 Les Relations:
 spécialisation/généralisation des cas d'utilisation
 Cette relation indique qu’un cas d’utilisation D est un cas spécifique d'un cas
d'utilisation plus général C.
A « acteur »
SYSCOMPTA
Agent B
C
Chef Service D E
S. KOUSSOUBE
44
 Les Relations:
 Dépendance (inclusion et extension) entre cas d'utilisation
 A inclut F : une instance de A contient le comportement spécifié par F.
 G étend E : une instance de E peut être augmentée (sous certaines conditions
spécifiques) par le comportement de G
A « acteur »
SYSCOMPTA
Agent B « includes»
C
F
G
Chef Service D E « extends»
S. KOUSSOUBE
45
 Diagramme des Cas d’Utilisation

 Un DCU est une vue graphique de tout ou partie des acteurs, des cas
d’utilisations et de leurs interactions.
 En pratique on construit plusieurs diagrammes de C.U. :
 Un DCU principal: qui montre les acteurs et les principales fonctionnalités
du système.
 Des DCU particuliers (par acteur, un CU et ses relations etc.)
S. KOUSSOUBE
46
 Documentation des Cas d’Utilisation

 Description Textuelle : présente sous forme de texte le déroulement du
CU
 Sommaire d’Identification (obligatoire) :
 titre du CU, acteurs, date de création etc.
 Description des Enchaînements (obligatoire) :
 scénarii nominaux, alternatifs, d’exception
 Besoins en IHM (Optionnel)
 Contraintes non fonctionnelles (optionnel) :
 fréquence, volumétrie, disponibilité, fiabilité, intégrité, confidentialité,
performance
 Pré/Post Conditions
 Autres descriptions
 Diagramme de Séquence Système
 Diagramme d’Activité S. KOUSSOUBE
47
48
 Diagrammes de structure Statique

 Diagramme des Classes
Diagrammes de structure Statique
49
 Modèle structurel:
 C’est un modèle conceptuel, une vue du système qui montre la structure
des objets (et leurs classes), leurs relations, attributs et opérations.
 Deux types de Diagrammes Statiques:

 Diagrammes des Classes (vue des classes),
 Diagrammes d’Objets (vue des instances)
S. KOUSSOUBE
Le Diagramme des Classes
50
 Diagramme des Classes

 C’est un graphe qui montre les classes du système les relations entre elles
ainsi que les attributs et les opérations de ces classes.
 Définition des classes existantes
 Définition de la structure interne des classes (attributs, opérations)
 Définition des relations entre les classes (2 principaux types de relations )
 Association (exemple.: un client peut passer une commande)
 Sous-typage/généralisation (exemple: un étudiant est une personne)
 Le diagramme des classes est utilisé généralement pour:

 Explorer les concepts du domaine (modèle du domaine)
 Analyser les besoins (modèle d’analyse conceptuel)
 Définir la conception détaillée d’un système.
S. KOUSSOUBE
51
 Organisation du diagramme des classes

 le diagramme des classes peut être organisés en paquetage pour gérer
 Chaque paquetage contient un nombre relativement faible de classe.
 Exemple d’organisation en paquetages
Gestion des Gestion des

Clients Fournisseurs
S. KOUSSOUBE
52
 Classe :
 Une classe représente un concept dans le système.
 personne, place, chose, concept, événement, écran, ou rapport, etc.
 Une classe est le descripteur d’un ensemble d’objets ayant une structure, un
comportement et des relations similaires.
 Une classe sert de moule (template) à partir duquel des objets sont créés.
 Sur le plan de la programmation, les classes sont les blocs constitutifs d’une application
orientée objet.
S. KOUSSOUBE
53
 Classe
 Notation : rectangle à trois compartiments
Nom + propriétés générales
Attributs
Opérations
 les Deux derniers compartiments sont optionnels

S. KOUSSOUBE
54
 Classe
 Exemple1
Noms + Fenêtre
[propriétés Générales] {abstrait, auteur= SK, statut = testé }
+taille : Zone = (100, 100)

Attributs #visibilité :Booléen= invisible
+taillepardéfaut : Rectangle
#taille_max : Rectangle
-xptr : XWindow*
+afficher()
Méthodes +cacher()
+créer()
S. KOUSSOUBE
55
 Classe
 Attribut d’une classe :
 Un attribut est une information (une propriété) relative à un objet stockée par
l’objet ou au moins temporairement maintenue.
 Syntaxe UML d'un attribut:
 visibilité nom [multiplicité] : Type = val initiale {propriétés}
 Visibilité d'un attribut :
 + (public), # (protected), - (private)
 Multiplicité:
 Nombre d’occurrence (par défaut [1..1])
 Exemples: coul[3] : Couleur ; points[2..*] : Point ; adr: Adresse
S. KOUSSOUBE
56
 Classe
 Attribut d’une classe :
 Attribut de classe :
 Attribut dans la valeur est partagée par toutes les instances de la classe.
 Syntaxe UML: on souligne l’attribut.
 Exemple: + taillepardéfaut : Rectangle dans la classe Fenetre.
 Attribut dérivé :
 Attribut dans la valeur peut être calculée à partir des autres attributs.
 Syntaxe UML: on préfixe l’attribut avec le symbole /
 Exemple: /age
 Propriété
 {frozen} : attribut non modifiable
S. KOUSSOUBE
57
 Classe
 Opération d’une classe:
 Un opération est un traitement ou une transformation que l’on peut effectuer sur
les objets d'une classe .
 Syntaxe UML d'une opération :
 visibilité nom(liste de paramètres) : type de retour {propriétés}
 Visibilité d'une opération :
 idem que pour les attributs Multiplicité:
 paramètres formels d'une opération :
 séparés par des virgules.
 syntaxe : nature nom : type = valeur par défaut
 nature : in , out , inout
S. KOUSSOUBE
58
 Classe
 Opération d’une classe :
 Opération de classe :
 Opération qui n'utilise pas de variables d’instances (n’utilise que des attributs de
classe).
 Syntaxe UML: on souligne l’opération.
 Exemple: + SetTaillepardéfaut (in t: Rectangle) dans la classe Fenetre.
 Propriétés d’une opération:

 {query} : méthode ne modifiant pas l’état du système
 {update} : modifie l’état du système
 {abstract} : méthode non implémentée (ou en italique)
 {concurrency = séquential/guarded/concurrent}
 Documentation dune opération

 note attachée à l’opération (ex. algorithme)
S. KOUSSOUBE
59
 Classe
 Opération d’une classe:
S. KOUSSOUBE
60
 Classe
 stéréotypes des classes:
 Les stéréotypes permettent de classifier les classes par rapport à leur rôle dans le
modèle.
 Les stéréotypes usuels :

 boundary,
 entity,
 control,
 exception,
 metaclass,
 utility.
S. KOUSSOUBE
61
 Classe
 Stéréotype boundary (frontière) :
 caractérise une classe modélisant la communication entre le système et son
environnement. C'est une classe se trouvant à la périphérie du système tout en étant à
l’intérieur du système. Un objet boundary interagit avec les acteurs et les autres
objets:
« boundary »
 Exemple FormCreationCompte
 Fenêtre (interface utilisateur),
 Protocole de Communication (interface système),
 Interface Imprimantes
 etc.
FormCreationCompte
S. KOUSSOUBE
62
 Classe
 Stéréotype boundary (frontière) :
« boundary » « boundary »
FormCreationCompte Impression
FormCreationCompte
S. KOUSSOUBE
63
 Classe
 Stéréotype entity:
 Classe généralement persistante modélisant une information (avec le comportement
associé). C'est une classe passive (non initiatrice d’interactions) qui peut participer à la
réalisation de plusieurs cas d’utilisation.
 Exemple
« entity »
 Compte Bancaire, Facture
 Commande Compte
 Facture
 etc.
S. KOUSSOUBE
64
 Classe
 Stéréotype Control :
 C 'est une classe qui contrôle les interactions d’une collection d’objets. Elle modélise
le comportement spécifique d’un (ou plusieurs) cas d’utilisation. En définitive ce sont
les classes ''control'' qui détiennent la logique applicative.
 Crée, initialise et détruit les objets contrôlés ;

 Contrôle le séquencement et la coordination des opérations exécutées par les objets
contrôlés ;
 Gèrent les aspects « concurrence ».
 Est généralement l’implémentation d’un objet intangible.
 Est généralement détruit à la fin de la réalisation du CU FactureManager
S. KOUSSOUBE
65
 Relations entre Classe

 Il existe plusieurs types de relations entre classes:
 Association
 Association binaire, association n-aire
 Agrégation, composition,
 Généralisation/Spécialisation (héritage)
 Relation (dépendance, …)
S. KOUSSOUBE
66
 Associations entre Classes

 Une association définit une relation sémantique pluridirectionnelle entre des
classes.
 Association binaire : Association mettant en relation deux classes
 Association n-aire : Association mettant en relation plus de deux classes.
 Classe association : association qui a des propriétés similaires à celles d’une
classe (attributs, opérations, autres associations)
Nota: un lien est une connexion physique on conceptuelle entre objets

(un lien est une instance d’une association)
S. KOUSSOUBE
67
Classe 1 nom
Classe 2
Association binaire
Classe Classe 1
Association Réflexive nom
Classe 2 Classe 3
S. KOUSSOUBE Association
ternaire
68
Etudiant est inscrit

Filiere
Association binaire
Employe Commande
est chef de
Association
Réflexive
Client Produit
S. KOUSSOUBE Association
ternaire
69

 Classe-Association :
 est une association porteuse d'informations
 Ayant des attributs, l'association est promue en classe
Abonné emprunte
Document
InfoPrêt
date
S. KOUSSOUBE
70

 Classe-Association :
Abonné emprunte
Document
date_emprunt
S. KOUSSOUBE
71

 Informations spécifiant une association:
 Nom de rôle
 Nécessaire pour les associations réflexives
 Navigation
 Indicateur de d’agrégation
 Multiplicité
 propriétés :
 {frozen} , {addOnly}
 {ordered}: ensemble ordonné d’objets liés (sans doublon)
 {sequence}: ordonné, doublon autorisé
 {bag} : non ordonné
multiplicité A nom multiplicité B
Classe A Classe B
rôle A rôle B
S. KOUSSOUBE
72

 Informations spécifiant une association -Exemple
ordered
Fenêtre Ecran
* visible sur 1
Parcours Ville
1 sequence *
S. KOUSSOUBE
Association: Extrémités
73

 Multiplicité d’une classe dans une association :
 nombre d’éléments de la classe pouvant être en relation avec une instance de l’autre
classe. Sa valeur est une chaîne comprenant une séquence d’intervalles d’entiers
Indicateur Signification
0..1 Zéro ou un
1 Un seul
0..* Zéro ou plus
1..* 1 ou plus
n N seulement (n > 1)
0..n 0 à n (n > 1)
1..n 1 à n (n > 1)
S. KOUSSOUBE
74
 Agrégation :
 association non symétrique dans laquelle une des classe joue un rôle
prédominant par rapport à l’autre
1..* 2..*
Formation Cours
S. KOUSSOUBE
75
 Composition:
 Agrégation forte, avec une coïncidence du cycle de vie d’une partie avec
celle d’un tout (contenance physique). La multiplicité de l’agrégat <= 1
(Non partage)

1 2..*
Immeuble Appartement
S. KOUSSOUBE
76
 Généralisation
 La généralisation représente la relation taxonomique entre un élément plus général
(le parent, la superclasse) et un élément plus spécifique (le fils, la sous-classe).
 Objectifs de la généralisation:
 Prise en charge du polymorphisme
 Structuration de la description des objets
 Possibilité de réutiliser du code
 Contraintes:
 Disjoint : Aucun ancêtre ne peut avoir deux fils; son contraire = overlapping
 Complet : tous les fils ont été spécifiés; contraire = Incomplet
S. KOUSSOUBE
77
 Généralisation
Arbre
{disjoint, incomplet}
Okoumé Ozigo
S. KOUSSOUBE
78
 Comment trouver les Classes

 Pas de recettes miracles (Grady Booch: « This is hard »)
 Plusieurs techniques
 On peut se baser la distinction des catégories de classes: « boundary », « control » et
« entity » Conformément au point de vue model-view-controller
 Exploiter la description textuelles des cas d’utilisation
 Etc.
 Plusieurs modèles de classes

 Classes d’Analyse : essentiellement un modèle du domaine construit avec les experts métiers
 Classe de Conception
 Classe d’Implémentation
S. KOUSSOUBE
79
Gestion de la Persistance
dans un Contexte SGBDR
S. KOUSSOUBE
Traduction du modèle Objet en Relationnel
80
 Mapping Objet-Relationnel
 Le mapping Objet-Relationnel consiste à traduire le modèle des
classes en modèle de tables pour implanter une base de données
relationnelle
 Il existe plusieurs possibilités de représentions concernant:
 La traduction des associations
 La traduction de la généralisation
 Il faut en outre fournir des détails supplémentaires :
 clés primaires,
 clés candidates,
 valeur null possible?
S. KOUSSOUBE
81
 Représentation des classes d’objets en Tables
 Chaque classe se représente par une (ou plusieurs) tables;
 Les objets d’une classes peuvent être découpés horizontalement et/ou
verticalement;
 Utilisation ou non d’Ids.
S. KOUSSOUBE
82
Représentation des classes d’objets en Tables
Personne
Objet
Modèle
Attibuts Null? Domaine

ID_Pers N ID
de Table
Modèle
nom N TypeNom
adresse O TypeAdr
CREATE TABLE Personne

( ID_Pers ID not null,
SQL
Code
nom char(30) not null,

adresse char(30) not null;
PRIMARY KEY (ID_Pers) );
CREATE SECONDARY INDEX Idx_NomPers on Personne(nom);
S. KOUSSOUBE
83
 Représentation des Associations Binaires
 La représentation d’une association en table ou non dépend de la
multiplicité, des préférences du concepteur (extensibilité, nombre de
tables, compromis de performances)
 Une association plusieurs-à-plusieurs se représente tjrs par une table
distincte. Les clés primaires des deux classes et les attributs
d’association sont des attributs de la table de l’association.
 Une association un-à-plusieurs se représente:
 Soit par une table d’association
 Soit en enfouissant une clé étrangère dans la table pour la classe plusieurs
S. KOUSSOUBE
84
 Avantages de la fusion d’une association dans une classe:
 Moins de tables et
 De meilleures performances
 Inconvénients de la fusion d’une association dans une classe:
 Moins de rigueur dans la conception (l’association se passe entre objets
indépendants de poids égal.  encapsulation)
 Moindre extensibilité (il est difficile d’obtenir une multiplicité définitive
dans les premières passes de la conception)
 Plus de complexité: la représentation asymétrique de l’association
complique les recherches et les mises à jour.
 On peut fusionner plus encore une association un-à-un et les deux objets dans une
seule table. Mais Attention aux associations cycliques (A::B, B::C, C::A. Il serait
incorrect de replier ces trois classes et ces trois associations dans une seule table)
S. KOUSSOUBE
85
Modèle Objet
possède_actions Entreprise
Personne
nom nom
adresse adresse
type
nbrActions
Attributs Null? Domaine

de Table
Modèle
ID_Pers N ID possède _actions

ID_Entr N ID
nbrActions O TNbrA
Entreprise
Attributs Attributs
nom nom
adresse adresse
type
Personne
86
Créer Table et Index pour Personne

…
Créer Table et Index pour Entreprise
Code SQL
CREATE TABLE possède-actions

( ID-Pers ID not null,
ID-Entr ID not null,
nbrActions integer,
PRIMARY KEY (ID-Pers, ID-Entr) ,
FOREIGN KEY (ID-Pers) REFERENCES Personne,
FOREIGN KEY (ID-Pers, ID-Entr) REFERENCES Entreprise);
CREATE SECONDARY INDEX Idx_PAPers on possède-actions (ID-Pers);

CREATE SECONDARY INDEX Idx_PAEntr on possède-actions (ID-Entr);
S. KOUSSOUBE
87

Personne * travaille-pour 0..1 Entreprise
nom nom
adresse adresse
fonction

ID_Pers N ID ID_Pers N ID
ID_Entr N ID
nom N Tnom
nbrActions O TNbrA
adresse O TAdr
Travaille-pour ID_Entr O ID
Personne
fonction O TFonc
88
 Représentation des Associations n-naires
Équipe
Lanceur Année
Victoires
défaites
T[ID-Lanceur, ID-Equipe, ID-Année, victoires, défaites]
S. KOUSSOUBE
89
 Représentation des Généralisations

 Plusieurs Approches:
1. La superclasse et les sous-classes
 La superclasse et les sous-classes sont chacune représentées par une
table.
 L’identité d’un objet est préservée à travers un ID partagé.
 Logiquement propre mais beaucoup de tables; de plus la navigation
entre les tables super et sous-classes est potentiellement lente
2. Approche « Plusieurs sous-classes » :

 Élimine La table de la superclasse et réplique tous les attributs de la
superclasse dans chaque table de sous-classes.
3. Approches « Une table de super-classe » :

 Remonte tous les attributs des sous-classes vers la superclasse.
S. KOUSSOUBE
90
Bibliographie
91
 Pascal Roques: UML2 par la pratique: Études de cas et exercices corrigés ,

Eyrolles, 2011
 Benoît Charroux, Aomar Osmani, et YannThierry-Mieg : UML2,

coll. Synthex, Pearson Education, 3e édition,2010
S. KOUSSOUBE

Si Analyse-Conception Objet L3 - Partie 1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Si Analyse-Conception Objet L3 - Partie 1

Transféré par

Droits d'auteur :

Formats disponibles

1

Processus Métier Technologie de

Les niveaux de modélisation des données

 Constituants du Label « Orienté Objet »

 Méthodes – Processus- Langages

 Etapes générales de développement SI – Approche Objet

 Etapes générales de développement SI – Approche Objet

 4. Conception des classes:

 Exemples de Langages de Modélisation (LM):

 Unified Modelling Language (UML)

 Object Constraint Language (OCL)

 Éléments de Base de UML

 Les Diagrammes UML

 Fonctionnel (cas d'utilisation)

 Les diagrammes seuls ne permettent pas de définir toutes les contraintes

 Les Diagrammes UML

 Les diagrammes de Package.

 Les Diagrammes UML

 Les Diagrammes UML

 Diagramme de Temps (Timing Diagram)

 Diagrammes d’Etats des Classes

 Les Diagrammes UML

 Les diagrammes de déploiement

 Modèle des Cas d’Utilisation

 Modèle des Cas d’Utilisation :

 Les Concepts du Modèle

 Les Concepts du Modèle

<nom cas utilisation>

 Quel niveau de détail dans un Cas d’Utilisation?

 Diagramme des Cas d’Utilisation

 Documentation des Cas d’Utilisation

 Diagrammes de structure Statique

 Deux types de Diagrammes Statiques:

 Diagramme des Classes

 Le diagramme des classes est utilisé généralement pour:

 Organisation du diagramme des classes

 Exemple d’organisation en paquetages

Gestion des Gestion des

Nom + propriétés générales

 les Deux derniers compartiments sont optionnels

+taille : Zone = (100, 100)

 Propriétés d’une opération:

 Documentation dune opération

 Les stéréotypes usuels :

 Crée, initialise et détruit les objets contrôlés ;

 Relations entre Classe

 Associations entre Classes

Nota: un lien est une connexion physique on conceptuelle entre objets

 Associations entre Classes

Association Réflexive nom

 Associations entre Classes

Etudiant est inscrit

 Associations entre Classes

 Associations entre Classes

 Associations entre Classes

 Associations entre Classes

 Associations entre Classes

 Associations entre Classes

 Associations entre Classes

 Comment trouver les Classes

 Plusieurs modèles de classes

Représentation des classes d’objets en Tables

Attibuts Null? Domaine