CONCEPTION DE LOGICIELS

Chapitre I : LES GRANDES PHASES DU CYCLE DE VIE D’UN LOGICIEL (SDLC ou

Software Development Life Cycle)
1.1. Définition
1.2. Les phases du cycle de développement logiciel
1.3. Les différents modèles de cycle de vie de développement logiciel (SDLC)
1.3.1. Modèle de cascade
1.3.2. Modèle itératif
1.3.3. Modèle en spirale
1.3.4. Modèle –V
1.3.5. Modèle Big Bang
1.3.6. Modèle incrémentiel

Chapitre II : GENERALITES SUR LE GENIE LOGICIEL

2.1. La naissance de la méthode du génie logiciel
2.2. Qualités d’un logiciel
2.2.1. Évaluation de la Qualité Logicielle
2.3. Méthodes et outils du génie logiciel
2.3.1. Méthodes de modélisation/Langage de modélisation
2.3.2. Méthodes de développement (gestion de projet)
2.3.3. Approche objet
2.3.4. Les écueils classiques
2.4. Introduction sur la conception
2.4.1. Définition
2.4.2. Les intervenants du projet

Chapitre III : CONCEPTION OBJET

3.1. Notation Unifiée (UML)
3.1.1. Présentation UML
3.1.2. Diagramme UML : détails
[Link]. Diagramme de cas d ‘utilisation
[Link]. Diagramme de classe
[Link]. Diagramme de séquence système
[Link]. Diagramme d’activité
[Link]. Diagramme de paquetage
[Link]. Diagramme de déploiement
3.1.3. Mise en œuvre UML
[Link]. Identification des besoins et spécification des fonctionnalités
[Link]. Phases d’analyse
[Link]. Phase de conception
3.2. Processus Unifiée (UP)
3.3. Présentation 2TUP
3.4. Mise en œuvre de 2TUP
3.4.1. Mise en œuvre : plan
3.4.2. Mise en œuvre : détail
[Link]. Etude préliminaire
[Link]. Capture des besoins fonctionnels
Chapitre IV : AUTRES PARADIGMES A TRAVERS LES ARCHITECTURES
5.1. Architecture à base de composants
5.2. Architecture à base de services et micro-services
5.3. Architecture à base de modèle
 I. LES GRANDES PHASES DU CYCLE DE VIE D’UN LOGICIEL (SDLC ou
Software Development Life Cycle)
I.1. Définition
Le cycle de vie du développement logiciel fait référence à la conception, le
développement et le test des logiciels de qualité optimale.

I.2. Les phases du cycle de développement logiciel

- Analyse des besoins : identifier, rassembler et définir les problèmes, les
exigences, les demandes et les attentes des clients liés au produit logiciel.
- Planification : l’équipe détermine le budget et les ressources nécessaires
pour la réalisation des exigences analysées ainsi que de vérifier les risques
encourus.
- Conception de logiciels : la transformation des spécifications du logiciel
en un plan de conception ou spécification de conception.
- Développement de logiciels : l’équipe de développement construit les
solutions logicielles en fonction des décisions de conception prises.
- Test : des tests sont effectués pour garantir que les solutions mises en
œuvre répondent aux normes de qualité et de performance (tests unitaires,
tests d’intégration et de bout en bout, etc.)
- Déploiement : déployer le logiciel dans l’environnement de production
afin que les utilisateurs puissent l’utiliser.
- Maintenance : s’assurer que les besoins continuent d’être satisfaits et que
le système continue de fonctionner conformément aux spécifications
mentionnées dans la première phase.

I.3. Les différents modèles de cycle de vie de développement logiciel (SDLC)

I.3.1. Modèle de cascade
C’est le modèle le plus ancien et le plus simple de tous qui se divise en
plusieurs phases. Chaque phase a son propre plan et commence après la
précédente. Le résultat de la première phase représentera le point d’entrée de la
phase d’après.

I.3.2. Modèle itératif

C’est un modèle à répétition, les concepteurs développent une version
rapide et pas chère pour, ensuite, l’améliorer au fur et à mesure des tests, par
d’autres versions, elles aussi rapides et successives.
 I.3.3. Modèle en spirale
C’est le modèle le plus flexible, similaire au modèle itératif en mettant
l’accent sur la répétition. Au départ, les développeurs planifient les différentes
étapes, conçoivent le logiciel et le construisent, avant de le tester, au final. À
chaque passage, de nouvelles améliorations sont apportées.

I.3.4. Modèle –V
Les phases de vérification du logiciel et de sa validation se font
parallèlement, en simultané.

I.3.5. Modèle Big Bang

Il s’agit d’un modèle à haut risque qui concentre toutes ses ressources au
développement. Cependant, l’étape de définition approfondie des exigences ne s’y
trouve pas, contrairement aux autres méthodes.

I.3.6. Modèle incrémentiel

Il s’agit de plusieurs cycles, révisés en cascade, avec des exigences
partagées en groupes dès le début du projet, tout en suivant le développement
planifié du logiciel. Le processus de cycle de vie SDLC se répète, et à chaque
répétition s’ajoutent de nouvelles fonctionnalités jusqu’à ce que toutes les
exigences soient remplies.

II. GENERALITES SUR LE GENIE LOGICIEL

II.1. La naissance de la méthode du génie logiciel
En 1970, l’algorithmique ne se suffisait plus à lui seul alors le génie logiciel place la
méthodologie au cœur du développement logiciel. D’où la naissance de la méthode
Merise en 1978.
De plus, la taille des applications ne cessant de croître, la programmation structurée
a rencontré ses limites, faisant alors place à la programmation orientée objet (C++, Java,
etc.). Cette nouvelle technique de programmation a nécessité la conception de nouvelles
méthodes de modélisation afin de maximiser les chances de réussite d’un projet logiciel.
  2001: UML 1
 2004: UML 2.0
 2006 : UML 2.1.1
 2016 : UML 2.5

II.2. Qualités d’un logiciel

