Hela LAJMI

Conception des SI Assistant  Professor

LSIM2

Héla  Lajmi
Plan
Chapitre  1
• Système  d’information
• Cycle  de  vie  d’un  logiciel
• Conception  des  SI  
• Concepts  importants  de  l’approche  objet
Chapitre  2
• Introduction
• Historique  UML
• Diagrammes  UML
• Types  de  visualisations
 Système  d’information
• On  peut  décomposer  le  terme  Système  d’information  en :
Système :  Ensemble  de  composantes  travaillant  en  collaboration  pour  
accomplir  une  tache  particulière  portant  des  données  initiales.

Information :elle  doit  être  collectée,  vérifiée,  validée,  représentée,  

codée,  stockée  et  bien  manipulée.

l'informatique  est  au  cœur  de  toutes  les  grandes  entreprises.  Le  système  
d'information  d'une  entreprise  est  composé  de  matériels  et  de  logiciels.
Les  logiciels  
• Le cycle  de  vie  d'un  logiciel  désigne  toutes  les  étapes  du  
développement  d'un  logiciel,  de  sa  spécification  et  conception  à  sa  
disparition.  

• L'objectif  d'un  tel  découpage  est  de  permettre  de  définir  des  jalons  
intermédiaires  permettant  la  conformité  du  logiciel  avec  les  besoins  
exprimés,  et  la  vérification  du  processus  de  développement  
(l'adéquation  des  méthodes  mises  en  œuvre)
Cycle  de  vie  d’un  Logiciel  (en  cascade)
Cycle  de  vie  d’un  Logiciel  (en  V)
Conception  des  SI

Le  système  d’information  (SI)  englobe  donc  deux  aspects :

*Les  méthodes  d’analyse  et  de  conception  (Modèle  E/A…)  et,

*Les  environnements  de  programmation  (modèle  relationnel…)

Pourquoi  modéliser  et  qui  doit   modéliser??

Pourquoi  Modéliser?
Modéliser  un  système   avant  sa   réalisation   permet   de:

• mieux   comprendre  le   fonctionnement   du  système.  

• maîtriser  sa  complexité  

• assurer  sa   cohérence

• assurer  la   bonne   communication  entre   les  membres   de   l’équipes   et   par  conséquent,  
aboutir  à   une  compréhension   commune   aux  différentes   parties   prenantes   d'un  problème  
donné.
 Pourquoi  Modéliser?  (suite)
• mieux  répartir  les  tâches  et  automatiser  certaines  d'entre  elles

• Réduire  les  coûts et  les  délais

• générer  automatiquement  le  code  et  effectuer  des  allers-­‐retours entre  le  code  et  le  

modèle  sans  perte  d'information

• assurer  un  bon  niveau  de  qualité  et  une  maintenance  efficace
Méthodologies  d’analyse  et  de  conception
• Approche  Fonctionnelle:  
Exemple  SADT,  Modélisation  que  du  traitement  (les  données  non)  pour  les  applications  peu  
complexe.

• Approche  Systémique:  
Exemple  Merise,  Modélisation  des  données  et  des  traitements  séparément  pour  des  applications  de  
complexité  moyenne.

• Approche  Orientée  Objet:

Exemple  OMT,  Modélisation  des  objets  (encapsulation  des  données  et  des  traitements)  pour  tout  
type  d’application.
Méthodologies  d’analyse  et  de  conception
Les  approches  structurés  (fonctionnelle  ou  systémique)  ne  sont  pas  adaptés  à  la  
conception  et  au  développement  des  applications  qui  évoluent  souvent  dont  la  
complexité  croit  continuellement.

è Ces  applications  nécessitent  une  maintenabilité  accrue,  manquent  de  

traçabilité,  de  modularité,  d’extensibilité  et  de  réutilisabilité.

L’approche  Orientée  objet:  consiste  à  modéliser  informatiquement  un  ensemble  

d’éléments  d’une  portée  du  monde  réel  en  un  ensemble  d’entités  informatiques  
appelés  OBJETS.  
 Méthodologies  d’analyse  et  de  conception
L’approche  Orientée  objet

Quel  que  soit  la  complexité  et  l’évolution  des  applications,  on  peut  réussir  à  les  
modéliser  et  développer  par  l‘approche  OO.

Avantage  de  l’OO:

ØLa  modularité:    la  programmation  modulaire  permet  la  réutilisation  du  code,  via  
l’écriture  de  librairie

ØLa  réutilisabilité:  réutilisabilité  des  composantes  logiciels  (encapsulation,  

généralisation,  polymorphisme)
Méthodologies  d’analyse  et  de  conception
L’approche  Orientée  objet

ØL’extensibilité  (pour  une  meilleure  productivité  des  développeurs  et  une  plus  
grande  qualité  des  applications)

ØLa  traçabilité:  ce  qu’on  fait  en  conception,  on  trouve  son  image  en  
programmation.

ØLa  maintenabilité:  l'application  peut  être  facilement  maintenue,  probablement  

par  une  autre  équipe  et,  qui  plus  est,  pas  nécessairement  de  la  même  société  que  
celle  ayant  créé  l'application.
Concepts  importants  de  l’approche  objet
l'approche  objet  rapproche  les  données  et  leurs  traitements.  Mais  
cette  approche  ne  fait  pas  que  ça,  d'autres  concepts  importants  sont  
spécifiques  à  cette  approche  et  participent  à  la  qualité  du  logiciel.
Concepts  importants  de  l’approche  objet
• Encapsulation  

L'encapsulation consiste à masquer les détails d'implémentation d'un objet,

en définissant une interface. L'interface est la vue externe d'un objet, elle

définit les services accessibles (offerts) aux utilisateurs de l'objet.

L'encapsulation garantit l'intégrité des données, car elle permet d'interdire,

ou de restreindre, l'accès direct aux attributs des objets

Concepts  importants  de  l’approche  objet

L'héritage est un mécanisme de transmission des caractéristiques

d'une classe (ses attributs et méthodes) vers une sous-­‐classe.

Plusieurs classes peuvent être généralisées en une classe qui les

factorise, afin de regrouper les caractéristiques communes d'un
ensemble de classes.
Concepts  importants  de  l’approche  objet
Héritage

L'héritage peut être simple ou multiple. L'héritage évite la duplication

et encourage la réutilisation.

Exemple:
Concepts  importants  de  l’approche  objet

Le  polymorphisme  

représente  la  faculté  d'une  méthode  à  pouvoir  s'appliquer  à  des  objets  

de  classes  différentes.  Le  polymorphisme  augmente  la  généricité,  et  
donc  la  qualité,  du  code.
Concepts  importants  de  l’approche  objet
Agrégation
Il s'agit d'une relation entre deux classes, spécifiant que les objets
d'une classe sont des composants de l'autre classe. L'agrégation
permet donc d'assembler des objets de base, afin de construire des
objets plus complexes.

Exemple:
Concepts  importants  de  l’approche  objet
Notion  de  classe
Une classe est un type de données abstrait qui précise des
caractéristiques (attributs et méthodes) communes à toute une famille
d'objets et qui permet de créer (instancier) des objets possédant ces
caractéristiques.
 Plan  
Chapitre  2
•Introduction
• Historique
• Diagrammes  UML
• Types  de  visualisations
Pourquoi  un  langage  de  modélisation  Unifié?
• Difficultés  de  l’échange  de  modèles  entre  équipes  de  concepteurs  et  entre  
concepteurs  et  clients.  

• Synergie  de  compétence:  différents  modèles  pour  une  même  application  

développée  par  différentes  équipes  de  concepteurs  avec  différentes  méthodes.
UML:  Unified Modelling Language
Ø Est  le  standard pour  la  Conception  orientée  Objet  des  Systèmes  d’Information.

Ø Est  un  langage  formel  qui  couvre  le  cycle  de  développement  des  logiciels  de  la  
spécification  des  besoins  à  l’implantation.

Ø Est  un  support  de  communication  :

• conséquence  de  la  standardisation
• On  peut  faire  travailler  des  équipes  différentes  avec  des  méthodes  
différentes  sur  les  parties  d’une  même  application.
UML:  Unified Modelling Language

Ø La  structure  des  diagrammes  UML  et  la  notation  graphique  des  

éléments  de  modélisation  sont  normalisées

ØUML  n’est  pas  un  processus  de  développement  

ØUML  n’est  pas  un  langage  de  programmation
 Plan  
Chapitre  2
• Introduction
•Historique
• Diagrammes  UML
• Types  de  visualisations
Historique

• 1993-­‐1994 1995 1996 01 - 1997 11 - 1997

Soumission à Adoption par
l’OMG l’OMG
Booch’93
jan.
Autres Unified Method 0.8 UML 0.9 UML 1.0 UML 1.1
OMT - 2 Partenaires Normalisation  
OOSE
en   1999
Autres  tentatives  d’unification  de  
méthodes  : UML  1.3
Fusion  et  Eurométhode

UML   2.0
 Plan  
Chapitre  2
• Introduction
• Historique
•Diagrammes   UML
• Types  de  visualisations
 Diagrammes  UML
• Neuf  diagrammes  représentant  chacun  un  aspect  particulier  du  SI  à  modéliser  :
• de   cas  d’utilisation  :  décrivent   les   vues   utilisateurs  du  système,

• de   classes  :  décrivent   les   classes   et   les   liens  qui  les  relient,

• d’objets  :   représentent   des   instances   de   diagrammes   de   classes,

• de   composants:   décrivent  les  dépendances  de  compilation   ou   d’exécution  entre   les  

différents  modules  constituant   un  logiciel,

• les  diagrammes  de   déploiement:   décrivent  les  unités   de   programmes  et   leurs  processus  
d’affectation.
Diagrammes  UML
• d’états-­‐transitions  :  décrivent   les   cycles   de   vie  des   objets,

• de   collaboration  :  décrivent   les   interactions   entre   les  objets,

• de   séquence   :   représentent   des   diagrammes   de   collaboration  ordonnés  dans   le  
temps,

• d’activités   :  décrivent   la   sémantique  des   méthodes  en  termes  d’actions,

Bibliographie
• Muller,   P.  A.,   &   Gaertner,   N.  ( 2000). Modélisation   objet   avec   UML (Vol.   514).  Paris:   Eyrolles.  

• Piechocki,   L.   ( 2007).  UML,   le   langage   de   modélisation   objet   unifié. Laurentpiechnocki.   developpez.   com.

• Laurent,   G.   ( 2007)  Modélisation   orientée   objets   avec   UML.

• Faiez.   G   ( 2015).  Cours   Modélisation   orientée   objets   UML.

 Plan  
Chapitre  2
• Introduction
• Historique
• Diagrammes  UML
•Types  de  visualisations
• Vue   Fonctionnelle  
• Vue   statique
• Vue   dynamique
 Types  de  visualisation  dans  UML
Visualisation  « Use  Cases » Visualisation  Logique

Vue  Fonctionnelle Vue  Dynamique Vue  Statique

D.  des  cas  d’utilisation   D.  activité D.  Classe

D.  Collaboration
D.  Objet
==>    Les  différents  types  de  
D.  Séquence  
diagrammes  UML  combinés  offrent  une   D.  composant
vue  complète  des  aspects  statiques  et   D.  Etat
D.  déploiement
dynamiques  d'un  système.
Types  de  visualisation  dans  UML
Visualisation  « Use  Cases » Visualisation  Logique

Vue  fonctionnelle Vue  Dynamique Vue  Statique

D.  des  cas  d’utilisation   D.  activité D.  Classe

D.  Collaboration
D.  Objet
D.  Séquence  
D.  composant
D.  Etat
D.  déploiement
 Plan  
Chapitre  2
• Introduction
• Historique
• Diagrammes  UML
• Types  de  visualisations
•Vue  Fonctionnelle  
• Vue  statique
• Vue  dynamique
Vue  Fonctionnelle:   Diagramme  des  cas  
d’utilisation   «Use  cases»
• Un  cas  d’utilisation  décrit  un  ensemble  d’actions  réalisées  par  le  système
qui  produit  un  résultat  observable  pour  un  acteur

• Son  objectif  est  de  structurer  les  besoins  des  utilisateurs  et  les  objectifs  
(fonctionnalités)    correspondants  d'un  système.

• Un  bon  Use  Case  représente  une  fonctionnalité  du  système  qui  est  complète  du  
début  jusqu’à  la  fin.  
«Use  cases»
Position  des  UC  dans  un  processus  de  modélisation  
Spécifications

Use Cases

Analyse Tests

Commencer par établir le diagramme des cas permet de :

Ø mener un développement orienté utilisateur et
Ø de découper le système global en grandes tâches qui pourront être
réparties entre les équipes de développement.
«Use  cases»  acteurs
• Les  acteurs  sont  déterminés  en  examinant  les  utilisateurs  directs  du  système  et  
leurs  responsabilités.      Ils  sont  représentés  sous  forme  de  petits  personnages  ou  
sous  forme  de  rectangle  avec  le  mot  clé  <<acteur>>
«Use  cases»  acteurs
• Les  acteurs  :
• Doivent  être  décrits  d’une  manière  simple  et  précise  avec  des  phrases  en  langage  naturel
• Peuvent  être  reliés  par  des  liens  de  généralisation/spécialisation  

Exemples  de  types  d’acteurs  :

• Humains : les utilisateurs du logiciel à travers son interface graphique
• Logiciels : déjà disponibles qui communiquent avec le système grâce à une interface logicielle
• Matériels : robots et automates qui exploitent les données du système ou qui sont pilotés par
le système
«Use  cases»:  relation  simple
«Use  cases»:  relation  d’inclusion  « include »
• Relation  d’inclusion  entre  cas  d'utilisation  

• L’instance  du  CU  source  contient  aussi  le  comportement  décrit  par  le  CU  destination.

• La  relation  d’inclusion  a  un  caractère   obligatoire:  La  source  doit  indiquer  à  quel  endroit  le  CU  
cible  doit  être  inclus

• Permet  de  décomposer  les  comportements  et  définir  des  comportements  partageables   entre  
plusieurs  CU.
«Use  cases»:  relation  d’extension  « extend »
• Relation  d’inclusion  entre  cas  d'utilisation
• L’instance  du  CU  source  ajoute  son  comportement  au  CU  destination  (si  la  
condition  est  réalisée).
• Le  CU  destination  étend  son  comportement  par  l’ajout  de  celui  du  CU  source,  
si  la  condition  est  vérifiée.
«Use  cases»:  relations  de  spécification
« Use  cases »
• Un  cas   d’utilisation  :
• Regroupe  une   famille   de   scénarios   d’utilisation
• Est   une   abstraction  du  dialogue  système/utilisateurs

• Quand  un  acteur  interagit   avec  le   système:

• Le   cas  d’utilisation  instancie   un   scénario

• L'ensemble   des   cas  d’utilisation  décrit   les   objectifs   du  système

• Utilité  des   cas   d’utilisation  pour  :
• les  utilisateurs   :   exprimer   les   besoins
• Les   analystes   :   comprendre
• Les   programmeurs  :   réaliser
• Les   testeurs  :  vérifier
 Description  des  cas  d’utilisation
Sommaire   d’identification  
Titre :         ………………..   Type :   …………………
Résumé :………………………………………………………………………………
Acteurs :
Date   de   création :                                               Date   de   mise   à   jour :…………………………………
Version :                                                                           Auteur(s) :

Description   des   Enchaînements :

Pré   conditions :
Scénario   nominal :
1.
2.
…
Enchaînements   alternatifs :
A1…
A2…
Contraintes  
….
Description  des  cas  d’utilisation
◦ Quelques  conseils  :
◦ Un  cas  d’utilisation  doit  être  :
◦ Simple

◦ Décrit  de  manière  claire  et  concise

◦ Le  nombre  d’acteurs  i nteragissant  avec  le  CU  doit  être  limité

◦ Lors  de  la  construction  d’un  CU,  il  faut  se  demander  :
◦ Quelles   sont  l es  tâches   de  l’acteur  ?

◦ Quelles   informations  l ’acteur  doit-­‐i l  c réer,  sauvegarder,   modifier,  détruire  ou  simplement  l ire  ?

◦ L’acteur  devra-­‐t-­‐i l  i nformer  le  système  des   changements   externes   ?

◦ Le  système   devra-­‐t-­‐i l  i nformer  l’acteur  des   conditions  i nternes  ?

Modélisation  objet  avec  UML

P.A.  Muller,  N.  Gaertner
Exemple
 Exercice:  Caisse  enregistreuse  
(extrait  de   UML  par   la  pratique,  Pascal  Roques,   Eyrolles)  

Le déroulement normal d’utilisation de la caisse est le suivant :

Ø Un client arrive à la caisse avec des articles à payer

Ø Le caissier enregistre le numéro d’identification de chaque article, ainsi que la quantité si elle
est supérieure à 1

Ø La caisse affiche le prix de chaque article et son libellé

Ø Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente la caisse affiche le
total des achats
 Exercice:  Caisse  enregistreuse  
(extrait  de   UML  par   la  pratique,  Pascal  Roques,   Eyrolles)  

Ø Le client choisit son mode de paiement : liquide (le caissier encaisse l’argent reçu, la caisse indique la
monnaie à rendre au client), chèque , carte de crédit (la caisse transmet une demande d’autorisation
à un centre d’autorisation)
Ø La caisse enregistre la vente et imprime un ticket.
Ø Le caissier donne le ticket de caisse au client.

Lorsque un paiement est terminé, la caisse transmet les informations sur le nombre d’articles vendus au
système de gestion de stocks.

Tous les matins, le responsable du magasin initialise la caisse pour la journée.

Travail demandé: Modéliser le diagramme des cas d’utilisation de la caisse

enregistreuse
 Conclusion
• Les  cas  d’utilisation  :

• Sont  de  bons  moyens  pour  modéliser  les  besoins  des  utilisateurs  par  les  utilisateurs.

• Les  avantages  :
• Un  formalisme  simple  :  
• Les   concepts   proposés   sont   faciles   à   comprendre   et   à   utiliser.

• Les  modélisations  résultats  (UC):  

• Faciles   à   comprendre,   à   lire   et   à   interpréter.

• Un  bon  moyen  de  communication  :  client/concepteur  et  concepteur/concepteur

Conclusion
• Les  limitations  :
• Subjectifs,  dépendant  de  l’utilisateur  :

• Peuvent  être  peu  précis,  ne  reflétant  pas  les  besoins  majeurs  de  l’utilisateur  ou  
interprétés  différemment.

• Pas  formels  :  pas  de  vérification  automatique  possible  ni  de  génération  des  autres  
diagrammes,  …
 Plan  
Chapitre  2
• Introduction
• Historique
• Diagrammes  UML
• Types  de  visualisations
• Vue  Fonctionnelle  
•Vue  statique
• Vue  dynamique