Uml2 LMD2

[1]
Préambule
Comment peut-on savoir qu’une fonction support de l’entreprise apporte
une vraie valeur ajoutée ? Comment la mesurer pour comprendre son
niveau de performance en vue de l’améliorer ? Ces questions conduisent à
une interrogation encore plus fondamentale : faut-il externaliser une
fonction support ou non ? Grande décision qui se présente aux responsables
d’entreprise aujourd’hui, mais qui, jusqu’à maintenant, restait sans
véritable outil pour trancher de façon objective.
En tant qu’enseignant qui encadre les futures responsables d’entreprise,

nous faisions « de notre mieux », conscients de l’absence d’un outil qui
nous permettrait d’adopter une méthode à la hauteur des conséquences –
car c’est la vie professionnelle et, quelquefois, personnelle de nos
collaborateurs qui est en jeu.
Cependant, à la lecture de ce support, vous aller découvrir une méthode

d’une grande clarté et d’une grande simplicité, qui permet d’évaluer une
fonction de contrôle de gestion d’une manière automatique quel que soit
l’approche Web ou Windows, trouver les points à améliorer, savoir aussi
ce qu’il faut externaliser et ce qu’il faut garder. Pour une prise de décision
qui peut être lourde de conséquences : garder une fonction et lancer des
plans de progrès, ou externaliser la fonction.
Nous sommes heureux Mr. Le Prof. Dr. Ir. Mbikayi et Mr. Le CT. Ir.
Balumangani que le langage UML2 que vous allez suivre tous ensemble et
surtout avec vous les étudiants de L1 ISS-Kin soit maintenant appliquée
dans la Conception de Système d’Information et pourquoi pas dans tous les
mémoires des ingénieurs concepteurs. Pour rester dans la course à la
compétitivité, les organisations doivent aligner leur système
d’information, véritable comme colonne vertébrale de l’entreprise, et à
leurs objectifs des business. Ce support permet aux responsables de le
faire, avec un outil simple et puissant pour prendre les décisions
stratégiques sur des bases robustes.
OBJECTIFS DU COURS
Permettre aux étudiants en informatique de gestion de l’I.S.S-KIN de doter

d’un guide de modélisation en UML2 précis, à jour, mais néanmoins léger
pour mieux spécifier et réaliser les applications web. Il ne s’agit pas d’un
long exposé théorique mais bien plutôt de conseils concrets et
pragmatiques, illustrés pas à pas grâce à une étude approfondie des
différents cas.
Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 1 sur

[2]
À la fin de ce cours de Conception de Système d’Information le participant

(Étudiant) sera capable de :
✓ Décrire, de comprendre et d’analyser efficacement plusieurs aspects

d’un système d’information à l’aide d’un certain nombre des modèles
orientes objets ;
✓ Différencier les différentes méthodes de conception des systèmes
d’information ;
✓ Comprendre les objectifs du langage de modélisation UML2
contrairement à d’autres méthodes ;
✓ Comprendre les différentes phases de conception du langage UML et
formaliser les différents diagrammes à cet effet ;
✓ Recenser les responsabilités et les tâches des différents acteurs
impliqués dans la conception d’un système d’information ;
✓ Élaborer son mémoire de l’informatique en utilisant une approche
objet.
Définitions des quelques concepts
• OMGL = Outils et Modèles pour le Génie Logiciel