Un logiciel de qualité est un logiciel capable de répondre parfaitement aux
attentes du client, sans défaut d’exécution. Afin de concevoir un logiciel répondant à ces
attentes, il faut élaborer des règles et des principes à suivre au cours du développement
d’une application.
II.2.1. Évaluation de la Qualité Logicielle
L’étape préalable à l’assurance de la qualité d’un logiciel est de respecter les
règles de l’art du développement : un code uniforme respectant des standards de
codage, une gestion décentralisée du code source.
- Capacité fonctionnelle : vérifier si les fonctionnalités sont implémentées et
respectées avec des critères de type : aptitude, exactitude, interopérabilité,
sécurité…
- Fiabilité : vérifier l’aptitude du logiciel à maintenir son niveau de service i.e sa
capacité à rétablir son niveau de service et de restaurer les données directement
affectées en cas de défaillance. Le logiciel doit résister aux erreurs de l’utilisateur.
- Facilité d’utilisation : prendre en compte les feedbacks des utilisateurs pour
améliorer en continu l’expérience utilisateur.
- Performance : vérifier le temps de démarrage et s’assurer que le temps
d’exécution est satisfaisant pour les tests de performance (consommation CPU,
utilisation mémoire, nombre de requêtes par seconde, flux d’entrée/sortie, etc.).
- Maintenabilité : vérifier la faculté d’analyse (facilité à diagnostiquer les
déficiences, leurs causes) ; la faculté de modification (facilité à modifier,
remédier aux défauts).
- Stabilité : facilité à anticiper les risques éventuels lors de modifications.

II.3. Méthodes et outils du génie logiciel

II.3.1. Méthodes de modélisation/Langage de modélisation
Une méthode d'analyse et de conception permet de formaliser les étapes
préliminaires du développement d'un système afin de rendre ce développement aux
besoins du client. Exemple : Merise, RAD, SADT.
Le langage de modélisation est tout langage informatique graphique ou textuel
qui fournit la conception et la construction de structures et de modèles suivant un
ensemble systématique de règles et de cadres. Exemple : UML (UP/2TUP), BON,
Merise. Outils : Visual Paradigm, StarUML, Microsoft Vision, etc.
N.B : méthode : enchainement de tâches, langage : outil pour effectuer ces tâches.

II.3.2. Méthodes de développement (gestion de projet)

 La méthode de développement permet d’aider les équipes de développeurs à
créer des logiciels d’une qualité élevée dans un délai bref et un coût réduit.
 Méthode agile : ce sont des cycles de développement courts, très ciblés,
impliquant le client et favorisant la collaboration entre des équipes pluridisciplinaires.
L'objectif de la méthode agile est de développer des produits plus rapidement, à
moindre coût, et avec un taux de réussite et de satisfaction plus important. Exemple :
Extreme programming (XP), Dynamic systems development method (DSDM),
Adaptive software development (ASD), Scrum, Feature driven development, Crystal
clear.
 Merise : est une méthode d'analyse et de conception des systèmes d'information
basée sur le principe de la séparation des données et des traitements.
II.3.3. Approche objet
La programmation par objet consiste à utiliser des techniques de programmation
pour mettre en œuvre une conception basée sur les objets. Exemple : Orienté objet,
interface de classe.
II.3.4. Les écueils classiques
Ce sont des techniques qui permettent d'augmenter la productivité des
programmeurs et de diminuer la quantité de bugs dans les programmes produits, et
d’éviter, le dépassement des délais, lors de la réalisation des projets informatiques.
Exemple : la balle en argent, prototypage, le plaqué or la loi de Brooks.

II.4. Introduction sur la conception

II.4.1. Définition
La conception logicielle met en œuvre un ensemble d'activités qui permet la
conception, l'écriture et la mise au point d'un logiciel jusqu'à sa livraison au
demandeur.
En règle générale, la conception de logiciel suit 3 grandes phases :
 Phase d'analyse (fonctionnelle) ou de conception : étude des
données, étude des traitements à effectuer et élaboration des techniques de
modélisation.
 Phase de réalisation ou de programmation (écriture et tests des
programmes) : algorithme, codage, programmation, gestion de versions,
refactoring (processus qui améliore le code sans écrire de nouvelles
fonctionnalités), tests unitaires (procédure permettant de vérifier le bon
fonctionnement d'une partie précise d'un logiciel), optimisation du code.
 Phase de livraison : intégration, validation, documentation du logiciel,
packaging (emballage).

II.4.2. Les intervenants du projet

Maître d’ouvrage (MOA) : le client Il faut que ça serve

 Définit les besoins
 Déclenche le financement
 Fait l’interface entre les
utilisateurs et le MOE
 Valide les livrables
 Fait le suivi d’exploitation
Maître d’œuvre (MOE) : le chef de Il faut que ça avance
projet
  Coordonne la réalisation
 Définit un référentiel qualité
 Suit les actions et gère les
risques
 Qualifie les livrables
Equipe projet Il faut que ça marche
 Réalise les travaux

III. CONCEPTION OBJET

3.1. Notation Unifiée (UML)
3.1.1. Présentation UML (Unified Modeling Langage)
UML est un langage de modélisation graphique et textuel. C’est à dire des
graphiques associés à des textes qui expliquent leur contenu. UML n’est pas une
méthode mais un langage graphique qui permet de représenter et de communiquer
les divers aspects d’un système d’information.
UML est un métalangage qui fournit des éléments permettant de construire le
modèle qui, lui, sera le langage du projet.
Ils existent plusieurs types de diagrammes d’UML.

Du côté fonctionnel :
- on fait le diagramme de cas d’utilisation qui énonce toutes les fonctionnalités
que doit faire le système.
- puis les diagrammes de séquence et les diagrammes de collaboration pour
saisir les scénarios d’utilisation du système.
- Elaboration du diagramme de classes qui représente les classes intervenant
dans le système et les diagrammes d’états, un diagramme déterministe qui
 décrit sous forme de machine à états finis le comportement du système ou de ses
composants.
Du côté technique :
- On ajoute les fonctionnalités techniques au diagramme de cas d’utilisation.
- on fait une ébauche du diagramme de déploiement (représente la structure du
réseau informatique dans lequel va s’insérer l’application à développer et la
manière dont les composants du système sont répartis sur ces éléments
matériels et interagissent entre eux).
- Puis, à la jonction des deux branches, lors de la conception préliminaire, on
complète le diagramme de déploiement et on fait le diagramme de
composants (représente la structure physique des composants du système. Les
composants du système sont les fichiers, les bibliothèques, les bases de données).
- Enfin, lors de la conception détaillée, on affine la majorité des diagrammes
effectués précédemment afin de permettre aux développeurs de coder les
fonctionnalités de manière très précise et adaptée aux besoins des utilisateurs.
(Le diagramme d’activités permet de décrire sous forme de flux ou
d'enchaînement d'activités le comportement du système ou de ses composants.)

3.1.2. Diagramme UML : détails

