Vous êtes sur la page 1sur 33

INPTIC- 2013/ 2014

2 ième année Licence SERVICE et Resaux de Communication SRC

Systèmes d’information

COURS UML

Cours: 06 H. & TD: 06 H.

M. BOUKRARA Ammar

Introduction

Les années 70: Les entreprises concevaient des SI avec des propres méthodes (OO)

20 ans plus tard: On recense plus de 50 M.OO (toutes divergentes)

Divergence réside dans les modèles utilisés, les démarches

03 méthodes ont marqué leurs distinction:

1) La méthode OMT de James Rumbaugh

2) La méthode BOOCH'93 de Grady Booch

3) La méthode OOSE de Ivar Jacobson (Object Oriented Software Engineering)

UML (début des années 1990)

UML: un standard mondial de modélisation Objet

En 1997: Objet Management Group (OMG) Normalisation

Modélisation Objet

Modéliser le Monde réal (un domaine) par un ensemble d’entité Objet

Un Objet peut être:

1) Physique : (Enseignant, Livre, Voiture…)

2) Abstrait: (opération de vente, ligne commande, Adresse_Machine…)

UML utilise 09 Diagramme

1.

Diagramme de cas d’utilisation

2.

Diagramme de classes.

3.

Diagramme d’objets.

4.

Diagramme de composants.

5.

Diagramme de déploiement.

6.

Diagramme d’états.

7.

Diagramme d’activités.

8.

Diagramme de séquence.

9.

Diagramme de collaboration.

03 axes:
03 axes:

Diagramme par axe de modélisation

2 ième année Licence SRC Diagrammes à étudier

1. Le diagramme de cas d’utilisations (***).

2. Le diagramme de classes (***)

3. Le diagramme de séquence.

4. Le diagramme de collaboration.

Le diagramme de cas d’utilisation

Définition Les cas d’utilisation sont une technique utilisée pour représenter un ensemble de séquences d’actions que devrait réaliser le système privilégiant le point de vue de l’utilisateur.

Exemple

Pour le cas d’utilisation d’un guichet automatique de banque, on ne dira pas « Distribuer de l’argent » favorisant ainsi le coté système,

On dirait plutôt « Retirer de l’argent » pour favoriser le coté utilisateur.

Un DCU montre QUI fait QUOI ?

Notation DCU

Nom_du_Cas_Utilis ation
Nom_du_Cas_Utilis
ation
Notation DCU Nom_du_Cas_Utilis ation Nom_Acteur Association reliant les acteurs aux cas d’utilisation.

Nom_Acteur

Association reliant les acteurs aux cas d’utilisation.

Exemple de CU avec Notation UML

Exemple de CU avec Notation UML

Inclusion / extension

Inclusion / extension
Inclusion / extension

Généralisation / Spécialisation

Généralisation / Spécialisation

Hiérarchisation des acteurs

Hiérarchisation des acteurs Ce que Fait A = Action ( B ) + Action ( C

Ce que Fait A = Action (B) + Action (C) + Action (D)

Exemple Pratique

Exemple Pratique

Conclusion

Les DCU récapitule les besoins du SI; Définissent les Fonctionnalités du système.

Le diagramme de Classes

Définition:

Une classe est une abstraction d’un éléments du monde réel, elle encapsule des propriétés qu’on appelle attributs et des comportements qu’on appelle des méthodes.

Note:

Une classe représente un modèle commun à un ensemble d’objets qu’on appelle instances, ainsi un chien, cheval et chat sont des instances de la classe animal.

Exemple <Classe…instances>

Animal

Classe

Exemple <Classe…instances> Animal Classe Chien Cheval Éléphant instances

Chien

Cheval

Éléphant

instances

Notation

Nom_Classe
Nom_Classe

+ Attribut 1

- Attribut 2

/ Attribut 3

+ Méthode 1 # Méthode 2

(+ ) Public (- ) Protégé (#) Privé

Association

Nom de l’association

Classe_1

Classe_2

 

0

*

1

Classe d’association

Classe_1 Nom de l’association Classe_2 0 * 1
Classe_1
Nom de
l’association
Classe_2
0 *
1

Classe_Association

Agrégation

Classe_1 Classe_2 1 * 0 *
Classe_1
Classe_2
1
*
0 *

L’agrégation est un type particulier d’association

Une occurrence de la classe 1 contient une ou

plusieurs occurrences de la classe 2

Composition

Classe_1 Classe_2 1 * 1
Classe_1
Classe_2
1
*
1

Type particulier d’agrégation;

Un Lien sémantique plus Fort

Généralisation

Généralisation

Exemple Complet

Exemple Complet

Principes Conceptuels

1. Notez la généralisation des trois (03) classes (Ingénieur, Développeur et Chef de projet) en une seule classe abstraite « Employé » regroupant les attributs communs aux trois classes filles (Nom, Prénom et adresse).

A l’aide de cette généralisation, le fait de parler d’employé sous entend soit l’Ingénieur, Développeur ou Chef de projet.

2. Un employé peut ne pas posséder de voitures, comme il peut en posséder plusieurs (D’où la cardinalité 0 *).

La voiture, quant à elle n’est possédée que par un seul employé (D’où la cardinalité 1).

3. La relation de composition entre la classe « Employé » et « Compte » souligne le fait qu’un compte n’appartient qu’à un seul employé, et dépend fortement de celui-ci (La destruction d’une instance d’un employé entraînerait systématiquement celle de son compte).

4. L’agrégation se situant entre les deux classes « Employé » et « Equipe » montre un sens d’appartenance. En effet, une équipe comprend un nombre certain d’employés. Il faut souligner ici, que la destruction d’une équipe n’engendre pas forcément la destruction de ses membres, puisqu’ils seront affectés à d’autres équipes et resteront employés de la boite informatique.

5. Une ou plusieurs équipes sont créées afin qu’elles soient affectées à un projet donné. Une classe d’association « Affectée » est créée pour contenir les dates début et fin de chaque projet réalisé par chaque équipe, sauvegardant ainsi l’historique des affectations.

Conclusion

1. L’établissement des diagrammes de cas d’utilisation représente l’étape indispensable pour l’analyse des besoins fonctionnels de tout système projeté. Une bonne modélisation de l’aspect fonctionnel avec les DCU signera la bonne continuité de l’étude du nouveau système, les autres diagrammes se reposant sur la logique de ce diagramme.

2. Le diagramme de classe nous permet de mettre en place les premières fondations du nouveau système. Il donne une description détaillée de la structure statique de celui-ci. Une bonne construction de ce diagramme représenterait des données cohérentes et stockables dans une base de données structurée et pérenne.