• Outil : logiciel supportant une méthode
• Modèle : représentation schématique de la réalité
• Logiciel : ensemble des programmes, procédés et règles, et
éventuellement de la documentation, relatifs au fonctionnement d'un
ensemble de traitements de l'information
• Génie Logiciel (ou l'ingénierie des systèmes d'information : ensemble
des activités de conception et de mise en œuvre des produits et des
procédures tendant à rationaliser la production du logiciel et de son
suivi
• Analyse : processus d'examen de l'existant
• Conception : processus de définition de la future application
informatique
• Systèmes d'Information : ensemble des moyens (humains et
matériels) et des méthodes se rapportant au traitement de
l'information d'une organisation
• Bases de Données : ensemble des données (de l'organisation)
structurées et liées entre elles :
➢ Stocké sur support à accès direct (disque magnétique)
➢ Géré par un SGBD (Système de Gestion de Bases de Données)
➢ Accessible par un ensemble d'applications
Enjeux de l’informatisation pour l'organisation
• Augmenter la productivité en améliorant l’efficacité des utilisateurs

• Améliorer les conditions de travail : enrichissement des tâches
• Rendre un meilleur service (de qualité, rapide, etc.) aux partenaires de
l'organisation.

[3]
Facteurs de la complexité de l'informatisation
• Difficultés techniques de l'informatique : complexité de la mise en œuvre

des matériels, complexité de la construction logicielle, réflexion abstraite,
contraintes techniques
• Constantes novations (matérielle et logicielle)
• Symbiose requise entre l'application informatique et toute l'organisation
(et ses partenaires)
Qui fait quoi dans la conception du système d’information (CSI) ?
QUI QUOI
Maître d’ouvrage Exprime les besoins dans un cahier de
(utilisateur) charges
Analyste Comprend les besoins exprimés par
l’utilisateur et produit le diagramme de
cas d’utilisation et le diagramme de
séquence.
Architecte (concepteur) Conçoit les besoins compris et produit le
diagramme de classe et les autres
diagrammes nécessaires pour
l’accompagnement.
Programmeur Réalise les besoins conçus.
(développeur)
Testeur Test le besoin réalisé
Introduction
C’est au début des années 1950 que sont nées les premières réflexions
publiques sur la conduite d’un projet, principalement dans les pays anglo-
saxons. Elles sont liées aux grands projets engagés dans divers domaines
industriels : aéronautique, travaux publics, armement. L’objectif était de
développer des techniques et des méthodes pour augmenter la maîtrise des
travaux et la coordination des différents corps de métier. Historiquement,
ce développement s’est inscrit dans le courant de la recherche
opérationnelle, qui visait une formalisation mathématique des problèmes
de gestion pour prendre les décisions optimales. Il a correspondu
également au grand mouvement de planification mis en œuvre dans la
plupart des pays développés et qui a influencé certaines théories
managériales. Le corpus méthodologique sur la conduite de projet s’est
ensuite constitué en grande partie par la pratique. Les sociétés de services
et de conseil, ainsi que de nombreux consultants indépendants, ont
développé une offre variée de prestations qui comprennent la direction
d’un projet ; l’assistance au chef de projet sur certains aspects, tels que la
planification et la surveillance des délais ou des coûts, la gestion de la

[4]
qualité du projet, la gestion administrative du projet… ; le conseil ponctuel

pour certaines tâches telles que le découpage et l’organisation du projet ou
l’estimation des charges.1
Problématique du management de projet
Leurs actions ont conduit à une diffusion et une reconnaissance des

certifications en management de projet, qui valident l’acquisition de
savoirs et savoir-faire spécifiques.
Citons notamment l’AFITEP (Association francophone de management de
projet), l’IPMA (International Project Management Association) d’origine
européenne et le PMI (Project Management Institute) d’origine nord-
américaine.
En ce qui concerne les techniques, la planification a occupé pendant

longtemps une place centrale dans la conduite d’un projet. Certaines
fonctions spécifiques de planificateur ont existé jusqu’à récemment. On a
aujourd’hui une vision plus large du rôle du chef de projet. Par ailleurs,
l’origine industrielle a fortement marqué le découpage d’un projet ; dans
le domaine des systèmes d’information, il a fallu des années pour que
d’autres approches apparaissent. Nous allons maintenant voir comment est
défini un projet et quelles sont les activités qui relèvent du management de
projet.
Définitions d’un Projet
 L’approche générale
La langue française a attaché au mot projet des degrés de précision divers.

Le terme représente d’abord une intention, souvent floue, dont la
réalisation peut être lointaine ; c’est par exemple le cas lorsque l’on évoque
un projet d’informatisation d’une entreprise.
Une seconde définition le décrit comme une étude préparatoire, parfois

exhaustive, qui va être soumise à décision : on parle ainsi d’un projet de loi
ou d’un projet d’urbanisme. Quelle que soit l’acception retenue, le projet
précède une réalisation ou un état définitif. C’est une image plus ou moins
précise d’un futur que l’on pense atteindre. Dans ce support, nous utilisons
le mot projet dans un sens orienté vers le management de projet
informatique.
Un projet est défini comme un ensemble d’activités à effectuer pour

atteindre un but défini de façon spécifique. De façon plus précise, on parle
de « travail en mode projet » lorsque l’on doit atteindre un objectif avec
1
Chantal Morley, Management d’un Projet SI, édition 6 ème Dunod, Page : 28

[5]
des moyens ad hoc et dans un délai donné. Le mode projet requiert une
organisation et un management adaptés. On le représente parfois sous
forme d’un triangle qui exprime la contrainte de solidarité entre les
sommets : si l’un des sommets bouge et que l’on veut conserver le même
triangle, il faut agir sur l’un ou les deux autres sommets. Ainsi, toute
évolution du périmètre du projet aura des conséquences soit sur le délai,
soit sur les ressources à mettre en œuvre. Un aléa modifiant la disponibilité
des ressources se répercutera soit sur le délai, soit sur l’objectif visé. Le
mode Projet se distingue de celui d’une activité répétitive ou d’une mission
permanente.
Une activité répétitive est la réponse à une occurrence d’événement

déclencheur préalablement identifié dans l’entreprise. On peut définir une
procédure stable pour décrire les activités à accomplir.
Ainsi un acheteur dans un service d’Approvisionnement déclenche la
procédure Commande chaque fois qu’un besoin d’achat se manifeste. À
l’inverse, le lancement d’un projet relève d’une décision.
Tout projet est unique et ne peut être traité par un dispositif standard. Il
nécessite une prise en compte de ses caractéristiques propres. De son côté,
une mission permanente est définie par un but, mais sans mention de délai
; elle subsiste jusqu’à une décision de réorganisation. Ainsi, une mission
qualité dans l’entreprise doit mettre en œuvre un ensemble d’activités pour
surveiller et augmenter la qualité : définir des critères qualité, identifier
les mesures à effectuer, traiter les écarts… Le responsable de la mission ne
peut en prononcer la suppression.
Tout projet est, au contraire, temporaire : par nature, il est destiné à

s’achever à un horizon visible. Les ressources sont affectées pour une durée
limitée. C’est aux responsables du projet qu’il revient de déclarer que celui-
ci est terminé. Le mode Projet introduit du mouvement dans un dispositif
organisationnel stable. Cela provient de ce que l’on entreprend quelque
chose de nouveau. L’effet est renforcé par les affectations temporaires des
acteurs. Cette instabilité souvent dynamisante est parfois recherchée pour
des activités traditionnellement effectuées dans de missions globales.
 Les définitions normalisées
Le référentiel du PMI, appelé Guide du PMBOK (Project Management Body

of Knowledge), donne d’un projet la définition suivante : « entreprise
temporaire décidée pour obtenir un produit ou un service unique ».
L’unicité du produit entraînera celle des activités à mettre en œuvre.
L’AFITEP et l’AFNOR définissent un projet comme un « ensemble d’actions
à réaliser pour satisfaire un objectif défini, dans le cadre d’une mission
précise, et pour la réalisation desquelles on a identifié non seulement un
début, mais aussi une fin ».

[6]
Une distinction est introduite entre les projets d’ingénierie qui visent
l’obtention d’un résultat pour un client, et les projets produit débouchant
sur un modèle qui fera ensuite l’objet d’une fabrication répétitive. Les
projets de système d’information relèvent exclusivement de la première
catégorie. Chacune de ces trois définitions met l’accent sur des activités
finalisées et soumises à contraintes, nous y retrouvons les trois éléments
du triangle Projet : objectif, moyens, délai.
Le contenu de cette norme, intitulée « Systèmes de management de la

qualité. Lignes directrices pour le management de la qualité dans les
projets » est exposé au management de projet par le but de mener un
projet à son terme en organisant et en surveillant son déroulement. Le
champ du management de projet est calé sur les caractéristiques
génériques d’un projet. Les trois aspects représentés par le triangle Projet
doivent être mis sous contrôle. Chacun fait l’objet d’un management
spécifique, qui prend en compte l’existence des deux autres ; chaque
sommet du triangle Projet en génère un autre, le tout formant un nouveau
triangle, celui du management de projet. Ainsi :
• Le délai donne lieu à un management du temps dont le rôle est de définir

le parcours et de le jalonner, d’établir des calendriers et de maîtriser la
consommation de l’enveloppe temps.
• Les moyens affectés constituent le budget du projet, qui est transformé

en travail, locaux, matériel, temps machine, déplacement… Cette
transformation nécessite un management des ressources portant sur les
ressources humaines et les moyens matériels. Dans les projets système
d’information, les ressources humaines occupent une place primordiale.
Utiliser chacun au mieux, constitué des équipes efficaces, affecter les
personnes au moment adéquat en fonction de leurs compétences,
coordonné les travaux, limiter le nombre d’acteurs sans pour autant
exclure… telles sont les attributions de cette fonction.
• L’objectif du projet doit à son terme être concrétisé par une ou plusieurs
fournitures. Ce sommet donne naissance au management de la production,
qui a pour but de suivre et diriger l’avancement vers l’objectif tout au long
du projet. On parle parfois de « faire converger le projet » : cela signifie
qu’il faut sans cesse s’assurer que l’on se rapproche du but et que l’on ne
part pas dans des directions remettant en cause un avancement consolidé.
En se référant à la description classique d’une fonction managériale, on

peut décomposer l’activité de management de projet en trois activités
principales autour de la production proprement dite.

[7]
• Analyser : il s’agit de déterminer le chemin que l’on va emprunter pour

avancer vers l’objectif. Pour cela, on étudie les caractéristiques du projet,
son contexte, les risques qui le menacent et l’état de son avancement.
Cela conduit à un découpage du projet en activités à entreprendre et à une
estimation de l’effort nécessaire. La maille de cette analyse varie selon le
moment du projet auquel on se place.
• Organiser : on repère les contraintes d’enchaînement entre les tâches afin

de les ordonnancer. Cela permet d’établir un calendrier. L’organisation
recouvre aussi la constitution d’une équipe, c’est-à-dire des personnes qui
sont affectées et imputées au projet, en déterminant les bons profils. Les
relations avec tous les partenaires nécessaires sont également prises en
compte. Dès que la charge est importante, on répartit le travail entre
plusieurs personnes, voire plusieurs équipes, ce qui conduit à mettre en
place des moyens de partage d’informations pour éviter les incohérences.
• Piloter : cette activité comprend le suivi de l’avancement du projet, en

quantité et en qualité, ainsi que l’analyse et le traitement des écarts avec
ce qui était prévu, les orientations et les décisions à prendre ou à faire
prendre.2
❖ Comment manager des projets Systèmes d’informations
 Caractéristiques d’un projet système d’information
Il convient tout d’abord de rappeler la définition d’un système

d’information, qui met en lumière son caractère complexe. En effet, dans
la mesure où c’est un « ensemble organisé de ressources : matériel, logiciel,
personnel, données, procédures… permettant d’acquérir, de traiter,
stocker, communiquer des informations (sous formes données, textes,
images, sons…) dans des organisations.
Le triplet {objectif, moyens, délai} présente, dans le domaine système

d’information, trois caractéristiques spécifiques, à savoir :
1. Il y a interaction entre l’objectif d’une part et les moyens/délais
d’autre part. Une première identification de l’objectif conduit à
évaluer la charge globale du projet. Cela permet de décider d’une
échéance cible théorique et des moyens à affecter. Si d’autres
contraintes obligent à limiter le délai ou le budget, on ajuste
l’objectif, selon le principe du design-to-cost (conception contrainte
par le budget disponible). Après décision, on va considérer comme
fixes les deux paramètres « moyens » et « délai » initialement alloués
et on évaluera l’efficience du projet composante de son succès par
rapport à ces valeurs.
2
Chantal Morley, op. cité, page : 36

[8]
2. L’objectif du projet n’est parfaitement défini qu’à l’achèvement du

projet. Un système d’information n’est pas un objet matériel, dont on
peut donner une représentation visuelle.
Un logiciel est quelque chose d’abstrait. Il est donc décrit par ses
fonctions ; cependant, une description exhaustive est longue et
coûteuse. Les modèles n’en donnent qu’une vue partielle. La
maquette qu’on peut en faire est une analogie, non une miniature. De
même un prototype n’est pas, comme en milieu industriel, ce qui
précède la série. Cette indétermination est absente des projets
industriels qui ont servi de référence à certaines des techniques,
notamment le découpage du projet. De plus, les modèles de processus
métiers représentant les modifications apportées sont également
abstraites et ne rendent pas en compte du vécu des acteurs qui
s’exprime progressivement.
3. Le développement d’un système d’information ne se déroule pas dans
un vide organisationnel, mais dans une organisation, dont les
particularités font partie de la caractérisation du projet lui-même.
Les comportements des acteurs sont influencés par le système
d’organisation dans lequel ils agissent. Celui-ci comprend à la fois la
répartition du pouvoir et des ressources, la division des activités, les
modes de coordination, les procédures opératoires, les statuts…
4. Les relations personnelles sont régies par un ensemble de normes,
fondées sur les valeurs dominantes de l’entreprise, qui contraignent,
légitiment ou limitent l’action. Les acteurs ne forment pas un groupe
uni vers la réalisation d’un même objectif. Dans les zones
d’incertitude se développent les stratégies des groupes ou des
individus. Si le pouvoir est un enjeu dans tout système
d’organisation, c’est l’efficacité que l’on invoque le plus souvent lors
des choix de conception (rapidité, coût…) d’un système
d’information.
La démarche d’élaboration est généralement guidée par une rationalité

d’optimisation, faisant abstraction d’autres formes de rationalité. Le
processus de développement d’un système d’information est certes un
processus rationnel, mais qui se double souvent d’un processus politique et
d’un processus psychologique. Leur prise en compte permet d’analyser
certaines réactions ou certains conflits, voire de les éviter.
 Les objectifs des projets systèmes d’information
Il est parfois utile de distinguer le système d’information et le système

informatique.
✓ Le système d’information est la partie du réel constituée
d’informations organisées, d’événements ayant un effet sur ces
informations et d’acteurs qui agissent sur ces informations ou à

[9]
partir de ces informations, selon des processus visant une finalité de

gestion et utilisant les technologies de l’information.
✓ Un système informatique est un ensemble organisé d’objets
techniques matériels, logiciels, applications dont la mise en œuvre
réalise l’infrastructure d’un système d’information.
Dans cette perspective, même si un projet système d’information inclut un

développement ou un paramétrage de logiciel, les objectifs du projet sont
clairement ceux qui sont attachés au système d’information. En effet, c’est
l’utilisation que l’on va faire du logiciel l’aide apportée aux processus et les
informations gérées qui va apporter de la valeur à l’entreprise.
La réflexion sur les objectifs des projets s’inscrit donc aujourd’hui dans la
perspective de l’alignement stratégique, selon laquelle la mission du
système d’information est d’aider l’entreprise à atteindre ses objectifs.
Tout projet système d’information est donc toujours un projet de
l’entreprise. Cela implique que les acteurs métiers, que l’on appelle «
maître d’ouvrage », décident des évolutions du système d’information.
Mais également que les orientations stratégiques soient être traduites en
objectifs du système d’information, ce qui fait partie des premières étapes
du projet. Par exemple, diminuer les coûts de gestion peut se traduire par
installer un système de workflow (Travail circulant) ou mettre en place un
suivi de la qualité des fournisseurs.
L’objectif stratégique d’améliorer l’efficacité des promotions peut conduire

à développer un système d’analyse d’effets ou bien un système de suivi des
promotions des concurrents. Augmenter les ventes peut passer par la mise
en place d’un site de vente en ligne ou la conception d’une application

[10]
d’aide à la vente pour les commerciaux. Comprendre les objectifs du projet

et faire émerger des réponses adéquates est de la responsabilité du chef de
projet. On rencontre souvent les grandes catégories suivantes, qui auront
des conséquences sur le management du projet.
Pour les projets système d’information, la complexité est accrue par le

caractère abstrait du logiciel et la difficulté à tester tous les cas de figure
pour en éliminer les dysfonctionnements.
C’est également le cas lorsque l’on met en place un progiciel intégré avec
un haut degré de paramétrage, dont on ne prévoit pas toutes les
conséquences organisationnelles.

[11]
Chapitre I. La Modélisation objet
Le but de la modélisation des systèmes d’information est d’aboutir à une

spécification qui peut être une représentation simplifiée de sa réalité
passive ou active. Ainsi, le recours à la modélisation est depuis longtemps
une pratique indispensable au développement, car un modèle est prévu
pour anticiper les résultats du développement. Un modèle est en effet une
abstraction du résultat, dont le but est de documenter, de prévoir,
d’étudier, de collecter ou d’estimer les informations d’un système. Associé
au processus de développement, un modèle qui représente la vue sur une
spécification ou sur une solution de système, pris à un niveau de détail
pertinent pour exprimer ou concevoir la cible de l’étape en cours.
Le modèle sert donc des objectifs différents suivant l’étape de

développement et sera construit avec des points de vue de plus en plus
détaillés :
❖ Dans les activités de capture des besoins, il convient premièrement
de considérer le système comme une boîte noire à part entière afin
d’étudier sa place dans le système métier plus global qu’est
l’entreprise. On développe pour cela un modèle de niveau contexte,
afin de tracer précisément les frontières fonctionnelles du système ;
❖ Dans les activités d’analyse, le modèle représente le système vu de
l’intérieur. Il se compose d’objets représentant une abstraction des
concepts manipulés par les utilisateurs. Le modèle comprend par
ailleurs deux points de vue, la structure statique et le comportement
dynamique. Il s’agit de deux perspectives différentes qui aident à
compléter la compréhension du système à développer ;
❖ Dans les activités de conception, le modèle correspond aux concepts
qui sont utilisés par les outils, les langages ou les plates-formes de
développement. Le modèle sert ici à étudier, documenter,
communiquer et anticiper une solution. Il est en effet toujours plus
rentable de découvrir une erreur de conception sur un modèle, que
de le découvrir au bout de milliers de lignes codées sans grands
horizons. Pour la conception du déploiement enfin, le modèle
représente également les matériels et les logiciels à interconnecter ;
❖ En dernier lieu, l’utilisation extensive de modèles dans les dernières
phases de conception, ainsi que le caractère systématique qui
s’esquisse dans le passage d’UML2 aux codex ont permis d’élaborer
les fondements de l’approche MDA (Model Driven Architecture) (voir
définition ci-après). Les technologies sont en constante évolution.
Afin de bénéficier des avancées technologiques, il est nécessaire
d'adapter les applications à ces technologies. Or cette opération
coûte cher aux entreprises, car il est souvent nécessaire de réécrire
le code entièrement. Lorsqu'il n'existe pas de capitalisation des
fonctions de l'application et que le développement repose
généralement sur le code source, la séparation des préoccupations

[12]
apparaît comme la solution nécessaire au problème. Ainsi,

spécifications fonctionnelles et spécifications techniques sont prises
en compte séparément par l'approche MDA. Après la technologie
procédurale, la technologie objet et la technologie des composants,
l'approche MDA (Model Driven Architecture) est un processus de
l'ingénierie dirigée par les modèles (ou MDE pour Model Driven
Engineering). Proposée par l'OMG (Object Management Group) en
2000, l'approche MDA est basée sur la séparation des
préoccupations. Elle permet prendre en compte, séparément, aspect
métier et aspect technique d'une application, grâce à la modélisation.
Le code source de l'application est obtenu par génération
automatique à partir des modèles de l'application. Les modèles ne
sont plus seulement un élément visuel ou de communication, mais
sont, dans l'approche MDA, un élément productif et le pivot du
processus MDA. Dans ce cadre, le modèle devient directement
exécutable, de sorte que la dernière étape fastidieuse du codage
devienne presque inutile. L’approche MDA, qui remet au goût du jour
le concept de programmation graphique, devient envisageable à
l’issue d’une longue maturation du génie logiciel. Elle est en effet le
résultat de différents concepts que sont : la structuration orientée
objet, la formalisation plus poussée du méta modèle d’UML 2, la
programmation orientée aspect, la standardisation des langages de
programmation, constatée au travers des plates-formes de
développement (Java et C# notamment), et des composants IHM,
Web (W3C) et bases de données pour l’essentiel.
Le modèle en tant qu’abstraction d’un système s’accorde parfaitement bien

avec le concept orienté objet. L’objet représente en effet l’abstraction d’une
entité utilisée dans le système en analyse, puis le modèle d’un composant
de solution logicielle en conception. La correspondance est encore plus
flagrante, et le modèle encore plus précis, lorsque les outils de
développement sont eux-mêmes orientés objet. Aujourd’hui, le standard
industriel de modélisation objet est UML pourquoi pas UML 2 Balustic vous
informe sans doute.
I.1 Pourquoi modéliser ?
Modéliser un système avant sa réalisation permet de mieux comprendre le

fonctionnement du système. Dans le domaine de l’ingénierie du logiciel, le
modèle permet de mieux répartir les tâches et d’automatiser certaines
d’entre elles. C’est également un facteur de réduction des coûts et des
délais. Le modèle est enfin indispensable pour assurer un bon niveau de
qualité et une maintenance efficace.
Partant de la maitrise de cette question pourquoi modéliser, nous allons
définir quelques concepts liés à la modélisation.

[13]
✓ Le génie logiciel est un domaine des sciences de l’ingénieur dont

l’objet d’étude est la conception, la fabrication et la maintenance des
systèmes informatiques complexes.
✓ Un logiciel est un ensemble d’entités nécessaires au fonctionnement
d’un processus de traitement automatique de l’information. Parmi
ces entités, on trouve par exemple : des programmes exécutables ;
des documentations d’utilisation ; des informations de configuration.
Donc un logiciel est en général un sous-système d’un système
englobant. Il peut interagir avec des clients, qui peuvent être : des
opérateurs humains (des utilisateurs, des administrateurs, . . .) ;
d’autres logiciels ; des contrôleurs matériels.
Il réalise une spécification : son comportement vérifie un ensemble de
critères qui régissent ses interactions avec son environnement.
✓ Le génie logiciel vise à garantir que :
1. la spécification répond aux besoins réels de ses clients ;

2. le logiciel respecte sa spécification ;
3. les coûts alloués pour sa réalisation sont respectés ;
4. les délais de réalisation sont respectés.
La problématique de la modélisation objet est focalisé sur :
• La gestion de la complexité
• Approches de modélisation
Tenant compte de la problématique de la modélisation un logiciel de

qualité, implique qu’en plus du respect (essentiel) de sa spécification, cette
qualité du logiciel dépend des 4 critères suivants :
1. Maintenabilité : Peut-on faire évoluer le logiciel ?

2. Robustesse : Le logiciel est-il sujet à des dysfonctionnements ?
3. Efficacité : Le logiciel fait-il bon usage de ses ressources ?
4. Utilisabilité : Est-il facile à utiliser ?
I.2. Qui doit modéliser ?
La modélisation est souvent faite par la maîtrise d’œuvre informatique

(MOE). La MOE doit intervenir dans le modèle lorsque, après avoir défini
les concepts du métier, on doit introduire les contraintes propres à la plate-
forme informatique.
Maître d’ouvrage et Maître d’œuvre
o Maître d’ouvrage (MOA) : Le MOA est une personne morale

(entreprise, direction etc.) client du MOE.

[14]
o Maître d’œuvre (MOE) : Le MOE est une personne morale

(entreprise, direction etc.) garante de la bonne réalisation
technique des solutions. Il a, lors de la conception du SI, un devoir
de conseil vis-à-vis du MOA, car le SI doit tirer le meilleur parti
des possibilités techniques.
Le MOA est client du MOE à qui il passe commande d’un produit nécessaire
à son activité. La relation MOA et MOE est définie par un contrat qui précise
leurs engagements mutuels.
I.3 Les éléments de la modélisation des SI
• Modèle
• Langage
• Démarche
• Outil
• Méthode
- Un modèle est une représentation d’une réalité observée à l’aide d’un

formalisme conventionnel. L’abstraction est un des piliers de
l’approche objet. Il s’agit d’un processus qui consiste à identifier les
caractéristiques d’une entité en vue d’une utilisation précise. Le
modèle définit la frontière entre la réalité et la perspective de
l’observateur.
- Les langages de modélisation sont des conventions d’écriture et de
représentation formelle de modèles ; ils vont du langage naturel aux
langages formels en passant par des diagrammes, graphiques
- Les outils logiciels facilitent le processus de modélisation en fonction

de diverses entrées : recensement des besoins, contrôle de cohérence
de la base de données, conception de ’architecture logicielle,
documentation, prototypage, simulation, génération de code,
génération de tests, rétro conception, réutilisation des composants,
gestion et suivi de projets.
- Une méthode est une combinaison des composantes essentielles

(modèles, langages, outils et démarches).
Une méthode de développement doit répondre aux questions suivantes :
• Quand réaliser une activité ?

• Qui doit réaliser une activité ? Quoi faire dans une activité ?
• Comment réaliser une activité ?

[15]
I.4 Les Méthodes objet
Une méthode est une combinaison des modèles, langages, outils et

démarches. Son avantage est de fixer un vocabulaire et des normes de
spécification précises.
Il existe 4 générations des méthodes :
• Les méthodes d’analyse,

• Les méthodes cartésiennes, comme SADT (Structured Analysis Design
Technic = méthodes d’analyse fonctionnelle)
• Les méthodes systémiques, comme Merise
• Les méthodes objets, exemple d’UML
• Les méthodes de développements pour les logiciels orientés objets
RUP (Rational Unified Process, Instanciation par Rational Software
(IBM) des préceptes UP) Processus Unifié
• La méthode SCRUM, est une méthode agile dédiée à la gestion de
projets.
La modélisation objet consiste à créer une représentation des éléments du

monde réel, sans se préoccuper de l’implémentation (c.à.d.
indépendamment d’un langage de programmation). Les méthodes de
conception et de développement ont été mises au point entre 1970 et 1990.
Les 3 méthodes émergeant :
- La méthode OMT de Rumbaugh
- La méthode BOOCH de Booch
- La méthode OOSE de Jacobson
La Méthode OMT
OMT (Object Modeling Technic) est une méthode qui permet de modéliser
un SI selon trois points de vue complémentaires et inter reliés. Ces trois
modèles sont :
- Le modèle objet (quoi) : est le point de vue des données. Il définit la
structure des objets et leurs interrelations (classes, liens et héritage)
- Le modèle dynamique (quand : est le point de vue de contrôle et des
comportements. Il décrit les interrelations entre les objets
(diagramme de transition d’états, contrôle et événements ou
messages)
- Le modèle fonctionnel (comment) : il décrit les transformations
apportées aux données (diagrammes de flots d données et les
processus).
L’avantage de cette méthode est :
- Meilleure compréhension des besoins

[16]
- Spécification et conception plus précise

- Meilleure mentalité des systèmes réalisés
I.5. Les concepts de base dans la modélisation objet
• Encapsulation et interface,
• Héritage,
• Polymorphisme,
• Persistance.
1.5.1 Encapsulation et interface
Le concept d’encapsulation est un mécanisme consistant à rassembler les

données et les méthodes au sein d’une structure en cachant
l’implémentation de l’objet. L’encapsulation permet de garantir l’intégrité
des données contenues dans l’objet. L’ensemble des opérations d’une classe
rendu visible aux autres classes porte le nom d’interface. L’encapsulation
permet de définir les niveaux de visibilité des éléments de la classe. Ces
niveaux de visibilité définissent les droits d’accès aux données selon que
l’on y accède par une méthode de classe elle-même, d’une classe héritière,
ou d’une quelconque classe.
1.5.2 L’Héritage
L’héritage est un principe de la programmation orientée objet permettant

de créer une nouvelle classe (classe dérivée) à partir d’une classe existante.
L’intérêt majeur de l’héritage est de pouvoir définir de nouveaux attributs
et de nouvelles méthodes pour la classe dérivée, qui viennent s’ajouter à
ceux hérités.
1.5.3 Polymorphisme
Le mot polymorphisme vient du grec et signifie qui peut prendre plusieurs

formes. Le polymorphisme est la capacité donnée à une même opération de
s’exécuter différemment suivant le contexte de la classe où elle se trouve.
Une opération définie dans une superclasse peut s’exécuter de manière
différente selon la sous-classe où elle est héritée.
Exemple : soit la classe Employé et ses deux sous-classes Cadre et Non

Cadre.
1. Classe Employé
– Attributs :
– numéro,
– nom,
– salaire de base.
– Opérations : calcul Salaire ().

[17]
2. Sous-classe Cadre
– Attributs : niveau d’encadrement.
3. Sous-classe Non-Cadre
– Attributs : niveau de spécialisation.
En considérant que le principe de calcul du salaire étant de calculer pour

chaque type d’employé une prime spécifique en fonction du niveau de
spécialisation selon le type d’employé, l’application du polymorphisme lors
de l’exécution des opérations pour cet exemple se fera comme suit :
Lorsque l’on appelle l’opération calcul Salaire (), c’est l’opération de sous-
classe Cadre ou celle de la sous-classe Non Cadre qui est en fait activée
selon l’objet concerné. L’opération de la sous-classe fait en général appel
explicitement à l’opération calcul Salaire () de la superclasse pour
bénéficier des traitements communs aux cadres et non cadres et ensuite il
y aura poursuite du traitement spécifique à la sous-classe.
1.5.4 Persistance
La persistance est la propriété donnée à un objet de continuer à exister

après la fin de l’exécution du programme qui l’a créé. Par défaut dans
l’approche objet, aucun objet n’est persistant. Les modèles décrivent le
système en exécution en mémoire centrale et ne tiennent pas compte a
priori de l’état du système qui doit être stocké sur disque.
❖ Les principes et bonnes pratiques de la modélisation objet
• Bien découper et concevoir les classes

• Réduire le couplage
• Organisation en packages
• Limiter les effets de bord, préférer les objets immuables
• Choisir entre l’héritage et la composition
• Éviter les données statiques
• Le typage statique ou dynamique

[18]
Chapitre 2 Conception
2.1. But
Le but de la conception est de :

• Fixer les choix techniques et de préparer l’implantation ;
• Décrire la solution ;
• Servir de support pour l’implantation et la maintenance.
2.2. Cycle de vie d’un logiciel
Le cycle de vie d’un logiciel (en anglais software life cycle), désigne toutes
les étapes du développement d’un logiciel, de sa conception à sa
disparition. L’objectif d’un tel découpage est de permettre de définir des
jalons intermédiaires permettant la validation du développement logiciel,
c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la
vérification du processus de développement, c’est-à-dire l’adéquation des
méthodes mises en œuvre. L’origine de ce découpage provient du constat
que les erreurs ont un coût d’autant plus élevé qu’elles sont détectées
tardivement dans le processus de réalisation. Le cycle de vie permet de
détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel,
les délais de sa réalisation et les coûts associés.
Le cycle de vie du logiciel comprend généralement les étapes suivantes :
• Définition des objectifs : Cette étape consiste à définir la finalité du

projet et son inscription dans une stratégie globale.
• Analyse des besoins et faisabilité : c’est-à-dire l’expression, le recueil
et la formalisation des besoins du demandeur (le client) et de
l’ensemble des contraintes puis l’estimation de la faisabilité de ces
besoins.
• Spécification ou conception générale : Il s’agit de l’élaboration des
spécifications de l’architecture générale du logiciel.
• Conception détaillée : Cette étape consiste à définir précisément
chaque sous-ensemble du logiciel.
• Codage (Implémentation ou programmation) : c’est la traduction
dans un langage de programmation des fonctionnalités définies lors
de phases de conception.
• Tests unitaires : Ils permettent de vérifier individuellement que
chaque sous-ensemble du logiciel est implémenté conformément aux
spécifications.
• Intégration : L’objectif est de s’assurer de l’interfaçage des différents
éléments (modules) du logiciel. Elle fait l’objet de tests d’intégration
consignés dans un document.
• Qualification (ou recette) : C’est-à-dire la vérification de la
conformité du logiciel aux spécifications initiales.

[19]
• Documentation : Elle vise à produire les informations nécessaires

pour l’utilisation du logiciel et pour des développements ultérieurs.
• Mise en production : il s’agit de l’installation matérielle et logicielle
• Maintenance : Elle comprend toutes les actions correctives
(maintenance corrective) et évolutives (maintenance évolutive) sur
le logiciel.
La séquence et la présence de chacune de ces activités dans le cycle de vie

dépend du choix d’un modèle de cycle de vie entre le client et l’équipe de
développement. Le cycle de vie permet de prendre en compte, en plus des
aspects techniques, l’organisation et les aspects humains.
❖ L’expression des besoins
C’est la première étape du cycle de développement d’un logiciel.

L’expression des besoins consiste à produire un document qui décrit les
utilisateurs visés et leurs objectifs. Ce document (DSL : Dossier de
Spécification du Logiciel) formalise la liste des fonctions à accomplir pour
répondre aux besoins des clients.
❖ La conception globale
C’est l’étape de la description de haut niveau du produit, en termes de

modules et de leurs interactions. Le DCP (Dossier de Conception
Préliminaire) doit mettre en évidence le plan de test, en termes de besoins
de l’utilisateur et montrer ce que l’on peut y satisfaire grâce à l’architecture
proposée.
❖ La conception détaillée
C’est dans cette étape que chacun des modules énumérés dans le DCP est
décrit en détail. L’interface de chaque module est complètement décrite à
ce niveau. On doit montrer, ici, comment le travail doit être fait et dans
quel ordre tout en estimant la charge précise de travail pour la réalisation
de chaque module. Pour ce faire, la méthode PERT, MPM ou le diagramme
de GANTT est d’une importance capitale. Il faudra donc avoir un plan de
test unitaire pour chaque module.
❖ Le codage (implémentation ou programmation)
Il s’agit ici, de la réalisation de chaque module décrit à l’étape précédente.

Le codage c’est l’âme du processus de développement du logiciel.

[20]
❖ L’intégration
L’intégration n’est réalisée qu’après avoir terminé tous les modules (c.à.d.
la programmation). C’est à ce niveau que tous les modules sont réunis en
un seul ensemble de code source, compilés et liés pour former un paquetage
qui constitue le système. L’intégration comprend le développement de tests
au niveau du système. L’intégration peut être réalisée de façon
incrémentale, en parallèle avec la réalisation de différents modules. Si le
paquetage réalisé est capable de s’installer lui-même il doit alors exister
un moyen de le faire automatiquement, soit sur des spécialisés, soit dans
l’environnement de simulation. Dans certains cas, le paquetage est
constitué d’ans certains cas, le paquetage est constitué d’un exécutable
résultant de la compilation de l’ensemble des modules.
❖ La validation (recette)
C’est l’étape de validation et vérification qui doit généralement commencer

en interne (c.à.d. par les développeurs du logiciel)
2.4 Le génie logiciel
L’informatisation est le phénomène le plus important de notre époque. Elle

s’immisce maintenant dans la plupart des objets de la vie courante et, que
ce soit dans l’objet proprement dit ou bien dans le processus de conception
ou de fabrication de cet objet.
S’il faut parler du monde actuel, l’informatique est au cœur de toutes les
grandes entreprises pour faciliter le traitement automatique de son
système d’information or 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épartissent généralement de la manière
suivante : 20% pour le matériel et 80% pour le logiciel.
Les techniques de programmation n’ont cessé de progresser depuis

l’époque de la programmation en langage binaire (cartes perforées, Switch)
à nos jours. Cette évolution a toujours été dictée par le besoin de concevoir
et de maintenir des applications toujours plus complexes.
UML (Unified Modeling Language en anglais, soit langage de modélisation

objet unifié) est né de la fusion des trois méthodes qui s’imposaient dans
le domaine de la modélisation objet au milieu des années 1990 : OMT,
Booch et OOSE. D’importants acteurs industriels (IBM, Microsoft, Oracle,
DEC, HP, Rational, Unisys etc.) s’associent alors à l’effort et proposent UML
1.0 à l’OMG (Object Management Group) qui l’accepte en novembre 1997
dans sa version 1.1. La version d’UML en cours en 2014 est UML2 qui
s’impose plus que jamais en tant que langage de modélisation standardisé
pour la modélisation des logiciels.
[21]
2.5. Le Système d’Information
2.5.1 Notion de Système
Le mot système résulte du mot grec philosophique « système » qui

signifiait ensemble. Mais de nombreux spécialistes de la systémique
décrivent le fait qu’un système est un ensemble d’éléments en interaction
dynamique, organisés en fonction d’un but.
Un système est composé de :
• Son système de pilotage (SP) ;

• Son système d’information (SI) ;
• Son système opérant (SO).
✓ Le système de pilotage
Le système de pilotage (aussi appelé système de commande) d’un système

coordonne le fonctionnement de ce système, le contrôle et décide de ses
réactions et de ses orientations à la connaissance d’événements importants
provenant de son environnement. C’est le système nerveux du système, qui
prend des décisions, fixe les objectifs et les moyens de les atteindre.
✓ Le système d’information
Un système d’information est un ensemble des méthodes et des moyens qui

recueille, contrôle, traite et distribue les informations nécessaires en tout
point d’organisation.
✓ Le système opérant
Le système opérant (aussi appelé système d’exécution) d’un système

exécute les tâches que lui demande d’assurer le système de pilotage pour
faire fonctionner le système.
Structure d’un système
Système de Pilotage
Système d’Information
Système Opérant

[22]
N.B. L’environnement d’un système est l’univers auquel il appartient. Ex :

I.S.S-KIN comme système et son environnement se sont les étudiants, les
enseignants, les administratifs.
2.5.2. Description du Système d’Information
Le système d’information est caractérisé par trois éléments dont les

entrées, la fonction de transformation et les sorties (résultats).
2.5.3 Objectifs du système d’information
L'importance du Système d'Information (SI) dans la vie des entreprises est

aujourd'hui amplement reconnue. Il est maintenant clair que, pour ces
dernières, un bon fonctionnement de leur SI conditionne grandement leurs
performances, voire leur survie dans un contexte de concurrence
croissante. En même temps que s'opérait cette prise de conscience, s'est
imposée la reconnaissance du caractère indispensable de méthodes
permettant de concevoir correctement le système d'information ce qui
implique :
- une claire appréhension, de la part des responsables, des utilisateurs

comme des spécialistes de l'informatique et des réseaux de la place du
système d'information dans l'entreprise ;
- une identification correcte des besoins des utilisateurs ;
- une spécification précise des solutions informatiques répondant à ces

besoins, spécification facilement exploitable par les équipes chargées de la
réalisation et de la mise en place.
Fonction de transformation
Entrées Sortie
SI
2.5.4 Rôle du système d’information
1. Collecte des informations provenant d’autres éléments du système de

l’environnement ;
2. Transmission des informations vers le lieu où elle doit être utilisée ou
traitée dans les organes concernés ;
3. Mémorisation des informations, prise en compte de l’information par le
système d’information, là où elle doit changer de forme (base de données
Fichiers Historique, Archivage) ;
4. Traitement des informations pour les rendre rationnelles ;
5. Communication des informations aux utilisateurs.

[23]
Un système d’information est composé de sous-systèmes

appelés “fonctions” et chaque fonction aura un rôle précis à jouer dans le
système.
Un sous-système ou fonction est un élément important du SI chargé d’une
tâche particulière dont l’exécution conditionne le fonctionnement normal
du système.
Exemple d’un SI : Un système de gestion d’une entreprise ou d’une

université.
SYSTEME DE PILOTAGE
Coordination, orientations
La haute hiérarchie
Décisions Informations traitées
SYSTEME
D’INFORMATION
Environnement - Collecte Environnement
- Transmission
- Mémorisation des données
- Traitement
- Communication
Informations
collectées
SYSTEME OPERANT
Production, exécution Flux sortant
Flux entrant
Les exécutants

[24]
Chapitre 3 UML
UML se définit comme un langage de modélisation graphique et textuel

destiné à comprendre et écrire des besoins, spécifier et documenter des
systèmes, esquisser des architectures logicielles, concevoir des solutions et
communiquer des points de vue. UML unifie à la fois les notations et les
concepts orientés objet. Il ne s’agit pas d’une simple notation graphique,
car les concepts transmis par un diagramme ont une sémantique précise et
sont porteurs de sens au même titre que les mots d’un langage. UML unifie
également les notations nécessaires aux différentes activités d’un
processus de développement et offre, par ce biais, le moyen d’établir le
suivi des décisions prises, depuis l’expression de besoin jusqu’au codage.
Dans ce cadre, un concept appartenant aux exigences des utilisateurs
projette sa réalité dans le modèle de conception et dans le codage. Le fil
tendu entre les différentes étapes de construction permet alors de
remonter du code aux besoins et d’en comprendre les tenants et les
aboutissants. En d’autres termes, on peut retrouver la nécessité d’un bloc
de code en se référant à son origine dans le modèle des besoins.
• Structure de Cours
Pour ne pas mélanger les problèmes, notre cours de CSI sera découpé
suivant les trois points de vue classiques de modélisation : fonctionnel,
statique et dynamique, en insistant pour chacun sur le ou les Diagrammes
UML prépondérants.
Fonctionnel
Diagramme de Use Cases
(Diagramme d’Activités)
(Diagramme de Séquence)
3 Axes de modélisation
Statique Dynamique
Diagramme de Classes Diagramme d’États
(Diagramme d’Objets) (Diagramme d’Activités)
(Diagramme de Séquence)
Diagramme de Composants
(Diagramme de Déploiement) Diagramme de Communication

[25]
3.1 Modélisation Fonctionnelle
Ce point va nous permettre d’illustrer pas à pas, sur une première étude de
cas, les principales difficultés liées à la mise en œuvre de la technique des
cas d’utilisation. Après avoir identifié les acteurs qui interagissent avec le
système, nous y développons un premier modèle UML de haut niveau, pour
pouvoir établir précisément les frontières du système. Dans cette optique,
nous apprenons à identifier les cas d’utilisation et à construire un
diagramme de cas d’utilisation reliant les acteurs et les cas d’utilisation.
Ensuite, nous précisons le point de vue fonctionnel en détaillant les
différentes façons dont les acteurs peuvent utiliser le système. À cet effet,
nous apprenons à rédiger des descriptions textuelles de cas d’utilisation,
ainsi qu’à dessiner des diagrammes UML complémentaires (comme les
diagrammes de séquence ou d’activité).
3.1.2 Principes et définitions de base
ACTEUR : Un acteur représente un rôle joué par une entité externe

(utilisateur humain, dispositif matériel ou autre système) qui interagit
directement avec le système étudié. Un acteur peut consulter et/ou
modifier directement l’état du système, en émettant et/ou en recevant des
messages susceptibles d’être porteurs de données.
La représentation graphique standard de l’acteur en UML est l’icône

appelée stick man, avec le nom de l’acteur sous le dessin. On peut également
figurer un acteur sous la forme rectangulaire d’une classe, avec le mot-clé
« actor ». Une troisième représentation (intermédiaire entre les deux
premières) est également possible, comme cela est indiqué ci-après.
« Actor »
Mot-clé
SI GEF I.S.S- SI GEF I.S.S-KIN
KIN
Stick man Étudiant
Symbole à la place du mot-clé
Une bonne recommandation consiste à faire prévaloir l’utilisation de la

forme graphique du stick man pour les acteurs humains et une
représentation rectangulaire pour les systèmes connectés.

[26]
Section1 Axe Fonctionnel
• CAS D’UTILISATION
Un cas d’utilisation (use case) représente un ensemble de séquences

d’actions qui sont réalisées par le système et qui produisent un résultat
observable intéressant pour un acteur particulier. Chaque cas d’utilisation
spécifie un comportement attendu du système considéré comme un tout,
sans imposer le mode de réalisation de ce comportement. Il permet de
décrire ce que le futur système devra faire, sans spécifier comment il le
fera. L’ensemble des cas d’utilisation doit décrire exhaustivement les
exigences fonctionnelles du système, selon le point de vue de ses acteurs.
NB : le cas d’utilisation doit être nommé par un verbe à l’infinitif suivi d’un
complément du point de vue de l’acteur. Pour détailler la dynamique du cas
d’utilisation, la procédure la plus évidente consiste à recenser de façon
textuelle toutes les interactions entre les acteurs et le système. Le cas
d’utilisation doit avoir un début et une fin clairement identifiés. Il faut
également préciser les variables possibles, telles que les différents cas
nominaux, les cas alternatifs, les cas d’erreurs, tout en essayant d’ordonner
séquentiellement les descriptions, afin d’améliorer leur lisibilité.
On peut organiser les cas d’utilisation de deux façons différentes et
complémentaires :
➢ en ajoutant des relations d’inclusion, d’extension, et de

généralisation entre les cas d’utilisation ;
➢ en les regroupant en packages, afin de définir des blocs fonctionnels
de plus haut niveau.
Remarquez que dans une relation « include », le cas d’utilisation de base

utilise systématiquement les enchaînements provenant du cas inclus.
On utilise fréquemment cette relation pour éviter de décrire plusieurs fois
le même enchaînement, en factorisant le comportement commun dans un
cas d’utilisation à part.
LES RELATIONS POSSIBLES ENTRE CAS D’UTILISATION
UML définit trois types de relations standardisées entre cas d’utilisation,

détaillées ci-après :
 Une relation d’inclusion, formalisée par un mot-clé <<include>>,

 Une relation d’extension, formalisée par un mot-clé <<extend>>,
 Une relation de généralisation/spécialisation.
Inclusion : le cas d’utilisation de base en incorpore explicitement un autre,

de façon obligatoire, à un endroit spécifié dans ses enchaînements.

[27]
Extension : le cas d’utilisation de base en incorpore implicitement un autre,

de façon optionnelle, à un endroit spécifié indirectement dans celui qui
procède à l’extension (déconseillé !)
Généralisation : les cas d’utilisation descendants héritent de la description

de leur parent commun. Chacun d’entre eux peut néanmoins comprendre
des relations spécifiques supplémentaires avec d’autres acteurs ou cas
d’utilisation (déconseillé !). La généralisation d’acteurs est en revanche
parfois utile.
1.1 Le diagramme de cas d’utilisation
Ce diagramme de cas d’utilisation est un schéma qui montre les cas

d’utilisation (ovales) reliés par des associations (lignes) à leurs acteurs
(icône du « stick man », ou représentation graphique équivalente). Chaque
association signifie simplement « participe à ». Un cas d’utilisation doit
être relié à au moins un acteur.
Exemple : Étude d’un SI pour la gestion des paiements de frais des

étudiants à l’I.S.S-KIN.
Cette étude est volontairement incomplète et imprécise, comme il en est
dans les projets réels ! La résolution complète doit se faire dans l’auditoire
ensemble avec les étudiants pour qu’ils arrivent a bien appréhendé la
notion sur le diagramme de cas d’utilisation.

[28]
On peut donc légitimement identifier un nouveau cas d’utilisation inclus

dans les précédents, que nous appellerons prendre l’INSCRIPTION, et qui
contient les enchaînements cités plus haut.
Cela nous permettra d’enlever des autres cas d’utilisation toutes ces
descriptions textuelles redondantes, en se concentrant mieux sur leurs
spécificités fonctionnelles. En UML, cette relation d’inclusion obligatoire
est formalisée par une flèche de dépendance entre le cas d’utilisation de
base et le cas inclus, nommée avec le mot-clé <<include>>, comme cela est
indiqué sur le schéma suivant.
Se présenter Cas d’utilisation Déposer la fiche remplie

à la banque de base et l’argent de frais
« include » « include »
« INSCRIPTION
Cas d’utilisation
DE L’ÉTUDIANT »
inclus
« include »
Retirer le bordereau de
la banque et reçu
En réexaminant la question de paiement de frais des étudiants de I.S.S-KIN,

on a tôt fait de s’apercevoir que l’étudiant applique quasiment le même
enchaînement nominal que les parents qui partent payer les frais pour
leurs enfants. Mais, en tant qu’étudiant, il a également accès dans autres
cas d’utilisation : pourquoi ne pas lui permettre de vérifier si son nom
existe dans le palmarès, juste avant qu’il ne choisisse le montant de frais à
payer ? Il pourrait ainsi ajuster le montant d’acompte avec ce qu’il lui est
fixé par l’institut. Si l’on retient ce nouveau besoin fonctionnel, pour le
modéliser en UML il suffit d’ajouter une relation d’extension optionnelle
comme cela est indiqué sur la figure suivante.

[29]
Vérifier le Condition : {Réussir au teste ou dans la

montant à payer délibération et connaitre le montant de frais}
Extension point : Vérification de l’acompte
fixé par l’I.S.S-KIN
« Extend »
Relation d’extension Vérification du nom sur la liste des

inscrits ou des réussites et/ou avoir
connaissance du prix fixé par
l’I.S.S-KIN
Possession d’un jeton d’étudiant pour se

présenter à la banque.
Les deux cas d’utilisation peuvent bien sûr s’exécuter indépendamment,
mais Vérifier le montant à payer peut également venir s’intercaler à
l’intérieur de possession d’un jeton d’étudiant pour se présenter à la banque,
au point d’extension Vérification du nom sur la liste des inscrits ou des
réussites et/ou avoir connaissance du prix fixé par l’I.S.S-KIN.
Nous allons poursuivre enfin par la relation de généralisation /

spécialisation : les cas d’utilisation descendants héritent de la description
de leur parent commun. Ils peuvent néanmoins comprendre chacune des
interactions spécifiques supplémentaires, ou modifier les interactions dont
ils ont hérité. On utilise cette relation pour formaliser des variations
importantes sur le même cas d’utilisation. Considérons le cas d’utilisation
Déposer la fiche remplie et/ou de l’argent de frais par l’étudiant. Il possède
deux scénarios principaux : Déposer du numéraire et Déposer des
dérogations. Est-il souhaitable de distinguer ces scénarios en tant que cas
d’utilisation à part entière ? Essayons de trouver les arguments pour et
contre. Ils mettent en jeu les mêmes acteurs : l’étudiant, les responsables
de l’étudiant comme acteur secondaire et la caissière, les membres du
comité de gestion comme les acteurs principaux. En distinguant deux cas
d’utilisation, nous ajoutons la possibilité de leur associer des acteurs
secondaires différents. Pour formaliser cette unité fonctionnelle, tout en se
gardant la possibilité de décrire les différences au niveau des
enchaînements, nous pouvons utiliser la relation de généralisation /
spécialisation.
Il suffit de considérer que Paiement frais est un cas d’utilisation généralisé.
Ce cas a maintenant la particularité d’être abstrait (il apparaît alors en
italiques), car il ne s’instancie pas directement, mais uniquement par le
biais de l’un de ses deux cas spécialisés.

[30]
Cas d’utilisation parent

Payer le frais (abstrait)
Étudiant Cas d’utilisation

descendant (concret) Généralisation
Dépôt de la
Dépôt du dérogation
numéraire
Avec tous ces ajouts, que devient donc notre diagramme de cas d’utilisation
? Il est maintenant si complexe. Notez que nous avons introduit un acteur
généralisé abstrait « Étudiant » en tant qu’acteur secondaire du fragment
de cas d’utilisation INSCRIPTION. Cela nous permet ainsi d’inclure ce
fragment dans les cas d’utilisation.
Pour améliorer notre modèle, nous allons donc organiser les cas
d’utilisation et les regrouper en ensembles cohérents. Pour ce faire, nous
utilisons le mécanisme général de regroupement d’éléments en UML, qui
s’appelle-le package. Le package est une sorte de dossier permettant de
structurer un modèle en unités cohérentes. Les outils de modélisation du
marché se servent pour la plupart de ce concept comme unité de gestion de
version, de stockage, et de partage du modèle pour le travail en équipe.
Nous y reviendrons plus en détail dans le Chapitre III (modélisation
statique).
1.2 Diagramme de Séquence (Sequence Diagram)
L’objectif du diagramme de séquence est de représenter les interactions

entre objets (Acteurs) en indiquant la chronologie des échanges. Cette
représentation peut se réaliser par cas d’utilisation en considérant les
différents scénarios associés.
Les principales informations contenues dans un diagramme de séquence

sont les messages échangés entre les lignes de vie, présentés dans un ordre
chronologique. Un diagramme de séquence se représente globalement dans
un grand rectangle avec indication du nom du diagramme en haut à gauche.
Il est aussi possible dans certains outils de modélisation d’indiquer plus
simplement la création d’une nouvelle instance d’objet en utilisant le mot-
clé « create ».

[31]
1.2.1 Fragment d’interaction
Dans un diagramme de séquence, il est possible de distinguer des sous-

ensembles d’interactions qui constituent des fragments. Un fragment
d’interaction se représente globalement comme un diagramme de séquence
dans un rectangle avec indication dans le coin à gauche du nom du
fragment.
Un port d’entrée et un port de sortie peuvent être indiqués pour connaître
la manière dont ce fragment peut être relié au reste du diagramme. Dans
le cas où aucun port n’est indiqué c’est l’ensemble du fragment qui est
appelé pour exécution. Le fragment « Contrôler Frais » est représenté avec
un port d’entrée et un port de sortie. Un fragment d’interaction dit
combiner correspond à un ensemble d’interaction auquel on applique un
opérateur. Un fragment combiné se représente globalement comme un
diagramme de séquence avec indication dans le coin à gauche du nom de
l’opérateur.
Exemple.
Diagramme d’ensemble
Interface Saisie de
Paiement
Étudiant Guichetier Caissier Dir. Génér

Se présente à la banque
Réception de l’étudiant
La continuité du
Présentation Fiche présent Diagramme se
fera dans la salle avec
les étudiants.
Récupération Fiche
Contrôle de Frais
Statistique du
Impression des données Paiement
Prise de décisions

[32]
1.2.1 Représentation des lignes de vie
Une ligne de vie représente l’ensemble des opérations exécutées par un

objet (acteur). Un message reçu par un objet déclenche l’exécution d’une
opération. Le retour d’information peut être implicite (cas général) ou
explicite à l’aide d’un message de retour.
Message synchrone et asynchrone
Dans un diagramme de séquence, deux types de messages peuvent être

distingués :
• Message synchrone – Dans ce cas l’émetteur reste en attente de la réponse
à son message avant de poursuivre ses actions. La flèche avec extrémité
pleine symbolise ce type de message. Le message retour peut ne pas être
représenté car il est inclus dans la fin d’exécution de l’opération de l’objet
(acteur) destinataire du message.
• Message asynchrone – Dans ce cas, l’émetteur n’attend pas la réponse à

son message, il poursuit l’exécution de ses opérations. C’est une flèche avec
une extrémité non pleine qui symbolise ce type de message.
1.2.2 Représentation des messages
Un message définit une communication particulière entre des lignes de vie.

Plusieurs types de messages existent, les plus communs sont :
L’envoi d’un signal ; l’invocation d’une opération ; la création ou la
destruction d’une instance.
1.3 Diagramme de paquetage
Un paquetage est un regroupement d’éléments de modèle et de diagrammes

portant sur un sous-ensemble du système. Le découpage en paquetage doit
traduire un découpage logique du système à construire qui corresponde à
des espaces de nommage homogènes. Il permet ainsi d’organiser des
éléments de modélisation en groupes. Il peut contenir tout type d’élément
de modèle : des classes, des cas d’utilisation, des interfaces, des
diagrammes, et même des paquetages imbriqués (décomposition
hiérarchique). Plusieurs stratégies sont possibles : procéder au
regroupement par acteur, par domaine fonctionnel, etc. Les éléments d’un
paquetage peuvent avoir une visibilité déclarée soit de type public (+) soit
privé (-). Un paquetage peut importer des éléments d’un autre paquetage.
Un paquetage peut être fusionné avec un autre paquetage.

[33]
Formalisme et exemple
Trois manières sont possibles pour présenter un paquetage.
• Représentation globale – Le nom du paquetage se trouve à l’intérieur du

grand rectangle.
Gestion de paiement des frais
• Représentation détaillée – Les membres du paquetage sont représentés et

le nom du paquetage d’ensemble s’inscrit dans le petit rectangle.
GesFrais
Paiement Contrôle et Rapport
• Représentation éclatée – Les membres du paquetage sont reliés par un

lien connecté au paquetage par le symbole ⊕.
GesFrais
Paiement Contrôle et Rapport
1.3.1 Dépendance entre paquetages
La dépendance entre paquetages peut être qualifiée par un niveau de

visibilité qui est soit public soit privé. Par défaut le type de visibilité est
public. À chaque type de visibilité est associé un lien de dépendance.
Les deux types de dépendances entre paquetages sont :
• « Import » – Ce type de dépendance permet, pour un paquetage donné,

d’importer l’espace de nommage d’un autre paquetage.

[34]
Ainsi tous les membres du paquetage donné ont accès à tous les noms des
membres du paquetage importé sans avoir à utiliser explicitement le nom
du paquetage concerné.
Ce type de dépendance correspond à un lien ayant une visibilité « public ».
• « Access » – Ce type de dépendance permet, pour un paquetage donné,
d’avoir accès à l’espace de nommage d’un paquetage cible. L’espace de
nommage n’est donc pas importé et ne peut être transmis à d’autres
paquetages par transitivité. Ce type de dépendance correspond à un lien
ayant une visibilité « privé ». Dans cet exemple, les éléments de la Base de
données de la banque sont importés dans GEF et ensuite dans la BDD
Finance I.S.S-KIN. Cependant, les éléments de Contrôle frais et Rapport
sont seulement accessibles par le paquetage GEF et donc pas à partir du
paquetage BDD Finance I.S.S-KIN.
BDD de la Banque
Paie
« Import »
GESFRAIS BDD Finances
I.S.S-KIN
Contrôle Frais et
Rapport
1.4 Diagramme d’Activités

1.4.1 Présentation générale et concepts de base
Le diagramme d’activité présente un certain nombre de points communs

avec le diagramme d’état-transition puisqu’il concerne le comportement
interne des opérations ou des cas d’utilisation. Cependant le comportement
visé ici s’applique aux flots de contrôle et aux flots de données propres à
un ensemble d’activités et non plus relativement à une seule classe. Les
concepts communs ou très proches entre le diagramme d’activité et le
diagramme d’état-transition sont :
• transition,
• nœud initial (état initial),
• nœud final (état final),
•⊗ nœud de fin flot (état de sortie),
• ◊ nœud de décision (choix).
Le formalisme reste identique pour ces nœuds de contrôle.

[35]
Les concepts spécifiques au diagramme d’activité sont :

• nœud de bifurcation,
• nœud de jonction,
• nœud de fusion,
• nœud de test-Décision,
• pin d’entrée et de sortie,
• flot d’objet,
• partition.
Avant de mettre en pratique un exercice sur la représentation du
diagramme d’activités dans le cadre de notre cours de CSI, nous allons dans
un premier temps définir d’autres concepts importants qu’allons-nous
utiliser dans cette présentation et qui sont utiles au formalisme de la
présentation du diagramme d’activités.
1. Action
Une action correspond à un traitement qui modifie l’état du système. Cette
action peut être appréhendée soit à un niveau élémentaire proche d’une
instruction en termes de programmation soit à un niveau plus global
correspondant à une ou plusieurs opérations. NB ne vous dérangez pas trop
confère au cours d’algorithmique de G1 pour bien maitriser la présentation
de diagramme d’activités.
Une action est représentée par un rectangle dont les coins sont arrondis.
Nom de l’Action Enregistrement frais
2. Transition et flot de contrôle
Dès qu’une action est achevée, une transition automatique est déclenchée
vers l’action suivante. Il n’y a donc pas d’événement associé à la transition.
L’enchaînement des actions constitue le flot de contrôle.
Transition
Enregistrement frais Impression preuve de paiement
3. Activité
Une activité représente le comportement d’une partie du système en

termes d’actions et de transitions. Une activité est composée de trois types
de nœuds :
✓ Nœud d’exécution (action, transition),
✓ Nœud de contrôle (nœud initial, nœud final, flux de sortie, nœud de
bifurcation, nœud de jonction, nœud de fusion-test, nœud de test-
décision, pin d’entrée et de sortie),

[36]
✓ nœud d’objet.
Une activité peut recevoir des paramètres en entrée et en produire en
sortie.
Activité : Présence de l’étudiant à la

banque
Remplir Vérification Enregistreme

fiche à la du nt frais
4. Nœud de bifurcation (fourche)
Un nœud de bifurcation (fourche) permet à partir d’un flot unique entrant

de créer plusieurs flots concurrents en sortie de la barre de
synchronisation.
Recevoir frais
Points de bifurcation
Vrai billet Faux billet
Enregistr. Frais Impression Bord.
5. Nœud de jonction (synchronisation)

Un nœud de jonction (synchronisation) permet, à partir de plusieurs flots
concurrents en entrée de la synchronisation, de produire un flot unique
sortant. Le nœud de jonction est le symétrique du nœud de bifurcation.
Fiche de la banque remplie Présence vrai billet banque
Enregistrement frais

[37]
6. Nœud de test-décision
Un nœud de test-décision permet de faire un choix entre plusieurs flots

sortants en fonction des conditions de garde de chaque flot. Un nœud de
test-décision n’a qu’un seul flot en entrée. On peut aussi utiliser seulement
deux flots de sortie : le premier correspondant à la condition vérifiée et
l’autre traitant le cas sinon.
Remplissage fiche banque

Bien remplie Mal remplie
Perception l’Argent Ré-remplissage fiche

Faux billet
Vrais billets
Ré-remplissage fiche
Enregistrement frais Impression Bord
7. Nœud de fusion-test
Un nœud de fusion-test permet d’avoir plusieurs flots entrants possibles et
un seul flot sortant. Le flot sortant est donc exécuté dès qu’un des flots
entrants est activé.
Dépôt de numéraire Dépôt de la dérogation
[KO] étudiant
I.S.S-KIN
[OK] étudiant
Refus étudiant douteux I.S.S-KIN
Enregistrement frais Impression Bord.

[38]
8. Pin d’entrée et de sortie
Un pin d’entrée ou de sortie représente un paramètre que l’on peut

spécifier en entrée ou en sortie d’une action. Un nom de donnée et un type
de donnée peuvent être associés au pin. Un paramètre peut être de type
objet. Prenons le cas d’une impression de bordereau de la banque, lorsque
le guichetier désire l’imprimer, il aura besoin des quelques informations
de l’étudiant pour son état et parmi ces informations, il y a les informations
avec comme type de données Numérique, Alphanumérique, Date …d’où
notre Pin d’entrée et de sortie seront :
P1 Type Alphanumérique
P2 Type Numérique R1 Résultat réel pour l’impression
P3 Type Date
P1
Bordereau de la banque
P2 R1
P3
9. Flot de données et nœud d’objet
Un nœud d’objet permet de représenter le flot de données véhiculé entre

les actions. Les objets peuvent se représenter de deux manières différentes
: soit en utilisant le pin d’objet soit en représentant explicitement un objet.
Étudiant Paiement Bordereau Imprimé
Comme nous avions dit dans des pages précédentes, la présentation de tous
les diagrammes est volontairement incomplète et imprécise, comme il en
est dans les projets réels ! La résolution complète doit se faire dans
l’auditoire ensemble avec les étudiants pour qu’ils arrivent a bien
appréhendé la notion les matières.

[39]
• Présentation de diagramme d’Activités
Étudiant Guichetier Caisse
Remplissage Fiche
Ré remplissage fiche
Demande d’Argent
Dépôt de numéraire
Dépôt de la
dérogation
Personne
[KO] étudiant I.S.S-KIN
Refus étudiant douteux [OK] étudiant

I.S.S-KIN
Paiement
Impression Bord.
Enregistrement frais
Réception Bord.

[40]
Section 2 Axe Statique

2.1 Diagramme de Classes
Le diagramme de classes est le point central dans un développement

orienté objet. En analyse, il a pour objectif de décrire la structure des
entités manipulées par les utilisateurs. En conception, le diagramme de
classes représente la structure d’un code orienté objet ou, à un niveau de
détail plus important, les modules du langage de développement. Ce
Diagramme constitue l’un des pivots essentiels de la modélisation avec
UML. En effet, il permet de donner la représentation statique du système à
développer. Cette représentation est centrée sur les concepts de classes,
des associations, des multiplicités et de la Généralisation. Chaque classe se
décrit par les données et les traitements dont elle est responsable pour elle-
même et vis-à-vis des autres classes. Les traitements sont matérialisés par
des opérations. Le détail des traitements n’est pas représenté directement
dans le diagramme de classe ; seul l’algorithme général et le pseudo-code
correspondant peuvent être associés à la modélisation.
La description du diagramme de classe est fondée sur :
• le concept d’objet,
• le concept de classe comprenant les attributs et les opérations,
• les différents types d’association entre classes,
• les multiplicités qui montrent le nombre de fois qu’une classe
Participe à l’association.
2.1.1 Les Concepts de base du diagramme de classes
1. Classe et Objet
Une classe représente la description abstraite d’un ensemble d’objets

possédant les mêmes caractéristiques. On peut parler également de type.
C’est-à-dire elle décrit un groupe d’objets ayant les mêmes propriétés
(attributs), un même comportement (opérations), et une sémantique
commune (domaine de définition). Exemples : la classe Frais, la classe
Personne.
Par contre un objet est un concept, une abstraction ou une chose qui a un
sens dans le contexte du système à modéliser. Chaque objet a une identité
et peut être distingué des autres sans considérer a priori les valeurs de ses
propriétés (caractérisant l’état d’un objet). Il est une instance (ou
occurrence) d’une classe. Il est aussi considéré comme une entité aux
frontières bien définies, possédant une identité et encapsulant un état et
un comportement. Un objet doit toujours être caractérisé par les valeurs
de ses propriétés qui lui confèrent des états significatifs suivant les
instants considérés. La classe représente l’abstraction de ses objets.
[41]
Au niveau de l’implémentation, c’est-à-dire au cours de l’exécution d’un

programme, l’identificateur d’un objet correspond à une adresse mémoire.
Lorsqu’on parle de l’état d’un objet, on voit la correspondance aux valeurs
de tous ses attributs à un instant donné. Les propriétés sont définies dans
la classe d’appartenance de l’objet. Le comportement d’un objet est
caractérisé par l’ensemble des opérations qu’il peut exécuter en réaction
aux messages provenant des autres objets. Les opérations sont définies
dans la classe d’appartenance de l’objet. Schématiquement par-là :
Objet = identité + état (attributs) + comportement (méthodes)

Exemple : considérons l’étudiant KALOMBO ILUNGA, NumMatricule
E0001, inscrit en 2011, Promotion L1INFO. Cet objet est caractérisé par la
liste de ses attributs et son état est représenté par les valeurs de ses
attributs. Son comportement est caractérisé par les opérations qu’il peut
exécuter. (Voir tableau ci-dessous)
Attributs (avec ses états) Opérations

• N°Matricule : E0001, • Enregistrer dans le palmarès
de l’année académique 2011,
• Nom : KALOMBO ILUNGA, • Changer la promotion,
• Promotion : L2 INFO, • Défendre son mémoire et

quitter de l’I.S.S-KIN,
2. Formalisme général et exemple
Une classe se représente à l’aide d’un rectangle comportant plusieurs

compartiments.
Les trois compartiments de base sont :
• la désignation de la classe,
• la description des attributs,
• la description des opérations.
Deux autres compartiments peuvent être aussi indiqués :
• la description des responsabilités de la classe (multiplicités),

• la description des exceptions traitées par la classe.
Exemple : KALOMBO ILUNGA est un objet instance de la classe Personne.

Le syllabus de cours de CSI que vous tenez entre vos mains est une
instance de la classe Livre.

[42]
3. Définition des Compartiments de base
 ATTRIBUT ET OPÉRATION
Un attribut représente un type d’information contenu dans une classe.

Exemples : Matricule, Noms, Date de naissance, etc. sont des attributs de
la classe Personne. Une opération représente un élément de comportement
(un service) contenu dans une classe. Nous ajouterons plutôt les opérations
en conception objet, car cela fait partie des choix d’attribution des
responsabilités aux objets.
 ASSOCIATION
Une association représente une relation sémantique durable entre deux

classes. Exemple : une personne peut payer des frais. La relation payer est
une association entre les classes Personne et Frais. Donc l’association
représente une relation entre plusieurs classes.
Elle correspond à l’abstraction des liens qui existent entre les objets dans
le monde réel. Les multiplicités et les rôles des objets participant aux
relations complètent la description d’une association.
Attention : même si le verbe qui nomme une association semble privilégier

un sens de lecture, une association entre concepts dans un modèle du
domaine est par défaut bidirectionnelle. Donc implicitement, l’exemple
précédent inclut également le fait qu’un frais est payé par une personne.
 AGRÉGATION ET COMPOSITION
• Une agrégation est un cas particulier d’association non symétrique

exprimant une relation de contenance. Il s'agit d'une relation entre
deux classes, spécifiant que les objets d'une classe sont des
composants de l'autre classe. En outre elle permet donc de définir
des objets composés d'autres objets.
• L'agrégation permet d'assembler des objets de base, afin de
construire des objets plus complexes.
Les agrégations n’ont pas besoin d’être nommées : implicitement elles
signifient « contient», «est composé de». Une composition est une
agrégation plus forte impliquant que :
• un élément ne peut appartenir qu’à un seul agrégat composite (agrégation

non partagée) ;
• la destruction de l’agrégat composite entraîne la destruction de tous ses
éléments (le composite est responsable du cycle de vie des parties).

[43]
Dépôt Produits
1..* 0..*
Service Agents
1 0..*
 GÉNÉRALISATION, SUPERCLASSE, SOUS-CLASSE

Une superclasse est une classe plus générale reliée à une ou plusieurs
autres classes plus spécialisées (sous-classes) par une relation de
généralisation. Les sous-classes « héritent» des propriétés de leur
superclasse et peuvent comporter des propriétés spécifiques
supplémentaires.
Personne
Identification
Nom
Postnom
Prénom
Sexe
Adresse
Etudiant Responsable Etud. Agent Adminis.

DateNais Téléphone Téléphone
Promotion Profession Fonction
Qualité
Moyen de Trans.
Marque
Modele
Vitesse
Vitesse max.
Voiture Bateau Avion

Immatriculation Tirant d’eau Altitude
Cylindrée Nombre de voiles Portée

[44]
 Association à navigabilité restreinte
Par défaut, une association est navigable dans les deux sens. La réduction
de la portée de l'association est souvent réalisée en phase
d'implémentation, mais peut aussi être exprimée dans un modèle pour
indiquer que les instances d'une classe ne "connaissant" pas les instances
d'une autre.
 Association n-aire : il s'agit d'une association qui relie plus de deux

classes et souvent sont reconnues par le symbole losange et est
appelé en UML « Arité »
 Classe Association : il s'agit d'une classe qui réalise la navigation

entre les instances d'autres classes.

[45]
NB : Une classe d’association peut participer au modèle c’est-à-dire on peut

même la spécialisé
Étudiant Frais
Paiement
Numéraire Dérogation
 Association binaire
Une association binaire est matérialisée par un trait plein entre les classes
associées. Elle peut être ornée d’un nom, avec éventuellement une
précision du sens de lecture (▸ ou ◂).
1 Concerne 1.. *
Étudiant Bordereau de frais
 Multiplicité ou cardinalité comme en merise
La multiplicité associée à une terminaison d’association, d’agrégation ou

de composition déclare le nombre d’objets susceptibles d’occuper la
position définie par la terminaison d’association. Voici quelques exemples
de multiplicité :
• Exactement un : 1 ou 1..1
• Plusieurs : * ou 0..*
• Au moins un : 1..*
• De un à six : 1..6
Dans une association binaire comme démontrer ci-haut, la multiplicité sur

la terminaison cible contraint le nombre d’objets de la classe cible pouvant
être associés à un seul objet donné de la classe source (la classe de l’autre
terminaison de l’association).
Dans une association n-aire, la multiplicité apparaissant sur le lien de

chaque classe et s’applique sur une instance de chacune des classes, à
l’exclusion de la classe-association et de la classe considérée.

[46]
Par exemple, si on prend une association ternaire entre les classes (A, B,
C), la multiplicité de la terminaison C indique le nombre d’objets C qui
peuvent apparaître dans l’association avec une paire particulière d’objets
A et B.
Remarque 1 :
Pour une association n-aire, la multiplicité minimale doit en principe, mais

pas nécessairement, être 0. En effet, une multiplicité minimale de 1 (ou
plus) sur une extrémité implique qu’il doit exister un lien (ou plus) pour
TOUTES les combinaisons possibles des instances des classes situées aux
autres extrémités de l’association n-aire.
Remarque 2 :
Il faut noter que, pour les habitués du modèle entité/relation, les

multiplicités sont en UML « à l’envers » (par référence à Merise) pour les
associations binaires et « à l’endroit » pour les n-aires avec n>2.
Entité Association UML

Entité Classe
Association (Relation) Association (Classe)
Occurrence Objet
Cardinalité Multiplicité
MCD, MOD Diagramme de classe
MLD Brute et Validé Diagramme d’Objet
Répartition en plusieurs sites Diagramme de déploiement
MLT Diagramme de composant
Cardinalités Multiplicités
1,0 0..1
1,1 11
0, N 0.. * ou *
1, N 1.. N
N, N2 N.. N
1. Ou absence de cardinalité (par défaut)

2. N,N : permet par exemple de spécifier qu’un segment doit connecter
entre trois postes et huit postes. Les cardinalités du côté Poste travail
seront (3,8) dans le modèle entité-association et 3...8 avec UML2.
Au niveau de la conception, il est important de déterminer correctement le

chiffre maximal des cardinalités. En effet, les méthodes de conception
reposent sur la transformation des entités (ou classes) et des associations
en fonction des cardinalités maximales (le processus que nous proposons
dans cet ouvrage ne déroge pas à cette règle).

[47]
Les cardinalités minimales précisent les liens d’associations et nécessitent

parfois l’intervention d’un programmeur, mais elles n’ont pas une grande
influence sur la construction de la base de données. Notez que la cardinalité
minimale 0 autorise une valeur NULL dans la base, que la cardinalité
minimale 1 interdit une valeur NULL et que la cardinalité minimale N induit
une vérification de cette contrainte, soit par programme, soit par
déclencheur (trigger).
Lecture des multiplicités
Segment
Poste de travail
1..* 0..1 Ind_IP
N°Serie
Nom
Ad_IP
Longeuer
Type_Poste
Se lit : « Un poste de travail est Se lit : « Un segment connecte au

connecté à 0 ou à 1 segment » minimum 1 et au maximum N postes
 Attribut »
Un attribut est une propriété élémentaire d’une classe. Pour chaque objet
d’une classe, l’attribut prend une valeur (sauf cas d’attributs multivalués).
Caractéristiques des attributs
Le nom de la classe peut être qualifié par un « stéréotype ». La description

complète des attributs d’une classe comporte un certain nombre de
caractéristiques qui doivent respecter le formalisme suivant :
• Visibilité/Nom attribut : type [= valeur initiale {propriétés}]

– Nom d’attribut : nom unique dans sa classe.
– Type : type primitif (entier, chaîne de caractères…) dépendant des types
disponibles dans le langage d’implémentation ou type classe matérialisant
un lien avec une autre classe.
– Valeur initiale : valeur facultative donnée à l’initialisation d’un objet de

la classe.
– {propriétés} : valeurs marquées facultatives (ex. : « interdit » pour mise
à jour interdite). Un attribut peut avoir des valeurs multiples. Dans ce cas,
cette caractéristique est indiquée après le nom de l’attribut (ex. : prénom
[3] pour une personne qui peut avoir trois prénoms). Un attribut dont la
valeur peut être calculée à partir d’autres attributs de la classe est un
attribut dérivé qui se note « /nom de l’attribut dérivé ».

[48]
 Opération
Une opération est une fonction applicable aux objets d’une classe. Une
opération permet de décrire le comportement d’un objet. Une méthode est
l’implémentation d’une opération.
Chaque opération est désignée soit seulement par son nom soit par son
nom, sa liste de paramètres et son type de résultat. La signature d’une
méthode correspond au nom de la méthode et la liste des paramètres en
entrée.
Caractéristiques
La description complète des opérations d’une classe comporte un certain

nombre de caractéristiques qui doivent respecter le formalisme suivant :
• Visibilité Nom d’opération (paramètres) [: [type résultat] {propriétés}]
– Nom d’opération : utiliser un verbe représentant l’action à réaliser.
– Paramètres : liste de paramètres (chaque paramètre peut être décrit, en
plus de son nom, par son type et sa valeur par défaut). L’absence de
paramètre est indiquée par ().
– Type résultat : type de (s) valeur(s) retourné(s) dépendant des types
disponibles dans le langage d’implémentation. Par défaut, une opération ne
retourne pas de valeur, ceci est indiqué par exemple par le mot réservé «
void » dans le langage C++ ou Java.
– {propriétés} : valeurs facultatives applicables (ex. : {query} pour un
comportement sans influence sur l’état du système).
Visibilité des attributs et opérations
Chaque attribut ou opération d’une classe peut être de type public, protégé,
privé ou paquetage. Les symboles + (public), # (protégé), - (privé) et ~
(paquetage) sont indiqués devant chaque attribut ou opération pour
signifier le type de visibilité autorisé pour les autres classes.
Les droits associés à chaque niveau de confidentialité sont :
• Public (+) Attribut ou opération visible par tous.
• Protégé (#) Attribut ou opération visible seulement à l’intérieur de la
classe et pour toutes les sous-classes de la classe.
• Privé (-) Attribut ou opération seulement visible à l’intérieur de la classe.
• Paquetage (~) Attribut ou opération ou classe seulement visible à
l’intérieur du paquetage où se trouve la classe.
Caractéristiques : Un attribut ou une opération peut être défini non pas au

niveau des instances d’une classe, mais au niveau de la classe.

[49]
Il s’agit soit d’un attribut qui est une constante pour toutes les instances
d’une classe soit d’une opération d’une classe abstraite ou soit par exemple
d’une opération « créer » qui peut être définie au niveau de la classe et
applicable à la classe elle-même.
C’est le soulignement de l’attribut ou de l’opération qui caractérise cette

propriété. L’attribut « province » est de type classe et l’opération « créer »
est une opération exécutable au niveau de la classe.
Personnes
- matricule
- nom
- postnom
- prenom [3] Dans le champ prénom le chiffre
- sexe 3 signifie qu’une personne peut
avoir trois prénoms
- datenais
- province
+ créer
+ enregistrer ()
+ modifier ()
+rechercher
Interface ()
# Supprimer ()
En UML, une interface définit un contrat que doivent respecter les classes
qui réalisent l’interface. Une interface est identifiée par son nom. Les
objets instances des classes qui réalisent des interfaces sont aussi des
instances des interfaces. Cependant une classe peut réaliser plusieurs
interfaces, et une interface peut être réalisée par plusieurs classes. Une
classe d’interface permet de décrire la vue externe d’une classe. La classe
d’interface, identifiée par un nom, comporte la liste des opérations
accessibles par les autres classes. Le compartiment des attributs ne fait pas
partie de la description d’une interface. L’interface peut être aussi
matérialisée plus globalement par un petit cercle associé à la classe source.
La classe utilisatrice de l’interface est reliée au symbole de l’interface par
une flèche en pointillé. La classe d’interface est une spécification et non
une classe réelle. Une classe d’interface peut s’assimiler à une classe
abstraite.

[50]
2.2 Diagramme de Package
Ne soyez pas surpris d’avoir lu (vu) encore le package à ce niveau, comme

nous l’avions précisé aux précédentes littératures que plus tard nous
reviendrons au DIAGRAMME DE PACKAGE, le voici dans son endroit
approprié. Un package permet de regrouper des classes, des interfaces et
des packages. Classes, interfaces et packages ne peuvent avoir qu’un seul
package dans lequel ils sont regroupés. La possibilité d’établir un lien entre
des classes et des interfaces dépend du lien qui existe entre les packages
qui les contiennent. Les packages se représentent à l’aide d’un rectangle
possédant un onglet dans lequel est inscrit le nom du package.

[51]
Les éléments contenus se représentent dans le rectangle. La taille du

rectangle s’adapte à la taille de son contenu.
Nous présenterons pour ce point un seul package HOMME et le lien entre
les packages ainsi que d’autre package vous les verrez dans la présentation
du Diagramme de Classes.
HOMME
Personne
Identification
Nom
Postnom
Prénom
Sexe
Adresse
Etudiant Responsable Etud. Agent Adminis.

DateNais Téléphone Téléphone
Promotion Profession Fonction
Qualité

[52]
• Présentation des Diagrammes de classes de la gestion des paiements des frais
HOMME FINANCE
Personne Frais
1..* 1..* +CodeFr : varchar(5)
+ Id : varchar(10)
- nom : varchar(25) -LibeFr : varchar(40)
- postnom :varchar(20) -MontFr : integer()
- prenom [3] :varchar(40) -AnnAcad :varchar(9)
- sexe :varchar(1)
- Adresse : varchar (50)
- province : varchar(25)
Paiement
-IdPaie : varchar(12)
-MontP : integer()
#DatePaie : date()
Étudiant Resp. Etud. Agent Administratif

#DateNais : date () +Téléphone : varchar(10) +Téléphone : varchar(10)
-Promotion : varchar (9) -Profession : varchar(30) -Fonction : varchar(30) Numéraire Dérogation
-Qualité : varchar(25) -TypBille : varchar(5) -Autorite: varchar(30)
-NbreBillet : integer() -MontChiff :integer()
#Serie : integer -MontLt : varchar(max)
-DateDer :date()
1 Contrôle 1..*

[53]

[54]

[55]
2.3. Présentation de Diagramme d’objets
Ce type de diagramme UML2 montre des objets (instances de classes dans

un état particulier) et des liens (relations sémantiques) entre ces objets.
Les diagrammes d'objets s'utilisent pour montrer un contexte (avant ou
après une interaction entre objets par exemple). Ce type de diagramme sert
essentiellement en phase exploratoire, car il possède un très haut niveau
d'abstraction. Lors de la présentation de diagramme d’objet, il faut tenir
compte de toutes les instances se trouvant dans les classes et qui
nécessitent leurs précisions dans la conception. Les attributs constants
peuvent aussi être décomposés pour en faire les objets. Le diagramme
d’objets ci-dessous se diffère de notre diagramme de classes de la gestion
de paiement des frais par les éléments suivants :
➢ Présence des opérations : Dans le diagramme de classe de la gestion

de paiements des frais académiques nous n’avions pas précisées les
opérations de chacune de classe parce que nous savons bien que ce
diagramme a quelque classe dont les instances nécessitent la
décomposition en objets (le cas de la classe frais) l’instance Frais
académiques a des éléments qui doivent être précis. Attention, cela
ne veut pas dire que dans le diagramme de classe on ne présente pas
des opérations tout dépend de votre conception. Si vous remarquez
dans votre analyse certaines classes du diagramme de classes les
instances (enregistrements) nécessitent la précision pour les faire
objets l’endroit approprié pour la présentation des opérations c’est
dans le diagramme des objets ;
➢ Présence des objets : Frais académiques, Promotion, Province, et
classe association Inscription. Comme nous venons de dire ci-haut la
classe frais a une instance Frais académique qui doit normalement
préciser ses éléments tels que : Frais liés à la construction du site ou
campus de l’institut ; Frais liés à la carte d’étudiants ainsi de suite.
Raison pour laquelle vous avez vu la présence de l’objet Frais
académiques. La constante Province de notre classe Personne est
devenue objet pour simple raison plusieurs personnes peuvent se
retrouver dans la même province. Cette décomposition est liée à la
notion d’Héritage et le non-redondance. Enfin l’attribut promotion de
la sous classe Étudiant sort de sa classe pour devenir l’objet et dans
sa présentation, nous savons bien qu’un étudiant peut faire au
maximum deux fois la même promotion raison pour laquelle notre
classe association inscription à la multiplicité 2 pour signifier qu’au-
delà de trois l’étudiant est sensé de quitter la faculté (NAF).

[56]
NB : Dans une bonne conception d’un SI avant de présenter le diagramme

d’objets nous sommes obligés :
 De répertorier toutes les instances de différentes classes ;

 La présentation de diagramme d’objets n’exclus pas la présence des
toutes les classes de votre diagramme de classe (le cas de notre
diagramme de classe pour la gestion de paiement de frais) si nous
avons voulu le présenter ainsi c’est pour une brève explication
normalement nous devrons présenter toutes les classes ainsi que les
objets de leurs classes, les packages, la liaison entre les packages et
les opérations de toutes les classes et objets.

[57]
Personne
Frais
+ Id : varchar(10) 1
1..* 1..* +CodeFr : varchar(5)
+ CodeProv : varchar(5) -LibeFr : varchar(40)
- nom : varchar(25)
-MontFr : integer()
- postnom :varchar(20)
Province +AnnAcad :varchar(9)
- prenom [3] :varchar(40)
- sexe :varchar(1) 1..* 1
+CodeProv : varchar(5) + Ajouter()
- Adresse : varchar (50) + Rechercher()
-LibeProv : varchar(30)
+ Modifier()
+ Ajouter() + Supprimer
+ Rechercher() + Ajouter()
+ Modifier() + Rechercher()
+ Supprimer()
+ Annuler()
Frais Académique
1..*
+CodeFr : varchar(5)
-Intitulé : varchar(30)
-Pourcentage : Integer()
Étudiant Resp. Etud. Agent Administratif + Ajouter()
+ Id : varchar(10) + Rechercher()
+ Id : varchar(10) +Téléphone : varchar(10) + Id : varchar (10) + Modifier()
#DateNais : date () -Profession : varchar(30) +Téléphone : varchar(10)
-Qualité : varchar(25) -Fonction : varchar(30)
+ Ajouter() + Ajouter() + Importer()
+ Rechercher() + Rechercher() + Exporter()
Promotion
1...*
1..* Inscrition
+ CodePM : varchar(10)
-LibPM :varchar(25)
+ CodePM : varchar(10)
+ AnnAcad : varchar (9)
+ Ajouter()
+ Rechercher()
+ Ajouter()
+ Rechercher()
[58]
2.3 Diagrammes de Composants et de Déploiements

2.3.1 Diagramme de composants
Les diagrammes de composants permettent de décrire l'architecture

physique et statique d'une application en termes de modules : fichiers
sources, librairies, exécutables, etc. Ils montrent la mise en œuvre
physique des modèles de la vue logique avec l'environnement de
développement. Les dépendances entre composants permettent notamment
d'identifier les contraintes de compilation et de mettre en évidence la
réutilisation de composants. Les composants peuvent être organisés en
paquetages, qui définissent des sous-systèmes. Les sous-systèmes
organisent la vue des composants (de réalisation) d'un système. Ils
permettent de gérer la complexité, par encapsulation des détails
d'implémentation. Le schéma ci-dessous montre le différent type de
module :

[59]
2.3.2 Diagramme de déploiements
Les diagrammes de déploiement montrent la disposition physique des

matériels qui composent le système et la répartition des composants sur
ces matériels. Les ressources matérielles sont représentées sous forme de
nœuds. Les nœuds sont connectés entre eux, à l'aide d'un support de
communication. La nature des lignes de communication et leurs
caractéristiques peuvent être précisées. Les diagrammes de déploiement
peuvent montrer des instances de nœuds (un matériel précis), ou des
classes de nœuds. Les diagrammes de déploiement correspondent à la vue
de déploiement d'une architecture logicielle.
Première représentation
Deuxième représentation

[60]

[61]
Section 3 Axe Dynamique

3.1 Diagramme de collaborations
Les diagrammes de collaboration montrent des interactions entre objets

(instances de classes et acteurs). Ils permettent de représenter le contexte
d'une interaction, car on peut y préciser les états des objets qui
interagissent. Ce diagramme autrement appelé le diagramme de structure
composite son rôle est de représenter un assemblage des éléments avec
comme rôles l’interaction en vue de réaliser une fonction donnée. Il existe
deux manières de représenter une collaboration :
• représentation par une collaboration de rôles,

• représentation par une structure composite : le diagramme de structure
composite.
3.2 Diagramme d’états transitions
Un diagramme d’états-transitions rassemble et organise les états et les

transitions d’un classeur donné. Bien entendu, le modèle dynamique du
système comprend plusieurs diagrammes d’états-transitions. Il est
souhaitable de construire un diagramme d’états-transitions pour chaque
classeur (qui, le plus souvent, est une classe) possédant un comportement
dynamique important. Un diagramme d’états-transitions ne peut être
associé qu’à un seul classeur.

[62]
Tous les automates à états finis des diagrammes d’états-transitions d’un

système s’exécutent concurremment et peuvent donc changer d’état de
façon indépendante. Ce diagramme est plus utilisé à la représentation des
automates d'états finis, sous forme de graphes d'états, reliés par des arcs
orientés qui décrivent les transitions. En outre ils permettent de décrire
les changements d'états d'un objet ou d'un composant, en réponse aux
interactions avec d'autres objets/composants ou avec des acteurs. Un état
se caractérise par sa durée et sa stabilité, il représente une conjonction
instantanée des valeurs des attributs d'un objet. Une transition représente
le passage instantané d'un état vers un autre. Une transition est déclenchée
par un événement. En d'autres termes : c'est l'arrivée d'un événement qui
conditionne la transition. Les transitions peuvent aussi être automatiques,
lorsqu'on ne spécifie pas l'événement qui la déclenche. En plus de spécifier
un événement précis, il est aussi possible de conditionner une transition, à
l'aide de "gardes" : il s'agit d'expressions booléennes, exprimées en
langage naturel (et encadrées de crochets). Ne confondez pas du point de
vue forme la représentation du diagramme d’états transition à celle de
diagramme d’activité que nous avons présenté dans les pages précédentes.

[63]

[64]
Chapitre 4 Utilisation du logiciel Entreprise Architect

4.1 Installation
Après avoir double-cliqué sur son icône, nous avons cette fenêtre, et nous
allons cliquer sur le bouton « Next »
Nous acceptons le terme du contrat de licence et après, nous cliquons sur

le bouton « Next », « Next »

[65]
L’assistant d’installation précise le profil d’utilisateur et le nom de

l’entreprise nous allons cliquer sur le bouton « Next », « Next », voir la
fenêtre suivante :
Dans cette fenêtre nous avons la détermination du répertoire principale

auquel notre application sera stocké. Nous cliquons sur « Next » et dans

[66]
une autre fenêtre qui va s’afficher nous cliquons encore sur le bouton
« Next ». Après nous cliquons sur « Instal »

[67]
4.2 Utilisation du logiciel SPARX
Double-cliquer sur l’icône
Présentation du Menu Principal du SPARX

[68]
Dans cette fenêtre nous allons cliquer sur le menu Fichier, New Project.
Dans la fenêtre qui s’ouvre, nous allons préciser l’emplacement de notre
projet (Répertoire) et nous cliquons sur « Enregistrer ». La fenêtre ci-
dessous, s’affiche et nous allons choisir les Diagrammes pour notre projet
et nous allons cliquer sur OK.

[69]
Alors amusons-nous bien dans cette fenêtre.

[70]
A. PREREQUIS
• Notions sur les SI

• Avoir la maîtrise de la méthode Merise
B. BIBLIOGRAPHIE
• Jean Luc Baptiste ; Modélisation des données et des traitements /
langage SQL. ENI éditions.
• Joseph Gabay, David Gabay ; UML 2 Analyse et Conception. Edition
Dunod.
• Fien VAN DER HEYDE 6 LAURENT debrauwer ; UML2 Initiation,
exemples et exercices corrigés. Eni éditions
• Christian SOUTOU ; UML 2 pour les bases de données. Edition Eyrolles
• Pascal Roques – franck Vallée ; UML2 en action, de l’analyse des
besoins à la conception 4ème édition. Edition Eyrolles
• Pascal Roques ; UML2 par la pratique, études de cas et exercices
corrigés 5ème édition. Edition Eyrolles
• Pascal Roques ; UML2 Modéliser une application web 4ème édition.
Edition Eyrolles
• Xavier Blanc, Isabelle Mounier ; UML2 pour les devéloppeurs, cours
avec exercices corrigés. Edition Eyrolles
• Franck Barbier ; UML2 et MDE, Ingénierie des modèles avec études de
cas. Edition Dunod

Uml2 LMD2

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

Uml2 LMD2

Transféré par

Droits d'auteur :

Formats disponibles

[1]

En tant qu’enseignant qui encadre les futures responsables d’entreprise,

Cependant, à la lecture de ce support, vous aller découvrir une méthode

Permettre aux étudiants en informatique de gestion de l’I.S.S-KIN de doter

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 1 sur

À la fin de ce cours de Conception de Système d’Information le participant

✓ Décrire, de comprendre et d’analyser efficacement plusieurs aspects

Définitions des quelques concepts

• OMGL = Outils et Modèles pour le Génie Logiciel

• Augmenter la productivité en améliorant l’efficacité des utilisateurs

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 2 sur

Facteurs de la complexité de l'informatisation

• Difficultés techniques de l'informatique : complexité de la mise en œuvre

Qui fait quoi dans la conception du système d’information (CSI) ?

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 3 sur

qualité du projet, la gestion administrative du projet… ; le conseil ponctuel

Problématique du management de projet

Leurs actions ont conduit à une diffusion et une reconnaissance des

En ce qui concerne les techniques, la planification a occupé pendant

Définitions d’un Projet

La langue française a attaché au mot projet des degrés de précision divers.

Une seconde définition le décrit comme une étude préparatoire, parfois

Un projet est défini comme un ensemble d’activités à effectuer pour

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 4 sur

Une activité répétitive est la réponse à une occurrence d’événement

Tout projet est, au contraire, temporaire : par nature, il est destiné à

 Les définitions normalisées

Le référentiel du PMI, appelé Guide du PMBOK (Project Management Body

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 5 sur

Le contenu de cette norme, intitulée « Systèmes de management de la

• Le délai donne lieu à un management du temps dont le rôle est de définir

• Les moyens affectés constituent le budget du projet, qui est transformé

En se référant à la description classique d’une fonction managériale, on

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 6 sur

• Analyser : il s’agit de déterminer le chemin que l’on va emprunter pour

• Organiser : on repère les contraintes d’enchaînement entre les tâches afin

• Piloter : cette activité comprend le suivi de l’avancement du projet, en

❖ Comment manager des projets Systèmes d’informations

 Caractéristiques d’un projet système d’information

Il convient tout d’abord de rappeler la définition d’un système

Le triplet {objectif, moyens, délai} présente, dans le domaine système

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 7 sur

2. L’objectif du projet n’est parfaitement défini qu’à l’achèvement du

La démarche d’élaboration est généralement guidée par une rationalité

 Les objectifs des projets systèmes d’information

Il est parfois utile de distinguer le système d’information et le système

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 8 sur

partir de ces informations, selon des processus visant une finalité de

Dans cette perspective, même si un projet système d’information inclut un

L’objectif stratégique d’améliorer l’efficacité des promotions peut conduire

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 9 sur

d’aide à la vente pour les commerciaux. Comprendre les objectifs du projet

Pour les projets système d’information, la complexité est accrue par le

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 10 sur

Chapitre I. La Modélisation objet

Le but de la modélisation des systèmes d’information est d’aboutir à une

Le modèle sert donc des objectifs différents suivant l’étape de

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 11 sur

apparaît comme la solution nécessaire au problème. Ainsi,

Le modèle en tant qu’abstraction d’un système s’accorde parfaitement bien

I.1 Pourquoi modéliser ?

Modéliser un système avant sa réalisation permet de mieux comprendre le

Ir. BALUMANGANI KITAMBALA Chef de Travaux Page 12 sur