[Link]. Diagramme de cas d ‘utilisation
Il permet de recueillir, d’analyser, d’organiser les besoins et de recenser les
grandes fonctionnalités d’un système. Il capture le comportement d’un système tel qu’un
utilisateur extérieur le voit.
a. Eléments
 Acteur : c’est le rôle que je joue une p
 ersonne externe, processus ou chose qui interagit avec un système.
 Cas d’utilisation : des fonctionnalités fournies par un système en interagissant
avec les acteurs. Il se représente par une ellipse contenant le nom du cas (verbe à
l’infinitif) et optionnellement, au-dessus du nom, un stéréotype.

 Dans le cas où l’on désire présenter les attributs ou les opérations du cas
d’utilisation, il est préférable de le représenter sous la forme d’un classeur
stéréotypé <<use case>>.

 Ex :
 b. Relations entre acteurs et cas d’utilisation (CU)

Une relation d’association est un chemin de communication entre un acteur

et un cas d’utilisation et est représenté un trait continu. Le symbole * signifie plusieurs,
lorsqu’un acteur interagit plusieurs fois avec un cas d’utilisation.
Un acteur est qualifié de principal <<primary>> pour le CU lorsque ce cas lui
rend service. Les autres acteurs sont alors qualifiés de secondaires <<secondary>>.
c. Relations entre cas d’utilisation

Il existe 2 types de relations :

 - Dépendances stéréotypées sont explicitées par un stéréotype (inclusion,
extension). Une dépendance se représente par une flèche avec un trait
pointillé. Si le cas A inclut ou étend le cas B, la flèche est dirigée de A vers B :
 Un cas A inclut un cas B alors cas A dépend de B
<<include>> .
 Un cas A étend un cas B lorsque le cas B peut être appelé au
cours de l’exécution du cas A (c’est optionnel) <<extend>>.
- Généralisation/spécialisation. Le symbole utilisé pour la généralisation est
une flèche avec un trait plein dont la pointe est un triangle fermé désignant le
cas le plus général.

d. Relations entre acteurs

Une relation entre 2 acteurs est la généralisation : un acteur B est une
généralisation d’un acteur A si l’acteur B peut être substitué par l’acteur A. Dans ce cas,
tous les cas d’utilisation accessibles à B le sont aussi à A. Le symbole utilisé pour la
généralisation entre acteurs est une flèche avec un trait plein dont la pointe est un
triangle fermé désignant l’acteur le plus général.

[Link]. Diagramme de classe (DC)

Le DC est le seul obligatoire lors d’une modélisation orientée objet. Le DC montre
la structure interne du système. Il permet de fournir une représentation abstraite des
objets du système qui vont interagir ensemble pour réaliser les cas d’utilisation.
Le DC permet de modéliser les classes du système et leurs relations
indépendamment d’un langage de programmation particulier.
a. Définition classes
Une classe est la description formelle d’un ensemble d’objets ayant une
sémantique et des caractéristiques communes. Un objet est une instance d’une classe.
b. Caractéristiques d’une classe
Les caractéristiques d’un objet permettent de spécifier son état et
son comportement. État d’un objet, ce sont les attributs et généralement
les terminaisons d’associations, tous deux réunis sous le terme de propriétés
structurelles, ou propriétés. Les associations sont utilisées pour connecter les classes
du DC ; dans ce cas, la terminaison de l’association (du côté de la classe cible) est
généralement une propriété de la classe de base.
 Une classe est un classeur, représentée par un rectangle divisé en 3 à 5
compartiments. Le 1ier indique le nom de la classe, le 2ième ses attributs (informations
qu’une classe ou un objet doivent connaître) et le 3ième ses opérations.

c. Encapsulation, visibilité

- Encapsulation est un mécanisme rassemblant les données et les méthodes au

sein d’une structure. L’encapsulation garantit l’intégrité des données contenues
dans l’objet.
- Encapsulation permet de définir des niveaux de visibilité des éléments d’un
conteneur. Il existe 4 visibilités.
 Public (+) : tout élément qui voit le conteneur peut également voir
l’élément indiqué.
 Protected (#) : seul un élément dans le conteneur ou un de ses
descendants peut voir l’élément indiqué.
 Private (-) : seul un élément situé dans le conteneur peut voir l’élément.
 Package (∼) ou rien : seul un élément déclaré dans le même paquetage
voit l’élément.
- Une méthode de classe ne peut manipuler que des attributs de classe et ses
propres paramètres.
- Exemple de diagramme de classe
Etudiant
Nom : string
Prénom : string
presenceEtudiant()
noteEtudiant : float

d. Relation entre classes

Une association est une relation entre 2 classes (binaire) ou plus (n-aire), elle
décrit les connexions structurelles entre leurs instances.
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 ◂). Quand les 2 extrémités de l’association pointent vers la même classe, l’association
est dite réflexive.
Association n-aire

La ligne pointillée d’une classe-association peut être reliée au losange par une
ligne discontinue pour représenter une association n-aire dotée d’attributs, d’opérations
ou d’associations.
On représente une association n-aire par un grand losange avec un chemin
partant vers chaque classe participante. Le nom de l’association apparaît à proximité du
losange.

Dans la 1ière version, l’association apparaît clairement et constitue une entité

distincte.
Dans la 2ième, l’association se manifeste par la présence de 2 attributs dans
chacune des classes en relation.

e. Multiplicité et cardinalité
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.
Exemples de multiplicité :
 exactement un : 1 ou 1..1
 plusieurs : * ou 0..*
 au moins un : 1..*
 de un à six : 1..6
 f. Classe-association
Parfois, une association possède des propriétés. Par exemple, l’association
Emploie entre une société et une personne possède comme propriétés le salaire et la
date d’embauche. Un nouveau concept classe-association modélise cette situation.
Une classe-association possède les caractéristiques des associations et des
classes : elle se connecte à 2 ou plusieurs classes et possède également des attributs et
des opérations.
Une classe-association est caractérisée par un trait discontinu entre la classe et
l’association qu’elle représente.

g. Classe-association pour plusieurs associations

Il n’est pas possible de rattacher une classe-association à plus d’une association
puisque la classe-association constitue elle-même l’association. Dans le cas où plusieurs
classe-associations doivent disposer des mêmes caractéristiques, elles doivent hériter
d’une même classe possédant ces caractéristiques, ou l’utiliser en tant qu’attribut.

h. Auto-association sur classe-association

Si on veut ajouter une association Supérieur de pour préciser qu’une personne

est le supérieur d’une autre personne. Une personne est, en tant qu’employé d’une
entreprise donné, le supérieur d’une autre personne dans le cadre de son emploi pour
une entreprise donnée. Il s’agit d’une association réflexive, non pas sur la
classe Personne mais sur la classe-association Emploie.

[Link]. Diagramme de séquence système (DSS)

 Les principales informations du DSS sont les messages échangés entre les lignes
de vie, présentés dans un ordre chronologique, dans un scénario d’un DCU. Le temps y
est représenté par une dimension verticale et s’écoule de haut en bas.
- Une ligne de vie se représente par un rectangle, auquel est accroché une ligne
verticale pointillée, contenant une étiquette : [<nom_du_rôle>] :
[<Nom_du_type>]. Au moins un des deux noms doit être spécifié dans l’étiquette,
les 2 points (:) sont obligatoires.
- Un message définit une communication particulière entre des lignes de vie.
Plusieurs types de messages existent, les plus communs sont : envoi d’un signal,
invocation d’une opération, la création ou la destruction d’une instance.
Messages asynchrones

Ici, ils n’attendent pas de réponse et ne bloquent pas l’émetteur qui ne sait
pas si le message arrivera à destination.
Messages synchrones

L’émetteur reste bloqué le temps que dure l’invocation de l’opération. Ce

message peut être suivi d’une réponse qui se représente par une flèche en
pointillé.
Messages de création et destruction d’instance
Représentation d’un message de création et de destruction d’instance.

UML permet de séparer l’envoi du message, sa réception, le début de

l’exécution de la réaction et sa fin.
 La syntaxe des messages et des réponses.

La réception d’un message est suivie de l’exécution d’une méthode d’une

classe.

Exécution de méthode et objet actif

Un objet actif initie et contrôle le flux d’activités. Graphiquement, la ligne
pointillée verticale d’un objet actif est remplacée par un double trait vertical.
Un objet passif, a besoin qu’on lui donne le flux d’activités pour pouvoir
exécuter une méthode. La spécification de l’exécution d’une réaction sur un objet passif
se représente par un rectangle blanc ou gris placé sur la ligne de vie en pointillée.

Les exécutions simultanées sur une même ligne de vie sont représentées par un
rectangle chevauchant.
 a. Fragment d’interaction combiné
Représente des articulations d’interactions. Il est défini par un opérateur et des
opérandes.
• Opérateur conditionne la signification du fragment combiné. Le fragment
combiné permet de décrire des DS de manière compacte. Il se représente comme
une interaction dans un rectangle dont le coin supérieur gauche contient un
pentagone. Dans le pentagone figure le type de la combinaison appelé opérateur
d’interaction.
• Opérandes sont séparés par 1 ligne pointillée. Conditions de choix des
opérandes sont données par des expressions booléennes entre crochets. Les
opérateurs sont groupés par fonctions :
 les opérateurs de choix et de boucle : alt (alternative), opt
(option), break et loop ;
 les opérateurs contrôlant l’envoi en parallèle de messages : par
(parallel) et critical region ;
 les opérateurs contrôlant l’envoi de
messages : ignore, consider, assertion et negative ;
 les opérateurs fixant l’ordre d’envoi des messages : weak
sequencing , strict sequencing.

- Alt : opérateur conditionnel possédant plusieurs opérandes équivaut à switch.

Chaque opérande détient une condition de garde. L’absence de condition de
garde implique une condition vraie. Else est vraie si aucune autre condition n’est
vraie.
Soit un exemple d’un opérateur alt :
- un utilisateur rentre un code correct et dans ce cas le diagramme de séquence
relatif à la vérification du code est appelé,
- si l'utilisateur rentre un code erroné, trois fois, et sa carte est gardée (le
distributeur se ré-initialise et demande à nouveau une carte).
 - Loop : a un sous-fragment, spécifie un compte min et max (boucle) et une
condition de garde. Syntaxe de boucle est loop[ '('<minInt> [ ',' <maxInt> ] ')' ]
Condition de garde est placée entre crochets sur la ligne de vie. La boucle est
répétée au moins minInt fois avant qu’une éventuelle condition de garde
booléenne ne soit testée. Tant que la condition est vraie la boucle continue au
plus maxInt fois.
- Opt : comporte une opérande et une condition de garde associée. Le sous-
fragment s’exécute si la condition de garde est vraie et ne s’exécute pas sinon.
- Ref : référence à une interaction dans un autre diagramme.
Soit un exemple d’un opérateur opt :
- l'utilisateur, s’il est mécontent, peut se défouler sur le distributeur de billets. En
revanche, la plupart des utilisateurs contiennent leur agressivité et restent
corrects envers le distributeur de billet. L'opérateur opt montre cette possibilité.
 - Break : représente des scenario d'exception.
Lorsque le distributeur demande le code à l'utilisateur, il peut choisir de saisir son code
ou de consulter l'aide. Si il choisit de consulter l'aide, le flot d'interaction relatif à la
saisie du code est interrompu. Les interactions de l'opérateur break sont "exécutées".

- Par : un fragment combiné de type parallèle possède au moins 2 sous-fragments

exécutés simultanément. La concurrence est logique : les exécutions
concurrentes peuvent s’entrelacer sur un même chemin d’exécution dans la
pratique.
- Soit un exemple d’un Microwave, un objet effectuant deux tâches en parallèle
 - strict : un fragment de type strict sequencing possède au moins 2 sous-
fragments, et s’exécutent selon leur ordre d’apparition au sein du fragment
combiné. Ce fragment est utile surtout lorsque 2 parties d’un diagramme n’ont
pas de ligne de vie en commun.
- Soit un exemple de procédure de décollage d’un avion dans l’ordre

[Link]. Diagramme d’activité (DA)

Les DA permettent de :
 mettre l’accent sur les traitements,
 représenter graphiquement le déroulement d’un cas d’utilisation.
Ils doivent être complétés par des diagrammes de séquence (DS). Ils viennent illustrer
et consolider la description textuelle des cas d’utilisation. On se concentre sur les
activités telles que les acteurs du système les voient dans le cadre d’un processus
métier.
a. Activité
Une activité définit un comportement décrit par une séquence organisée d’actions.
Le flot d’exécution est modélisé par des nœuds reliés par des arcs (transitions). Une
action est le plus petit traitement qui puisse être exprimé en UML.
Groupe d’activités : est une activité regroupant des nœuds et des arcs. Un
diagramme d’activités est lui-même un groupe d’activités.
Nœud d’activité : est un type d’élément abstrait permettant de représenter les
étapes du flot d’une activité.

Il existe 3 familles de nœuds d’activités :

 Nœud d’exécutions : un nœud exécutable est un nœud d’activité qu’on peut
exécuter.
 Nœud d’action : c’est un nœud d’activité exécutable constituant l’unité
de fonctionnalité exécutable dans une activité. L’exécution d’une action
représente une transformation ou calcul dans le système modélisé. Un
nœud d’action doit avoir au moins un arc entrant.

 Nœud d’activité structurée : représente une portion structurée d’une

activité donnée.
 Nœud objets : Définissent un flot d’objets dans un DA. Ce nœud représente
l’existence d’un objet généré par une action dans une activité et utilisé par
d’autres actions.

 Pin d’entrée ou de sortie

Pour spécifier les valeurs passées en argument à une activité et les valeurs de
retour, on utilise des nœuds d’objets appelés pins d’entrée ou de sortie.
L’activité ne peut débuter que si l’on affecte une valeur à chacun de ses pins
d’entrée. Quand l’activité se termine, une valeur doit être affectée à chacun de ses
pins de sortie.
 Flot d’objet : permet de passer des données d’une activité à une autre. Un
arc reliant un pin de sortie à un pin d’entrée est un flot d’objets. Le type
du pin récepteur doit être identique au type du pin émetteur.

 Nœud tampon central : est un nœud d’objet qui accepte les entrées ou
sorties de plusieurs nœuds d’objets.
 Nœud de contrôle : un nœud d’activité abstrait utilisé pour coordonner les
flots entre les nœuds d’une activité.
 Nœud initial : est un nœud de contrôle à partir duquel le flot débute. Une
activité peut avoir plusieurs nœuds initiaux. Un nœud initial possède un
arc sortant.

 Nœud final : est un nœud de contrôle possédant un ou plusieurs arcs

entrants :
o Nœud de fin d’activité : lorsque l’un des arcs d’un nœud de fin
d’activité est activé, l’exécution de l’activité enveloppante s’achève
et tout nœud ou flot actif au sein de l’activité enveloppante est
abandonné.
o Nœud de fin de flot : lorsqu’un flot d’exécution atteint un nœud de
fin de flot, le flot en question est terminé.

b. Transitions

Le passage d’une activité vers une autre est matérialisé par une transition. Les
transitions sont représentées par des flèches en traits pleins qui connectent les
activités entre elles. Elles sont déclenchées dès que l’activité source est terminée et
provoquent automatiquement et immédiatement le début de la prochaine activité à
déclencher (l’activité cible).

c. Partitions
Appelées couloirs ou lignes d’eau (swimlane) permettent d’organiser les nœuds
d’activités d’un diagramme d’activités en opérant des regroupements.
Graphiquement, les partitions sont délimitées par des lignes continues. Il s’agit
généralement de lignes verticales, mais elle peuvent être horizontales ou même
courbes. Dans le cas d’un DA partitionné, les nœuds d’activités appartiennent
forcément à une et une seule partition. Les transitions peuvent, bien entendu,
traverser les frontières des partitions.
Les partitions d’activités étant des catégories arbitraires, on peut les représenter
par d’autre moyens quand une répartition géométrique s’avère difficile à réaliser. On
peut ainsi utiliser des couleurs ou tout simplement étiqueter les nœuds d’activité
par le nom de leur partition d’appartenance.
Illustration de l’utilisation de nœuds d’objets et de partitions dans un DA

[Link]. Diagramme de paquetage

Un diagramme qui contient d’autres éléments de modélisation (classes, autres
paquetages, ...) et définit un espace de nom (namespace).
Espace de nom et visibilité
- 2 éléments dans 2 paquetages différents sont différents, quel que soit leur nom

 Nom complet = nom préfixé par les noms des paquetages englobants :
Banque::Compte différent de Commerce::Compte
- Visibilité d’un élément E dans un package P :
 Public (+) : Elément visible par tous (utilisation du nom complet)
 Privé (-) : Elément visible uniquement par
 Les autres éléments de P
 Les éléments englobés par E (si E est un package)

Dépendances entre paquetages

Reflètent les dépendances entre éléments des paquetages :
- Une classe A dépend d’une classe B (noté A - - - - - - - - > B) si :
 Il existe une association navigable de A vers B (ou A possède un attribut
de type B)
 Une méthode de A a un paramètre ou une variable locale de type B
Stéréotypes sur les dépendances inter-paquetage
- A - - - «access» - - - > B : tout élément public de B est accessible par son nom
complet depuis A.
 - A - - - «import» - - - > B : tout élément public de B est accessible par son nom
depuis A ; Création d’alias si nécessaire.

Le paquetage B importe Classe1 et Classe2 (pas Classe3 qui a une visibilité de

type privée). Classe1 et Classe2 ont une visibilité de type public dans paquetage B. Le
paquetage C importe Classe1, Classe2 et Classe4.
- dépendance de types « merge » : elle correspond à la fusion de 2 paquetages en
un seul.

Le paquetage A est fusionné dans le paquetage B (le paquetage A n’est pas modifié alors
que le paquetage B est écrasé pour accueillir la fusion des 2 paquetages).

Architecture logique
Regroupement des classes logicielles en paquetages ; Point de départ pour un
découpage en sous-systèmes.
Exemples d’architectures logiques
- Architecture en couches
- Architecture Modèle - Vue - Contrôleur (MVC)
 - Architecture Multi-tiers
- ...

[Link]. Diagramme de déploiement

C’est de modéliser le déploiement du système sur une architecture physique, disposition
des artefacts (instances de composants, processus, ...) sur les nœuds physiques
(Ordinateur, Téléphone, Imprimante, ...).

Un diagramme de déploiement est un type de diagramme UML qui montre

l’architecture d’exécution d’un système, y compris les nœuds tels que les
environnements d’exécution matériels ou logiciels, et l’intergiciel qui les relie.
Notations des diagrammes de déploiement
 Nœuds : représenté sous forme de cube, est une entité physique qui exécute un
ou plusieurs composants, sous-systèmes ou exécutables. Un nœud peut être un
élément matériel ou logiciel.
  Artifacts : des éléments concrets qui sont causés par un processus de
développement (Ex : les bibliothèques, les archives, les fichiers de configuration,
les fichiers exécutables, etc.).

 Association de communication : représentée par une ligne continue entre deux

nœuds. Il indique le chemin de la communication entre les nœuds.

 Dispositifs : un nœud qui sert à représenter une ressource physique de calcul

dans un système. Un exemple de dispositif est un serveur d’application.

 Spécifications de déploiement : un fichier de configuration, tel qu’un fichier

texte ou un document XML. Il décrit comment un artefact est déployé sur un
nœud.

Exemple d’un étape pour dessiner un diagramme de déploiement

- Étape 1 : identifiez l’objectif du diagramme de déploiement c’est à dire identifier
les nœuds et les dispositifs du système qu’on va visualiser à l’aide du diagramme.
- Étape 2 : déterminez les relations entre les nœuds et les appareils en ajoutant les
associations de communication au diagramme.
- Étape 3 : identifiez les autres éléments, tels que les composants et les objets
actifs pour compléter le diagramme.
- Étape 4 : ajoutez des dépendances entre les composants et les objets selon les
besoins.
Ex : Diagramme de déploiement du système d’achat en ligne

3.1.3. Mise en œuvre UML

UML ne propose pas une démarche de modélisation explicitant et encadrant
toutes les étapes d’un projet, de la compréhension des besoins à la production du code
de l’application. Et le problème de la mise en œuvre d’UML c’est comment passer de
l’expression des besoins au code de l’application ?
Une méthode basée sur l’utilisation UML doit être :
- Pilotée par les cas d’utilisation : toutes les étapes, de la spécification des
besoins à la maintenance, doivent être guidées par les cas d’utilisation qui
modélisent justement les besoins des utilisateurs.
- Centrée sur l’architecture : l’architecture est conçue pour satisfaire les besoins
exprimés dans les cas d’utilisation, mais aussi pour prendre en compte les
évolutions futures et les contraintes de réalisation.
- Itérative et incrémentale : l’ensemble du problème est décomposé en petites
itérations, définies à partir des cas d’utilisation et de l’étude des risques. Les
risques majeurs et les cas d’utilisation les plus importants sont traités en priorité.
Le développement procède par des itérations qui conduisent à des livraisons
incrémentales du système.

[Link]. Identification des besoins et spécification des fonctionnalités

a. Identification et représentation des besoins : diagramme de cas
d’utilisation
On le crée pour identifier et modéliser les besoins des utilisateurs. Déterminer les
limites du système, identifier les acteurs et recenser les cas d’utilisation.
- identifier les acteurs
Acteur Rôles
Administrateur - s’authentifie
- gère les utilisateurs de l’application
- gère les contrats
client - s’authentifie
- consulte les sites
 - liste les contrats

- identifier les cas d’utilisation

Cas d’utilisation acteurs
S’authentifier Administrateur, client
Gérer les utilisateurs Administrateur
Consulter les sites client
Gérer les contrats Administrateur

b. Spécification détaillée des besoins : diagrammes de séquence

système
Scénarii de la description textuelle des cas d’utilisation sont des instances de
cas d’utilisation et illustrés par des diagrammes de séquence système. Il faut au moins
représenter le scénario nominal de chaque cas d’utilisation par un diagramme de
séquence. Pour l’exemple dans la section a, il faut un diagramme de séquence système
pour les cas d’utilisation : s’authentifier, gérer les utilisateurs, consulter les sites et Gérer
les contrats.

Exemple de diagramme de séquence du cas d’utilisation « s’authentifier »

c. Maquette de l’IHM de l’application

Une maquette d’IHM est un produit permettant aux utilisateurs d’avoir une vue
concrète de la future interface de l’application. La maquette pourra intégrer des
fonctionnalités de navigation permettant à l’utilisateur de tester l’enchaînement des
écrans ou des menus.
[Link]. Phases d’analyse
a. Analyse du domaine : modèle du domaine
C’est une étape dissociée de l’analyse des besoins. Cette phase permet d’élaborer
la 1ière version du diagramme de classes appelée modèle du domaine. Ce modèle doit
définir les classes qui modélisent les entités ou concepts présents dans le domaine
(métier) de l’application.
Les étapes à suivre pour établir ce diagramme sont :
- identifier les entités ou concepts du domaine ;
- identifier et ajouter les associations et les attributs ;
- organiser et simplifier le modèle en éliminant les classes redondantes et en
utilisant l’héritage ; ou structurer les classes en paquetage selon les principes de
cohérence et d’indépendance.

b. Diagramme de classes participantes

Effectue la jonction entre d’une part les cas d’utilisation, le modèle du domaine
et la maquette, et d’autre part, les diagrammes de conception logicielle que sont les
diagrammes d’interaction et le diagramme de classes de conception. Le diagramme de
classes participantes modélise trois types de classes d’analyse, les dialogues,
les contrôles et les entités ainsi que leurs relations :
- Classes de dialogues permettent les interactions entre l’IHM et les utilisateurs. Il
y a 1 dialogue pour chaque association entre un acteur et un cas d’utilisation du
diagramme de UC.
- Classes de contrôles modélisent la cinématique de l’application. Elles font la
jonction entre les dialogues et les classes métier en permettant aux différentes
vues de l’application de manipuler des informations détenues par un ou plusieurs
objets métier.
 - Classes entités sont les classes métier qui proviennent directement du modèle
du domaine. Elles survivent à l’exécution d’un cas d’utilisation particulier et
permettent à des données et des relations d’être stockées dans des fichiers ou des
bases de données.

c. Diagrammes d’activités de navigation

Les IHM modernes facilitent la communication entre l’application et l’utilisateur
en offrant toute une gamme de moyens d’action et de visualisation comme des menus
déroulants ou contextuels, des palettes d’outils, des boîtes de dialogues, des fenêtres de
visualisation, etc.
Les diagrammes d’activités de navigation représentent graphiquement cette
activité de navigation dans l’interface en produisant des diagrammes dynamiques.

[Link]. Phase de conception

a. Diagrammes d’interaction
Maintenant, il faut attribuer les responsabilités de comportement, dégagée par
le diagramme de séquence système, aux classes d’analyse du diagramme de classes
participantes. Les résultats de cette réflexion sont présentés sous la forme de
diagrammes d’interaction UML.
Pour chaque service ou fonction, il faut décider quelle est la classe qui va le
contenir. Les diagrammes d’interactions (de séquence ou de communication) sont
particulièrement utiles au concepteur pour représenter graphiquement ces décisions
d’allocations des responsabilités. Chaque diagramme va représenter un ensemble
d’objets de classes différentes collaborant dans le cadre d’un scénario d’exécution du
système.
Dans les diagrammes d’interaction, les objets communiquent en s’envoyant des
messages qui invoquent des opérations sur les objets récepteurs. Il est ainsi possible de
suivre visuellement les interactions dynamiques entre objets et les traitements réalisés
par chacun d’eux.

Diagrammes d’interaction attribuant les responsabilités de comportement aux classes

d’analyse.

Par rapport aux diagrammes de séquences, remplaçons le système, vu comme une boîte
noire, par un ensemble d’objets en collaboration. Ces objets sont des instances des 3
types de classes d’analyse du diagramme de classes participantes, à savoir des dialogues,
des contrôles et des entités. Il faut que :
- les classes dont ils sont issus soient en association dans le diagramme de classes
participantes ;
- l’interaction respecte la navigabilité de l’association en question.
 Système des diagrammes de séquences vu comme une boîte noire, remplacé par
un ensemble d’objets en collaboration. L’objectif de cette étape est de produire le
diagramme de classes qui servira pour l’implémentation. Il faut maintenant
compléter le diagramme de classe en précisant les opérations privées des différentes
classes. Il faut prendre en comptes les choix techniques : choix du langage de
programmation, des différentes librairies utilisées (notamment pour l’implémentation
de l’interface graphique) etc.

Chaîne complète de la démarche de modélisation du besoin jusqu’au code

3.2. Processus Unifiée (UP)
Le processus unifié (UP : Unified Process) est un processus de développement
logiciel mené par UML. Le processus unifié est :
 itératif et incrémental: le projet est découpé en des itérations de courte
durée. Ces itérations aident à mieux suivre l'avancement du système global.
A chaque itération, il est produit un exécutable de façon incrémentale.
 piloté par les risques : il est identifié et écarté au plut tôt tout risque pouvant
conduire à un échec du projet.
 centré sur l'architecture : le système est décomposé en modules pour des
besoins de maintenabilité et d'évolutivité.
 conduit par les cas d'utilisation : le processus met en avant les besoins et
exigences des futurs utilisateurs du système.
2TUP est un processus unifié qui a pour but d'apporter une réponse aux
contraintes de changement fonctionnelles et techniques qui s'imposent aux systèmes
d'information.

3.3. Présentation 2TUP

2TUP est un processus de développement logiciel qui met en oeuvre la méthode du
processus unifié. Il propose un cycle de développement en Y, qui dissocie les aspects
techniques des aspects fonctionnels. Son objectif est d’obtenir un système logiciel qui
répond bien aux besoins des utilisateurs. Cependant, il y a des contraintes tels que le
respect des délais et le respect des coûts.
Idée de base du 2TUP, toute évolution imposée au SI peut se décomposer et se
traiter parallèlement, suivant 2 axes (« 2 tracks ») :
 un axe fonctionnel
 un axe technique
La réalisation du système consiste à fusionner les résultats des deux branches

Une forme en Y, du coté de la branche fonctionnelle :

- Capture des besoins fonctionnels : elle aboutit à un modèle des besoins focalisé
sur le métier des utilisateurs. Elle minimise le risque de produire un système
 inadéquat avec les besoins des utilisateurs. De cette capture, la MOE consolide les
spécifications et en vérifie la cohérence et l’exhaustivité.
- Analyse : étude des spécifications afin de savoir ce que le système va réellement
réaliser en termes de métier.
Du coté de la branche technique :
- Capture des besoins techniques : recensement des outils, des matériels et des
technologies à utiliser.
- Conception générique : découpage en composants nécessaires à la construction
de l’architecture technique. Cette étape permet de minimiser l’incapacité de
l’architecture technique à répondre aux contraintes opérationnelles.
Enfin, la branche du milieu :
- Conception préliminaire : étape où on intègre le modèle d’analyse dans
l’architecture technique. Le but ici est de savoir dans quel composant technique
on met nos fonctionnalités issues de l’analyse.
- Conception détaillée : conception de chaque fonctionnalité.
- Etape de codage : phase de programmation de ces fonctionnalités, avec des tests
au fur et à mesure.
- Etape de recette : phase de validation des fonctions du système développé.

3.4. Mise en œuvre de 2TUP

3.4.1. Mise en œuvre : plan
a. Capture des besoins

b. Analyse
 c. Conception d’architecture

3.4.2. Mise en œuvre : détail

[Link]. Etude préliminaire

Objectifs
- Établir un recueil initial des besoins fonctionnels et opérationnels
- modéliser le contexte du système en
 identifiant les entités externes au système qui interagissent directement
avec lui (acteurs).
 répertoriant les interactions (émission/réception de messages) entre ces
acteurs et le système.
 a. identifier les acteurs
Un acteur représente l’abstraction d’un rôle joué par des entités externes
(utilisateur, dispositif matériel ou autre système) qui interagissent 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 éventuellement porteurs de données (voir
section [Link].a).

b. identifier les messages

Un message représente la spécification d’une communication unidirectionnelle
entre objets qui transportent de l’information avec l’intention de déclencher une activité
chez le récepteur.
Un message est normalement associé à deux occurrences d’événements :
 un événement d’envoi
 un événement de réception
 décrire les interactions de plus haut niveau entre les acteurs et le système.
Acteurs Messages émis Messages reçus
client Demande de s’authentifier Authentification réussie
Demande la consultation de Liste de l’historique d’un
l’historique d’un contrat ou contrat spécifique
réservation ou bon de commande
Demande d’effectuer un règlement Paiement effectué
administrateur Demande de s’authentifier Authentification réussie
Demande de consultation de Liste des historiques
l’historique complet
Demande d’ajout, de mise à jour ou Ajout ou modification ou
de suppression d’un utilisateur suppression d’un
utilisateur
Demande d’ajout, de mise à jour ou Ajout ou mise à jour ou
d’effectuer un règlement d’un paiement effectué
contrat, bon de commande et
réservation

c. représenter le contexte dynamique grâce à un diagramme de

collaboration
Représenter le contexte dynamique grâce à un diagramme de collaboration
 le système étudié est représenté par un participant central
 ce participant central est entouré par d’autres participants symbolisant les
différents acteurs
 des liens relient le système à chacun des acteurs
 sur chaque lien sont montrés les messages en entrée et en sortie du
système, sans numérotation.
Pour implémenter un cas d’utilisation, il faut utiliser un ensemble de classes et
d’autres éléments, fonctionnant ensemble pour réaliser le comportement de ce cas
d’utilisation. Cet ensemble d’éléments, comportant à la fois une structure statique et
dynamique, est modélisé en UML par une collaboration. Elle permet de décrire la mise
en œuvre d’une fonctionnalité par un jeu de participants.
 Diagramme de collaboration d’une transaction immobilière

Un rôle est la description d’un participant. Une collaboration ne détient pas les
instances liées à ses rôles. La collaboration rassemble les instances et précise des
connecteurs entre elles.
Graphiquement, une collaboration se représente par une ellipse en trait pointillé
comprenant deux compartiments : celui au-dessus contient le nom de la collaboration et
le compartiment inférieur montre les participants à la collaboration.
Une interaction montre le comportement d’une collaboration en se focalisant
sur l’échange d’informations entre les éléments de la collaboration. Une interaction
contient un jeu de ligne de vie. Chaque ligne de vie correspond à une partie interne
d’une collaboration (i.e. un rôle). L’interaction décrit l’activité interne des éléments de
la collaboration, appelés lignes de vie, par les messages qu’ils échangent.

[Link]. Capture des besoins fonctionnels

1er étape de la branche gauche du cycle en Y : formalise et détaille ce qui a été

ébauché au cours de l’étude préliminaire.
 Objectifs
 Décrire exhaustivement les exigences fonctionnelles du système.
 Décrire les différentes façons qu’auront les acteurs d’utiliser le futur
système.

a. identifier les cas d’utilisation

Un cas d’utilisation représente un ensemble de séquences d’actions réalisées par
le système et produisant un résultat observable intéressant pour un acteur particulier.
Un cas d’utilisation modélise un service rendu par le système.
Ex d’un cas d’utilisation d’une application
Cas d ‘utilisation Acteurs Messages émis/reçus
1) s’authentifier - administrateur Demande de s’authentifier
- client Authentification réussie
2) Gérer les - administrateur Demande d’ajout ou modification d’un
clients client
ajout ou modification d’un client
3) gérer les - administrateur ajout ou modification d’un utilisateur
utilisateurs

b. Établir une description succincte de chaque cas d’utilisation candidat

Établir une première description succincte de chaque cas d’utilisation candidat
 Intention de l’acteur lorsqu’il utilise le système
 Séquences d’actions principales qu’il est susceptible d’effectuer

c. Représenter les cas d’utilisation et leurs acteurs sur un diagramme de

cas d’utilisation
Représenter les cas d’utilisation et leurs acteurs sur un diagramme de cas
d’utilisation : détailler les rôles (principal ou secondaire) et le sens des associations.

Exemple d’un diagramme de cas d’utilisation

 d. Décrire les cas d’utilisation
- Recenser toutes les interactions de façon textuelle
- Préciser
 quand ont lieu les interactions entre acteurs et système
 quels sont les messages échangés
 les variantes possibles (scénario)
 les différents cas nominaux
 les cas alternatifs
 les cas d’erreurs
Ex Description textuelle du cas d’utilisation s’authentifier
Titre S’authentifier
But Accéder a l’application
Résumé Les utilisateurs entrent leurs login pour se connecter et le
système vérifie les informations saisies
Acteur Administrateur, client
Pré-condition L’utilisateur accède à l’application
Post-condition L’utilisateur accède à l’application
Scenario nominal 1- l’utilisateur ouvre l’application
2- l’application demande les informations de connexion
3- l’utilisateur saisit son nom d’utilisateur et son mot de passe
4- le système vérifie les informations de connexion et autorise
l’accès à l’application si elles sont correctes
5- l’utilisateur accède à l’application
Scenario alternatif 4- les informations sont incorrectes et le système affiche un
message d’erreur et retourne a l’étape 3 du scenario nominal
NB : il faut dresser un diagramme de séquence de chaque cas d’utilisation.

Exemple de diagramme de séquence du cas d’utilisation « s’authentifier »

 e. Documenter les cas d’utilisation avec des diagrammes d’activité
Diagramme d’activité
- Permet de consolider les enchaînements de la fiche textuelle
- Permet d’identifier d’un seul coup d’œil la famille des scénarii d’un cas
d’utilisation qui décrit toutes les réactions du système
Identifier les classes candidates
- Concepts connus des utilisateurs du système
- Exploiter la description textuelle de chaque cas d’utilisation
 Chercher les noms communs importants
- Vérifiez les propriétés de chaque concept (identité, propriétés, comportement)

DA modélisant le fonctionnement d’une borne bancaire

[Link]. Conception du modèle statique

2eme activité de l’étape d’analyse : activité itérative
Objectifs
– Compléter et optimiser les diagrammes de classes établis sommairement lors de la
capture des besoins fonctionnels

a. Affiner les classes

– Examiner de manière détaillée les classes identifiées lors de l’étude des cas
d’utilisation
 – Optimiser avec la généralisation
– Eliminer
 classes redondantes (qui représentent le même concept)
 classes vagues (ne correspondent pas à des concepts que l’on peut
exprimer par des classes)
 classes identifiées à la place d’attribut (expriment des concepts
quantifiables)
 classes identifiées à la place d’un rôle (expriment un rôle dans une
association)
 classes représentant des acteurs (utiles uniquement lorsque le système
gère des informations sur l’acteur)
 classes de conception (introduisent trop tôt des choix de réalisation)
 classes représentant des groupes d’objets (inutiles, car implicites dans les
multiplicités des associations, et font souvent référence à des choix de
conception)
b. Affiner les associations
– Examiner de manière détaillée les associations identifiées lors de l’étude des cas
d’utilisation
– Eliminer
 associations non structurelles (expriment des relations dynamiques, c’est-
à- dire des liens instantanés entre objets)
 associations redondantes (peuvent être retrouvées par navigation grâce
aux associations existantes)
- La multiplicité exprimée sur les associations doit être vraie àtous les moments du
cycle de vie des instances.
- Utiliser l’agrégation et la composition Si l’une des classes joue le rôle d’ensemble
composé d’instances de l’autre classe, utiliser l’agrégation
- Identifier des propriétés
 spécifier que les objets à une extrémité de l’association doivent être
ordonnés avec la propriété {ordered}
préciser qu’un lien ne peut plus être modifié ni détruit avec la propriété {frozen}
c. Ajouter les attributs
- Conserver uniquement comme attributs les propriétés simples des classes que le
système doit mémoriser et utiliser
- Un attribut peut être valorisé par une structure de données
- Distinguer les attribut dérivés attribut intéressant pour l’analyste, mais
redondant, car sa valeur peut être déduite d’autres informations disponibles pour
la classe concernée
- la propriété {frozen} permet d’indiquer un attribut dont la valeur ne peut plus
changer une fois que l’objet a été créé.
d. Ajouter les opérations (optionnel)
- représente un service, un traitement qui peut être demandé à n’importe quel
objet de la classe.
Exemple d’un diagramme de classe