3ème partie: Développement

logiciel en orienté objet

Prof. Dr. Saint-Jean DJUNGU

 Plan
• Spécification initiale du système
• Analyse
• Conception
• Implémentation
 Introduction
• Le premier stade d’un projet consiste à
imaginer une nouvelle idée, qu’il s’agisse de
créer un nouveau système ou d’améliorer un
système existant

• Les développeurs doivent alors étudier cette

idée afin de comprendre les besoins et
d’imaginer des solutions possibles
 Imaginer un concept de système
• Voici quelques façons de trouver de nouveaux
concepts de système:
– Nouvelle fonctionnalité. Ajouter une fonctionnalité à un
système existant

– Restructuration. Supprimer des restrictions ou

généraliser le fonctionnement d’un système

– Simplification. Permettre à tout un chacun de réaliser des

tâches précédemment affectées à des spécialistes
 Imaginer un concept de système
– Automatisation. Automatiser des processus manuels

– Intégration. Combiner des fonctionnalités issues de systèmes

différents

– Analogies. Rechercher des analogies dans d’autres domaines

d’application et voir si elles génèrent des idées utiles

– Globalisation. Voyager dans d’autres pays et observer leurs

cultures et leurs façons de travailler
 Élaborer un concept
• Un bon concept de système doit répondre aux
questions suivantes:
– A qui l’application est-elle destinée?
* Déterminez clairement quelles personnes et quelles
entreprises sont les parties prenantes du nouveau
système

* Parmi ces parties prenantes, deux des plus

importantes sont les investisseurs et les utilisateurs
finaux
 Élaborer un concept
– Quels problèmes l’application résoudra-t-elle?
* Délimitez clairement la portée de l’effort et
établissez son périmètre

* Déterminez également les fonctionnalités qui

feront partie de la nouvelle application et celles qui
en seront absentes
 Élaborer un concept
– Quelles seront les conditions d’utilisation de
l’application?
A ce stade précoce, il est utile de se faire une idée
générale de la façon dont le nouveau système
pourra être utilisé
• Vous devez avoir une notion approximative de la
façon dont le nouveau système complétera les
systèmes existants
• Il importe de savoir si le logiciel sera utilisé
localement ou réparti sur un réseau
• S’il s’agit d’un produit commercial, caractérisez la
base de la clientèle
 Élaborer un concept
• Quand l’application est-elle attendue?
Deux aspects temporels sont importants:
– La faisabilité: le temps pendant lequel le système peut
être développé dans le cadre des contraintes budgétaires
et des ressources disponibles

– La nécessité: le moment où le système est requis pour

répondre à des objectifs métier

• Vous devez veiller à ce que les prévisions de temps liées à la

faisabilité technique et celles liées aux exigences métier soient
cohérentes
 Élaborer un concept
– Pourquoi l’application est-elle attendue?
Au besoin, préparez une étude de rentabilité
(business plan) du nouveau système si personne ne
l’a déjà réalisée
• L’étude de rentabilité contient la justification financière
du nouveau système, y compris le coût, les bénéfices
tangibles et intangibles, les risques et les solutions de
rechange envisagées
• S’il s’agit d’un produit commercial, estimez le nombre
d’unités susceptibles d’être vendues et déterminez un
prix de vente raisonnable: le revenu doit couvrir les
coûts et apporter un bénéfice
 Élaborer un concept
– Comment l’application fonctionnera-t-elle?
Réfléchissez à la faisabilité du problème.
• S’il s’agit d’un grand système, considérez les
mérites respectifs de différentes architectures
– L’objectif à ce stade n’est pas de choisir une solution mais
de s’assurer que le problème peut être raisonnablement
résolu
 Étude de cas d’un guichet
automatique de banque (GAB)
• Le concept du système d’un guichet
automatique de banque se présente comme
suit:
– Développez un logiciel qui permettent aux clients
d’accéder aux ordinateurs d’une banque et
effectuer leurs propres transactions financières
sans recourir à un employé
 A qui l’application est-elle destinée?

• Cette application est destinée à:

– Un fournisseur ou
– Une compagnie financière

• Pour cette étude de cas, nous supposons que vous

êtes un fournisseur qui construit le logiciel
– Développement d’un produit ordinaire
 Quels problèmes l’application
résoudra-t-elle?
• Ce logiciel servira à la fois à la banque et aux clients

• En ce qui concerne la banque, il accroît

l’automatisation et réduit le traitement manuel des
imprimés administratifs

• Du point de vue des clients, le GAB est omniprésent

et disponible en permanence, autorisant les
transactions réglementaires quand et où ils le
désirent
 Où l’application sera-t-elle
utilisée?
• Les logiciels de GAB sont devenus essentiels pour
les institutions financières

• Le client tient pour acquis qu’une banque disposera

d’un guichet automatique

• Ces guichets sont également disponibles dans de

nombreux magasins, sur les lieux des rencontres
sportives, et dans d’autres lieux publics du monde
entier
 Quand l’application est-elle
entendue?
• Tout effort de développement logiciel est une
proposition financière
– L’investissement correspondant doit au final procurer
un flux de revenus

• D’un point de vue économique, il est souhaitable

de:
– minimiser l’investissement,
– maximiser le revenu
– en avoir l’usage dès que possible
 Pourquoi l’application est-elle
attendue?
• Pour de nombreuses raisons, un fournisseur peut
décider de construire un produit logiciel

• Les entreprises commandent des développements

internes de produits technologiques difficiles à
acquérir et sont vitaux pour elles

• Quant à nous, nous n’avons pas de réelle motivation

à développer un logiciel de GAB, si ce n’est le désir
d’apprendre à utiliser un certain nombre de
techniques!
 Comment l’application
fonctionnera-t-elle?
• Nous adopterons une architecture à trois
niveaux (three-tier architecture) pour séparer
l’interface utilisateur de la logique de
programmation, et la logique de
programmation de la base de données
 Préparer un énoncé du problème
• Une fois que vous avez étoffé l’idée brute en répondant à ces
questions de haut niveau, vous êtes prêt à rédiger un énoncé
des exigences qui résume les buts et l’approche générale du
système proposé

• Tout au long du développement, vous devez distinguer les

exigences de la conception et de l’implémentation
– Les exigences décrivent la façon dont un système se comporte du
point de vue de l’utilisateur

• L’énoncé du problème doit exprimer ce qui doit être effectué

et non comment l’implémentation doit être réalisée
– Il doit faire état des besoins, non proposer une architecture du
système
 Nota
• L’énoncé du problème peut être plus ou moins
détaillé
– Celui d’un produit conventionnel, tel un programme de paie ou de
facturation, peut contenir un nombre considérable de détails
– Celui d’une application de recherche dans un nouveau domaine
peut manquer de précisions, mais doit définir l’objectif

• L’énoncé n’est qu’un point de départ, un moyen

de mieux comprendre le problème, non un
document immuable
 Étude de cas d’un guichet
automatique de banque (GAB)

Caissier

Compte
en banque
GAB

Ordinateur
Compte
de la banque
en banque
GAB Ordinateur
central
Ordinateur Compte
de la banque en banque

GAB
Compte
en banque
 Énoncé du problème
Vous allez concevoir un logiciel prenant en charge un
réseau d’organisations bancaires informatisées,
constitué à la fois de caissiers humains et de guichets
automatiques de banque (GAB), et partagé par un
consortium de banques. Chaque banque utilise son
propre ordinateur pour maintenir ses comptes et
traiter les transactions qui les concernent. Les
stations de caissiers sont la propriété de chaque
banque et chaque cassier a accès aux ordinateurs de
la banque où il travaille. Les caissiers saisissent les
données concernant les comptes et les transactions.
 Énoncé du problème
Les GAB communiquent avec un ordinateur central qui
autorise les transactions avec la banque appropriée.
Un GAB accepte une carte bancaire, interagit avec
l’utilisateur, communique avec le système central
pour effectuer les transactions, distribue des billets et
imprime des reçus. Le système nécessite une
journalisation adéquate des transactions et des
dispositions de sécurité. Il doit pouvoir gérer
correctement des accès concurrents et des dispositions
de sécurité. Il doit pouvoir gérer correctement des
accès concurrents à un même compte.
 Énoncé du problème
Les banques utiliseront leur propre logiciel
sur leurs ordinateurs. Vous devez concevoir
le logiciel pour les GAB et le réseau. Le
coût du système sera partagé entre les
banques au prorata du nombre de clients
possédant des cartes bancaires.
 Plan
• Spécification initiale du système
• Analyse
• Conception
• Implémentation
 Analyse
• Analyse du domaine

• Analyse de l’application
 Introduction
• L’analyse du domaine a pour objectif d’obtenir un
modèle précis, concis, compréhensible et correct du
monde réel
– Avant de construire quoi que ce soit de complexe, celui qui le construit doit
comprendre les besoins

• Lors de l’analyse, nous construirons des modèles et nous

commençons à comprendre plus clairement les exigences

• Vous devez analyser les implications des exigences et les

reformuler de manière rigoureuse
 Vue d’ensemble de l’analyse
Utilisateurs
Développeurs Émettre des Spécification initiale du système
demandes
Managers

Énoncé
Entretiens utilisateurs du problème
Connaissance du domaine
Construire Analyse:
Expérience du monde réel des modèles Analyse du domaine
Analyse de l’application
Systèmes apparentés
Modèle de classes
Modèle d’états
Modèle d’interactions

Conception
 Modèle de classes du domaine
• Vous devez effectuer les étapes suivantes
pour construire un modèle du domaine:
– Identifier les classes
– Préparer un dictionnaire de données
– Identifier les associations
– Identifier les attributs des objets et les liens
Modèle de classes du domaine
– Organiser et simplifier les classes en utilisant
l’héritage
– Vérifier que tous les chemins d’accès existent
pour les requêtes probables
– Itérer et affiner le modèle
– Réexaminer le niveau d’abstraction
– Regrouper les classes en packages
 Identifier les classes
• Les classes correspondent souvent à des
noms
– N’opérez toutefois pas à l’aveuglette. L’idée est de comparer des
concepts: tous les noms ne représentent pas de concepts et ceux-ci
peuvent être exprimés par d’autres catégories grammaticales

Exigences Classes Classes

Extraire Éliminer les classes
sources les noms candidates inappropriées
 Exemple du GAB
• Classes du GAB extraites à partir des noms figurant dans
l’énoncé du problème:
– Logiciel, Réseau de banque, Caissier, GAB, Consortium,
Banque, Ordinateur de banque, Compte, Transaction, Station
caissier, Données du compte, Données de la transaction,
Ordinateur central, Carte de retrait, Utilisateur, Espèces, Reçu,
Système, Provision pour tenue de compte, Provision de sécurité,
Accès, Coût, Client

• Classes du GAB déduites de la connaissance du domaine

du problème
– Ligne de communication, Journal de transactions
 Élimination des classes inutiles
dans le problème du GAB
• Classes redondantes: Utilisateur

• Classes sans intérêt: Coût

• Classes vagues: Système, Provision pour tenue de compte, Provision de

sécurité, Réseau de banques

• Attributs: Données sur les comptes, Reçu, Espèces, Données sur les
transactions

• Implémentation: Journal des transactions, Accès, Logiciel, Ligne de

communication

• Classes pertinentes: Compte, GAB, Banque, Ordinateur de banque, Carte

de retrait, Caissier, Station caissier, Ordinateur central, Consortium,
Client, Transaction
 Préparer un dictionnaire de
données
• Rédigez un paragraphe en décrivant précisément
chaque classe

• Décrivez la portée de la classe dans le problème

courant, en incluant toutes les hypothèses ou les
restrictions quant à son utilisation

• Le dictionnaire de données doit également décrire

les associations, les attributs, les opérations et les
valeurs énumérées
 Dictionnaire de données pour
quelques classes du GAB
• Banque: Institution financière qui tient les comptes des clients et émet
des cartes bancaires autorisant l’accès aux comptes sur le réseau des
GAB

• Caissier: Employé d’une banque autorisé à effectuer des transactions

sur une station et à recevoir ou à délivrer des espèces et des chèques
aux clients. Les transactions, les espèces et les chèques manipulés par
un cassier doivent être journalisés de façon appropriée

• GAB. Station permettant aux clients d’effectuer eux-mêmes leurs

transactions en utilisant leur carte bancaire comme identifiant. Le
GAB interagit avec le client pour recueillir les données de la
transaction, envoie ces données à l’ordinateur central pour qu’il les
valide et les traite, puis remet les billets au client. Vous supposerez
qu’un GAB ne peut pas fonctionner indépendamment du réseau
 Identifier les associations
• Une relation structurelle entre deux classes ou plus est une
association
• Une référence d’une classe à une autre est une association
• Les associations correspondent souvent à des verbes d’état
ou à des locutions verbales
• Elles expriment:
– une localisation physique (ACôtéDe, FaitPartieDe,
ContenuDans),
– une action dirigée (Conduit),
– une communication (ParleAvec),
– une appartenance (A, FaitPartieDe) ou
– la satisfaction d’une condition (TravaillerPour, MariéA,
Administre)
 Associations issues de l’énoncé du
problème du GAB
• Expressions verbales

1. Le réseau bancaire comprend des stations de cassiers et des GAB

2. Le consortium partage les GAB
3. Chaque banque fournit l’ordinateur de banque
4. L’ordinateur de chaque banque gère les comptes
5. L’ordinateur de chaque banque traite les transactions sur les comptes
6. Chaque banque possède des stations de caissiers
7. Les stations de caissiers communiquent avec l’ordinateur de chaque banque
8. Les caissiers saisissent les transactions sur les comptes
9. Les GAB communiquent avec l’ordinateur central à propos des transactions
10. L’ordinateur central valide les transactions avec la banque
11. Le GAB accepte la carte bancaire
12. Le GAB interagit avec l’utilisateur
 Associations issues de l’énoncé du
problème du GAB
13. Le GAB délivre des billets
14. Le GAB imprime des reçus
15. Le système gère les accès concurrents
16. La banque possède son propre logiciel
17. Le coût est réparti entre les banques

• Expressions verbales implicites

18. Le consortium est composé de banques

19. Les banques gèrent des comptes
20. Le consortium est propriétaire de l’ordinateur central
21. Le système fournit un journal des transactions
22. Le système est sécurisé
23. Les clients ont des cartes bancaires
Associations issues de l’énoncé du
problème du GAB
• Connaissance du domaine

24. Une carte permet d’accéder à des comptes

25. Une banque emploie des caissiers
 Conserver les associations
pertinentes
• Éliminez maintenant les associations inutiles ou
incorrectes en fonction des critères suivants:

– Associations entre classes éliminées. Si vous avez

éliminé l’une des classes de l’association, vous devez
supprimer l’association ou la redéfinir en termes
d’autres classes

Exemple: Nous pouvons éliminer les associations 1,

13, 14, 16, 17, 21, 22
 Conserver les associations
pertinentes
– Association non pertinentes ou relevant de
l’implémentation. Éliminez toute association
étrangère au domaine du problème ou qui
concerne des éléments d’implémentation

Exemple: Le système gère les accès concurrents

est un concept d’implémentation
 Conserver les associations
pertinentes
• Actions. Une association doit décrire une propriété
structurelle du domaine de l’application et non un
événement passager
– Il arrive qu’une exigence exprimée sous forme d’action
implique une relation structurelle sous-jacente et doive
être reformulée en conséquence

Exemple. Le GAB accepte la carte bancaire est une partie

du cycle d’interaction entre le GAB et le client, non une
relation permanente entre les GAB et les cartes
bancaires.
– On peut aussi éliminer les relations 10 et 12
 Conserver les associations
pertinentes
• Associations ternaires. Vous pouvez décomposer la
plupart des associations entre trois classes ou plus, en
associations binaires ou les exprimer par des associations
qualifiées
– Si un terme d’une association ternaire est purement descriptif et n’a pas
d’identité propre, il s’agit d’un attribut dans une association binaire

Exemple: - L’ordinateur de la banque traite les transactions sur les comptes

peut être décomposée en L’ordinateur de la banque traite les transactions
et Les transactions concernent des comptes

- Les GAB communiquent avec l’ordinateur central à

propos des transactions représente en réalité deux associations binaires:
Les GAB communiquent avec l’ordinateur central et La transaction est
entrée sur le GAB
 Conserver les associations
pertinentes
• Associations dérivées
– Omettez les associations qui peuvent être définies en
termes d’autres associations, car elles sont redondantes
• Par exemple, GrandParentDe peut être définie avec une paire
d’associations ParentDe

– Omettez également les associations définies par des

conditions sur des attributs
• Par exemple, plus-Jeune-Que exprime une condition sur la
date de naissance de deux personnes, non une information
supplémentaire
 Trouver les attributs
• Les attributs correspondent généralement à des noms
suivis d’une forme possessive
– « la couleur de la voiture » ou « la position du curseur »

• Les adjectifs représentent souvent des valeurs énumérées

– rouge, allumé ou expiré

• Contrairement aux classes et aux associations, les attributs

risquent d’être incomplètement décrits dans l’énoncé du
problème
– Vous devez puiser dans votre connaissance de l’application et du
monde réel pour les découvrir
 Trouver les attributs
• Vous devez normalement omettre les attributs dérivés
– Par exemple, âge est dérivé de dateDeNaissance et de
dateCourante (qui est une propriété de l’environnement)
– N’exprimez pas d’attributs dérivés comme des opérations, getAge
par exemple, même si c’est ainsi qu’ils seront finalement
implémentés

• Recherchez également les attributs pour les associations

Nota: Plusieurs critères permettent d’éliminer les attributs

inutiles ou incorrects
 Modèle de classes du GAB avec ses
attributs 1
Emet

code
Carte code
code Banque Compte Client
Consortium Banque 0..1
1 0..1 Compte
1 nom * 1 nom
code solde
1
1 code adresse
Employé limiteCrédit
Station
1 type 1
1
Emploie 1 1 *
1
1
Ordinateur 0..1
Ordinateur Banque
code 1 0..1 Caissier
Central Banque code
nom
code CommuniqueAvec Station
1
Station CommuniqueAvec 1 SaisiePar
* *
0..1 0..1
1
StationCaissier SaisieSur TransactionCaissier
CommuniqueAvec 1 * type
dateHeure
0..1
montant
GAB SaisieSur TransactionDistante * * 0..1

espèces type *
1 *
dateHeure *
1 CarteBancaire
Disponibles codeSecret
montant AutoriéePar
 Affiner en utilisant l’héritage
• L’héritage peut être appliqué dans deux directions:

– en généralisant les aspects communs des classes

existantes dans une super-classe (procédé ascendant)
• Ex: TransactionDistante et TransactionCaissier sont
similaires, sauf à leur initialisation, et peuvent être
généralisées par Transaction

– en spécialisant les classes existantes en plusieurs sous-

classes (procédé descendant)
• Ex: Un Compte peut être raffiné en CompteChèques et
CompteEpargne
 Associations similaires
• Lorsque le même nom d’association
apparaît plus d’une fois et signifie
essentiellement la même chose, essayez de
généraliser les classes associées

– Ex: Une Transaction est saisie sur un GAB ou

sur une StationCaissier, StationDeSaisie
généralise StationCaissier et GAB
 Modèle de classes du GAB avec ses
attributs et héritage 0..1

StationDeSaisie Transaction
1 SaisieSur * type *
dateHeure
montant
0..1
GAB
StationCaissier
espècesDisponibles Transaction Transaction
0..1 Caissier Distante
1
0..1
CommuniqueAvec * *
CommuniqueAvec 1
1 code SaisiePar
Ordinateur Station 1 AutoriséePar
code Ordinateur
Central Banque
Caissier
Banque Émet 1
code nom 0..1

Station
1
0..1 CarteBancaire
1
Client
1 1 codeSecret
Emploie nom 1 *
code adresse *
Station code 1
1
1 Banque Employé 1
*

nom Compte *
Consortium code code
Banque
1 1
0..1 code Carte solde
1
Compte 1 0..1 limiteCrédit 1
type
 Itérer sur le modèle de classes
• Un modèle objet est rarement correct d’emblée

• L’ensemble du processus de développement logiciel est

fait d’itérations et les différentes parties du modèle se
trouvent souvent à différents stades d’achèvement
– Si vous détectez une déficience, revenez si nécessaire à un stade
antérieur pour la corriger

Ex: La distinction entre Banque et OrdinateurBanque et entre

Consortium et OrdinateurCentral ne semble pas affecter l’analyse
- Fusionnez OrdinateurBanque dans Banque et
OrdinateurCentral dans Consortium
 Modèle de classes du GAB après
révision
Transaction
SaisieSur *
dateHeure
1
*
MiseAJour
montant
1 type
StationDeSaisie Transaction Autorisation *

Caissier Carte
SaisiePar * *
1 AutoriséePar
GAB
StationCaissier Caissier 1
espècesDisponibles nom Émet 0..1 Autorisation
0..1 0..1 0..1 Carte
1 Emploie
code * *
1 1
code Station code
Banque Employé Client
Station 1
nom
nom Compte
Consortium code code adresse
Banque
1 1
0..1 code Carte solde
1
Compte 1 0..1 limiteCrédit *
type 1
Grouper les classes en packages
• La dernière étape de la modélisation des classes consiste à
regrouper les classes en packages
– Un package est un groupe d’éléments (classes, associations,
généralisation et d’autres packages de niveau inférieur) ayant un
thème commun

• Pour le modèle GAB, les packages sont les suivants:

– guichets – caissier, station de saisie, station de caissier, GAB;
– comptes – compte, carte bancaire, autorisation de carte, client,
transaction, mise à jour, transaction caissier, transaction distante;
– banques – consortium, banque
 Modèle d’états du domaine
• Les étapes suivantes permettent de
construire un modèle d’états du domaine:
– Identifier les classes du domaine ayant des
états;
– Trouver les états;
– Trouver les événements;
– Construire des diagrammes d’états;
– Évaluer les diagrammes d’états
 Identifier les classes du domaine
ayant des états
• Examinez la liste des classes du domaine et
recherchez celles qui ont un cycle de vie distinct
– Ce sont celles qui sont caractérisées par une
progression ou qui présentent un comportement
cyclique
• Par exemple, un article destiné à une publication scientifique
passe de l’état En cours de rédaction à celui de Présélectionné
pour finalement se trouver dans l’un des états Accepté ou
Rejeté

• Exemple du GAB. Compte est un concept métier important, et

le comportement correct d’un GAB dépend de l’état de
Compte
 Trouver les états
• Listez les états de chaque classe et donnez à chaque état un
nom évocateur

• Caractérisez les objets de chaque classe:

– les valeurs que ses attributs peuvent avoir
– les associations auxquelles ils peuvent participer et leurs
multiplicités,
– les associations et les attributs qui ne sont significatifs que dans
certains états,
– etc

• Les états doivent être basés sur des différences qualitatives

dans le comportement, les attributs ou les associations
 Exemple du GAB
• Voici certains états de Compte:
– Normal (normalement accessible),
– Fermé (fermé par le client mais figurant
toujours dans les fichiers de la banque),
– À découvert (les retraits du dépassent le solde
du compte) et
– Suspendu (l’accès au compte est bloqué pour
une raison quelconque)
 Trouver les événements
• Une fois que vous disposez d’un ensemble préliminaire
d’états, recherchez les événements qui déclenchent les
transitions entre les états
– Pensez aux stimuli qui provoquent un changement d’état

• Exemple du GAB
– Les événements importants comprennent:
• fermer compte,
• retirer montant supérieur au solde,
• trois codes faux successifs
• suspicion de fraude et
• action administrative
 Construire des diagrammes
d’états
Compte Fermé

fermer compte
retirer montant supérieur au solde
ouvrir compte
Normal ADécouvert
déposer montant suffisant
suspicion de fraude

lever opposition
action administrative
Suspendu
trois codes faux successifs
Évaluer les diagrammes d’états
• Examinez chaque modèle d’états
– Tous les états sont-ils connectés?
• Prêtez une attention particulière aux chemins d’accès
– S’il représente une classe « progressive », y a-t-il un
chemin conduisant de l’état initial à l’état final?
– Les variations attendues sont-elles présentes?
– S’il représente une classe « cyclique », la boucle
principale est-elle présente?
– Existe-t-il des états « morts » (terminaux) qui mettent
fin au cycle?
Modèle d’interactions du domaine

• Le modèle d’interactions a rarement

d’importance pour l’analyse du domaine
 Analyse
• Spécification initiale du système
• Analyse du domaine
• Analyse de l’application
 Modèle d’interactions de
l’application
• Vous pouvez construire un modèle d’interactions de
l’application en observant les étapes suivantes:
– Déterminer la frontière du système
– Trouver les acteurs
– Trouver les cas d’utilisation
– Trouver les événements initiaux et finaux
– Rédiger les scénarios standard
– Ajouter des scénarios de variations et d’exceptions
– Trouver les événements externes
– Préparer des diagrammes d’activité pour les cas d’utilisation
complexes
– Organiser les acteurs et les cas d’utilisation
– Vérifier avec le modèle de classes du domaine
 Déterminer la frontière du système
• Vous devez connaître le périmètre précis d’une
application – la frontière du système – afin de
spécifier ses fonctionnalités

• En règle générale, vous ne devez pas considérer

les êtres humains comme faisant partie du système
– Les êtres humains sont les acteurs qui doivent interagir
avec le système, mais leurs interactions ne sont pas
contrôlées par le système
– En revanche, vous devez tenir compte des erreurs
pouvant être réalisées par les humains sur le système
 Exemple du GAB
• Dans la pratique commerciale, l’application GAB
serait séparée de l’application « cassier »: une
application GAB est transversale à plusieurs
banques alors qu’une application « caissier » est
interne à une banque

• Dans la suite, nous nous concentrerons sur le

comportement du GAB et nous ignorerons les
détails concernant le caissier
 Trouver les acteurs
• Une fois déterminé la frontière du système, vous devez
identifier les objets externes qui interagissent avec lui
– Ce sont ses acteurs

• Les acteurs peuvent être:

– des êtres humains,
– des équipements ou
– d’autres systèmes logiciels

• Exemple du GAB. Les acteurs sont Client, Banque et

Consortium
 Trouver les cas d’utilisation
• Pour chaque acteur, dressez la liste des façons
fondamentalement différentes qu’il a d’utiliser le
système
– Chacune de ces façons est un cas d’utilisation

• Chaque cas d’utilisation doit représenter un type

de service que le système fournit: quelque chose
qui apporte de la valeur à l’acteur
 Trouver les cas d’utilisation
• Essayez de vous concentrer sur l’objectif principal
du cas d’utilisation et différez les choix
d’implémentation

• Représentez les acteurs et les cas d’utilisation et

connectez les acteurs aux cas d’utilisation

• Rédigez une ou deux phrases de résumé pour

chaque cas d’utilisation
Diagramme de cas d’utilisation du
GAB
GAB
initialiser
une session

interroger
un compte Banque

Client
exécuter une
transaction

transmettre
des données Consortium
 Résume des cas d ’utilisation du
GAB
• Initialiser une session. Le guichet automatique
vérifie l’identité du client et affiche une liste de
comptes et d’interventions possibles pour ce
clients sur le système

• Interroger un compte. Le système affiche les

données générales concernant les fonctionnalités,
telles que le solde actuel, la date de la dernière
transaction et la date d’envoi du dernier relevé
 Résume des cas d ’utilisation du
GAB
• Exécuter une transaction. Le système GAB
effectue une opération qui affiche le solde d’un
compte bancaire, comme un dépôt, un retrait ou un
transfert. Le GAB vérifie que les transactions
terminées sont enregistrées dans la base de
données de la banque

• Transmettre des données. Le GAB utilise le

réseau du consortium pour communiquer avec les
ordinateurs de banque appropriés
Trouver les événements initiaux et
finaux
• Recherchez les événements qui initient chaque cas
d’utilisation
– Déterminez l’acteur qui initie le cas d’utilisation et définissez
l’événement envoyé au système
– Dans de nombreux cas, l’événement initial correspond à la
demande du service que le cas d’utilisation fournit
– Dans d’autres cas, l’événement est l’occurrence qui enclenche un
enchaînements d’activités
– Attribuez à cet événement un nom évocateur

• Vous devez également déterminer le ou les événements

finaux et lesquels il convient d’inclure dans le cas
d’utilisation
Événements initiaux et finaux pour les
cas d’utilisation du GAB
• Initialiser une session
– L’événement initial est l’insertion d’une carte bancaire
dans le guichet automatique par le client
– Il y a deux événements finaux: le système rend la carte
au client ou il la conserve

• Interroger un compte
– L’événement initial est une demande du client de
consulter les données de son compte
– L’événement final est la présentation de ces données au
client
Événements initiaux et finaux pour les
cas d’utilisation du GAB
• Exécuter une transaction
– L’événement initial est l’initialisation d’une transaction par le
client
– Il y a deux événements finaux: la transaction est validée ou elle est
annulée

• Transmettre des données

– L’événement initial peut être déclenché suite à la demande de
consultation d’un compte par le client. Il peut également s’agir
d’une reprise sur une panne suite à une panne de réseau, une panne
d’alimentation ou autre
– L’événement final est la transmission effective des données
 Préparer des scénarios standard
• Pour chaque cas d’utilisation, préparez un ou
plusieurs dialogues types pour vous faire une idée
du comportement attendu du système
– Ces scénarios illustrent les interactions importantes, les
formats d’affichage externe et les échangent
d’information

• Un scénario est une séquence d’événements se

produisant au sein d’un ensemble d’objets qui
interagissent
 Scénario standard pour Exécuter
une transaction
• Le GAB affiche un menu des comptes et des commandes
• L’utilisateur choisit un retrait sur un compte
• Le GAB demande le montant du retrait
• L’utilisateur demande 100€
• Le GAB vérifie que le montant n’excède pas la somme
autorisée
• Le GAB contacte le consortium et la banque et vérifie que le
compte dispose de fonds suffisants
• Le GAB délivre un ou des billets et demande à l’utilisateur
de le(s) prendre
• L’utilisateur prend le ou les billets
• Le GAB affiche un menu des comptes et des commandes
Ajouter des scénarios de variations et
d’exceptions
• Après avoir préparé les scénarios standard,
considérez les cas « particuliers », tels que
les entrées omises, les valeurs minimales et
maximales et les valeurs dupliquées
– Puis prenez en compte les cas d’erreurs, comme
les valeurs invalides ou les absences de réponse
 Exemple du GAB
• Voici une liste de variantes et d’exceptions (on
peut préparer un scénario pour chacun d’eux):
– Le GAB ne peut pas lire la carte
– La validité de la carte a expiré
– Le GAB attend une réponse et le délai de temporisation
est dépassé
– Le montant est invalide
– La machine est en panne de billets ou de papier
– Les lignes de communications sont coupées
– La transaction est rejetée pour cause de suspicion de
fraude
 Trouver les événements externes
• Examinez les scénarios afin d’identifier les
événements externes
– incluez toutes les entrées, les décisions, les interruptions
et les interactions provenant de ou dirigées vers des
utilisateurs ou des équipements externes

• Une transmission d’informations à un objet est un

événement
– Par exemple, saisir code secret est un message envoyé
depuis un agent externe Utilisateur vers l’objet
d’application GAB
 Diagramme de séquence du
scénario exécuter une transaction
:Utilisateur :GAB :Consortium :Banque
afficher menu

sélectionner retrait

sélectionner compte
demander montant
saisir montant
vérifier fonds
vérifier fonds

confirmer fonds
confirmer fonds
délivrer billet(s)

prendre billet(s)
 Préparer des diagrammes d’activité
pour les cas d’utilisation complexes

• Les diagrammes de séquence capturent les

dialogues et les interactions entre les acteurs, mais
ils ne montrent pas clairement les différentes
possibilités ni les décisions

• Vous pouvez utiliser des diagrammes d’activité

pour documenter la logique métier durant
l’analyse, mais ne les utilisez pas comme excuse
pour commencer prématurément l’implémentation
 Diagramme d’activité pour la
vérification d’une carte

rendre carte insérer carte

[illisible]
[lisible] [mauvais code banque
[communication en panne] ou mauvais compte]

[carte OK]
[communication en panne]

[compte OK]

[communication en panne] demander

code secret

[communication en panne] [illisible]

[code secret correct] retenir carte

 Organiser les acteurs et les cas
d’utilisation
• L’étape suivante consiste à organiser les cas
d’utilisation avec des relations (include,
extend et généralisation)
– Cette pratique est particulièrement utile pour
des systèmes de grande taille ou complexes
Organisation des cas d’utilisation
Client Banque
Consortium

GAB
initialiser
une session
« include »
« include »

interroger exécuter « include »

un compte une transaction
« include »

transmettre
des données
 Vérifier avec le modèle de classe
du domaine
• À ce stade, le modèle de l’application et le
modèle du domaine devraient être
globalement cohérents

• Les acteurs, les cas d’utilisation et les

scénarios sont tous basés sur des classes et
des concepts du modèle du domaine
Modèle de classes d’application
• Les classes d’application définissent l’application elle-même et
non les objets du monde réel sur lesquels l’application agit

• La plupart des classes d’application sont « orientées ordinateur »

et définissent la façon dont les utilisateurs perçoivent
l’application

• Vous pouvez construire un modèle de classes d’application en

observant les étapes suivantes:
– Spécifier les interfaces utilisateur
– Définir des classes frontières
– Déterminer les contrôleurs
– Vérifier avec le modèle d’interactions
 Spécifier les interfaces
utilisateur
• La plupart des interactions peuvent être divisées
en deux parties:
– La logique application et
– Interface utilisateur

• Une interface utilisateur (IHM – interface homme-

machine) est un objet ou un groupe d’objets qui
fournit à l’utilisateur d’un système un moyen
cohérent d’accéder aux objets du domaine, aux
commandes et aux options de l’application
Format d’interface pour un GAB
Messages à l’utilisateur

1 2 3 CORRECTION

4 5 6 ANNULATION

7 8 9 VALIDATION

reçus billets
 Définir des classes frontières
• Une classe frontière est une classe qui fournit un
lien d’acheminement pour les communications
entre un système et une source externe

• Exemple du GAB. Il serait utile de définir des

classes frontières (ClasseFrontièreCarteBancaire
et ClasseFrontièreCompte) pour encapsuler les
communications entre le GAB et le consortium
 Déterminer des contrôleurs
• Un contrôleur est un objet actif qui gère le contrôle au
sein d’une application
– Il reçoit des signaux du monde extérieur ou des objets internes au
système, réagit à ces signaux, invoque des opérations sur les objets
du système et envoie des signaux au monde extérieur

• Exemple du GAB. Il possède deux boucles de contrôle

majeurs:
• La boucle externe vérifie les clients et les compte
• La boucle interne vérifie les transactions
– Chacune de ces boucles pourrait très naturellement être gérée avec un
contrôleur
 Vérifier avec le modèle
d’interactions
• En construisant le modèle de classes
d’application, revoyez les cas d’utilisation
et réfléchissez à la façon dont ils peuvent
fonctionner
Modèle de classes d’application
InterfaceUtilisateur InterfaceConsortium

FrontièreCarteBancaire * * InterfaceUtilisateur TypeProblème

codeBanque codeBanque 1
codeCarte codeCompte
numéroSérie *Solde
motDePasse limiteCrédit *
Limite typeCompte
nomBanque nomBanque
ProblèmeDeContrôleur
nomClient dateHeureDébut
adresseClient dateHeureFin
*
transactionActive ContrôleurDeTransactions
TransactionDistante * 0..1 dateHeureDébut

CarteBancaire carteActive 1
0..1 0..1 SessionGAB ContrôleurDeSession
Compte 0..1 dateHeureDébut * 1 état
compteActif
Modèle d’états de l’application
• Le modèle d’états de l’application se concentre sur les
classes de l’application et augmente le modèle d’états du
domaine

• Vous pouvez construire un modèle d’états de l’application

en observant les étapes suivantes:
• Déterminer les classes d’application ayant des états
• Identifier les événements
• Construire des diagrammes d’états
• Comparer aux autres diagrammes d’états
• Comparer au modèle de classes
• Comparer au modèle d’interactions
 Déterminer les classes d’application
ayant des états
• Les classes de l’interface utilisateur et les classes
contrôleurs sont de bonnes candidates pour les
diagrammes d’états
– Les classes frontières ont tendance à être statiques et
sont utilisées pour regrouper les importations et les
exportations de données

• Exemple du GAB. Les contrôleurs possèdent des

états importants que nous allons élaborer
 Trouver les événements
• Pour le modèle d’interactions de l’application,
vous avez préparé un certain nombre de scénarios
– Étudiez maintenant ces scénarios et extrayez-en les
événements

• Exemple du GAB. Certains événements sont:

• insérer carte,
• saisir code secret,
• terminer session et
• prendre carte
 Construire des diagrammes d’états

• L’étape suivante consiste à construire un

diagramme d’états pour chaque classe
présentant un comportement temporel
– Choisissez l’une de ces classes et envisagez un
diagramme de séquence
 Diagramme d’états de ContrôleurDeSessions
ContrôleurDeSessions
Carte reprise Récupération de la carte
Inexploité Éjection de la carte
coupure de com
do / demander do / éjecter carte
reprise de com de récupérer carte
[pas de carte]
fin de communication [possède carte]
Écran principal
do / afficher écran principal
insérer carte [problème] /compteur:=0 insérer carte
[problème]
Obtention du code secret
do / demander code secret Problème de carte /conserver carte
saisir code secret code secret incorrect do / message d’erreur
[compteur<n] / compteur ++
Vérification du compte code secret incorrect
do / vérifier compte [/ compteur>=n]
compte OK / new ContrôleurDeTransactions

Exécuter les transactions

Émission
Récupération de la carte carte récupérée
Éjection de la carte do / demander de
do / éjecter carte récupérer carte
Impression du reçu Récupération du reçu
reçu récupéré
do / imprimer reçu Do / demander de
Récupérer reçu
 Vérifier avec les autres diagrammes
d’états
• Vérifier que les diagrammes d’états de chaque
classe sont complets et cohérents
– Chaque événement doit avoir un émetteur et un
récepteur, éventuellement le même objet

• Exemple du GAB. Le ContrôleurDeSessions

initialise le ContrôleurDeTransactions et la fin du
ContrôleurDeTransactions provoque la reprise du
ContrôleurDeSessions
 Vérifier avec le modèle de classes
• De même, vérifiez que les diagrammes d’états
sont cohérents avec le modèle de classes du
domaine et celui de l’application

• Exemple du GAB. Plusieurs GAB sont

susceptibles d’accéder simultanément à un
compte. L’accès à un compte doit être contrôlé
pour garantir qu’une seule mise à jour est
appliquée à la fois
 Vérifier avec le modèle
d’interactions
• Lorsque le modèle d’états est prêt, revenez
en arrière et comparez-le avec les scénarios
du modèle d’interactions
 Ajouter les opérations
• Les opérations sont issues des sources
suivantes:
– du modèle de classes
– des cas d’utilisation

• Il existe des opérations « aide-mémoire »

 Opérations issues du modèle de
classes
• La lecture et l’écriture des valeurs
d’attributs et des liens d’association sont
implicites dans le modèle de classes
– Durant l’analyse, tous les attributs et les
associations sont supposés accessibles
 Opérations issues des cas
d’utilisation
• La plupart des fonctionnalités complexes d’un
système proviennent de ses cas d’utilisations
– Durant la définition du modèle d’interactions, les cas
d’utilisation conduisent à des activités
• Nombre d’entre elles correspondent aux opérations du modèle
de classes

• Exemple du GAB.
– Consortium a l’activité vérifierCodeBanque
– Banque a l’activité vérifierCodeSecret
 Opérations « aide-mémoire »
• Le comportement des classes dans le monde réel
suggère parfois des opérations
– Meyer nomme cela l’aide-mémoire, parce que ces
opérations ne dépendent pas d’une application
particulière mais qu’elles présentent un intérêt
intrinsèque 
• Les opérations de l’aide-mémoire fournissent
l’occasion d’élargir la définition d’une classe au-
delà des besoins stricts du problème immédiat
Quelques opérations aide-mémoire
pour le GAB
• compte.fermer()
• banque.créerCompteEpargne(client):compte
• banque.créerCompteChèques(client):compte
• Banque:créerAutCarteBancaire(client) ->
autorisationCarteBancaire
• autorisationCarteBancaire.ajouterCompte(compte)
• autorisationCarteBancaire.supprimerCompte(com
pte)
• autorisationCarteBancaire.fermer()
 Simplifier les opérations
• Recherchez, dans le modèle de classes, les
opérations similaires et les variations de
forme d’une même opération
– Utilisez l’héritage, quand c’est possible, pour
réduire le nombre d’opérations distinctes
 Modèle du domaine du GAB avec des opérations
EntréeSur
Transaction
*
dateHeure
1
*
1
MiseAJour
StationDEntrée montant
type
*
Transaction Autorisation
Caissier Carte
GAB SaisiePar *
CarteBancaire
*
AutoriséePar
StationCaissier 1 1
espècesDisponibles numéroSérie AutorisationCarte
Caissier *
codeSecret
0..1
vérifierCarteBancaire nom 1
limite
1 ajouterCompte
0..1 code 0..1
supprimerCompte
1 Station Émet
Banque Emploie fermer
code nom
0..1 *
*
1
Station vérifierCodeSecret code
code créerCompteEpargne Employé
Client
consortium Banque 0..1
1 Compte nom
1 créerCompteChèque code solde
créerAutCarteBancaire Carte adresse
vérifierCarteBancaire code limiteCrédit
1
Compte 1 0..1
type *
fermer
1
 Plan

• Analyse
• Conception
• Implémentation
 Conception
• Conception du système

• Conception des classes

 Introduction
• Pendant l’analyse, l’accent est mis sur ce qui doit
être fait, le quoi, indépendamment de la manière
de le faire, le comment

• Durant la conception, les développeurs prennent

des décisions quant à la façon de résoudre le
problème, d’abord à un haut niveau, puis à des
niveaux de plus en plus détaillés
 Vue d’ensemble de la conception
du système
• La conception du système est la première
étape de la conception, au cours de laquelle
on élabore l’approche qui permettra de
résoudre le problème

• Pendant la conception du système, les

développeurs déterminent la structure
globale et le style
 Architecture du système
• L’architecture du système détermine la
façon dont le système sera organisé en sous-
sytèmes

• En outre, l’architecture fournit le contexte

des décisions détaillées qui seront prises à
des stades ultérieurs
 Architecture du système
• Vous devez prendre les décisions suivantes:
– Estimer les performances du système
– Mettre au point un plan de réutilisation
– Organiser le système en sous-systèmes
– Identifier les questions de concurrence inhérentes au
problème
– Allouer les sous-systèmes aux équipements matériels
– Gérer les stockages de données
– Choisir une stratégie de contrôle du logiciel
– Traiter les cas limites
– Arbitrer les priorités
– Sélectionner un style architectural
 Estimer les performances
• Dès le début de la planification d’un
nouveau système, vous devez préparer une
estimation approximative des performances

– Les ingénieurs nomment cela un calcul « au dos

de l’enveloppe »
– L’objectif n’est pas d’obtenir une exactitude
absolue, mais simplement de déterminer la
faisabilité du système
 Exemple du GAB
• Imaginez que nous soyons en train de planifier un
réseau de GAB pour une banque. Nous pourrions
procéder comme suit:
– La banque possède 40 agences
– Supposez également que, lors d’une journée chargée, la
moitié des terminaux soient occupés en même temps
– Supposez enfin qu’il faille à chaque client environ 1
minute pour terminer une session, et que la plupart des
transactions impliquent un seul dépôt ou un seul retrait
 Exemple du GAB
– Nous estimons donc qu’il y aura un pic de 40
transactions par minute, soit environ 1 par
seconde

• Cette estimation est peut-être imprécise,

mais elle montre que nous n’avons pas
besoin d’un matériel particulièrement
rapide
 Mettre au point un plan de
réutilisation
• On affirme que la réutilisation est l’un des
avantages de la technologie objet, mais elle ne se
produit pas automatiquement

• Les éléments réutilisables comprennent les:

– Modèles,
– Bibliothèques,
– Framworks,
– Patterns
 Bibliothèques
• Une bibliothèque est une collection de classes qui
sont utiles dans de nombreux contextes

– Cette collection de classes doit être soigneusement

organisée, afin que les utilisateurs puissent les localiser
facilement

– De plus, la description des classes doit être exacte et

complète, pour aider les utilisateurs à déterminer leur
pertinence
 Framworks
• Un framwork est une structure, un squelette
de programme qui doit être étoffé pour
construire une application complète

• Exemple: Spécialiser des classes abstraites

avec des comportements spécifiques à la
dite application
 Patterns
• Un pattern est une solution éprouvée à un problème
récurrent

• Il existe des patterns pour la:

– analyse,
– Architecture,
– Conception,
– Implémentation

• Au lieu de tout réinventer, les patterns vous permettent de

réutiliser des solutions existantes
 Décomposer un système en sous-
systèmes
• Hormis pour les plus petites, la première étape de la
conception consiste à diviser le système en sous-parties

• Un sous-système n’est ni un objet ni une fonction, mais

plutôt un ensemble de classes, d’associations,
d’opérations, d’événements et de contraintes qui sont reliés
et qui ont des interfaces bien définies et (préalablement)
restreintes avec d’autres sous-systèmes

• Un sous-système est généralement défini par les services

qu’il fournit
 Décomposer un système en sous-
systèmes
• Chaque sous-système peut donc être conçu
indépendamment sans affecter les autres

• Vous devez définir les sous-systèmes de telle sorte

que la plupart des interactions soient internes et ne
franchissent pas les frontières du sous-système
– Cela réduit les dépendances entre sous-systèmes
 Décomposer un système en sous-
systèmes
• Les relations entre sous-systèmes peuvent
être de type client-serveur ou peer-to-peer
 Architecture du système GAB
Ordinateur banque
Station GAB Ordinateur consortium

Caissier

GAB Consortium Station

lien caissier

réseau
Carte Code BD
lien
bancaire station
réseau Compte
Utilisateur
interface Code Client
utilisateur banque
Autorisation
carte

Transaction
Transaction
Transaction
 Identifier la concurrence
• Dans la pratique, on peut implémenter de
nombreux objets sur un même processeur si ces
objets ne doivent pas être actifs en même temps

• Un objectif important de la conception d’un

logiciel consiste à identifier les objets qui doivent
être actifs simultanément et ceux dont l’activité est
mutuellement exclusive
– Ces derniers objets peuvent être regroupés dans un seul
thread de contrôle, ou tâche
 Identifier la concurrence
intrinsèque
• Le modèle d’états sert de guide pour identifier les
concurrences

• Deux objets sont intrinsèquement concurrents s’ils

peuvent recevoir des événements simultanément
sans interagir

• Il n’est pas indispensable d’implémenter deux

sous-systèmes intrinsèquement concurrents sur
des unités matérielles distinctes
 Exemple du GAB
Si l’énoncé du problème du GAB spécifiait
que chaque machine devrait continuer à
fonctionner en local en cas de panne du
système central (avec peut être une
restriction au montant des transactions), il
n’y aurait pas d’autre choix que d’inclure
une unité centrale dans chaque GAB avec
un programme de contrôle complet
Définir les tâches concurrentes
• Bien que tous les objets soient conceptuellement
concurrents, beaucoup d’objets d’un système sont
interdépendants en pratique

• En examinant les diagrammes d’états de chaque objet et

l’échange d’événements entre eux, on constate qu’il est
souvent possible de grouper plusieurs objets dans un même
thread de contrôle

• Un thread de contrôle est un chemin de diagrammes

d’états, sur lequel un seul objet est actif à la fois
 Exemple du GAB
• Pendant que la banque vérifie un compte ou
traite une transaction, le GAB est inactif

• Si un ordinateur central contrôle

directement le GAB, nous pouvons
combiner l’objet GAB avec l’objet
transaction dans une seule tâche
 Allouer des sous-systèmes
• Vous devez allouer chaque sous-système
concurrent à une unité matérielle – soit un
processeur généraliste, soit une unité
fonctionnelle spécialisée – comme suit:
– Estimez les besoins de performances et
ressources nécessaires pour les satisfaire

– Choisissez l’implémentation matérielle ou

logicielle des sous-systèmes
 Allouer des sous-systèmes
– Allouez les sous-systèmes logiciels à des
processeurs pour satisfaire les besoins de
performances et limiter les communications
entre processeurs

– Déterminez la connectivité des unités

matérielles servant qui implémentent les sous-
systèmes
 Gérer le stockage des données
• Il existe plusieurs solutions de stockage des
données que vous pouvez utiliser
séparément ou combiner:
– Structures de données,
– Fichiers et
– Bases de données
 Exemple du GAB
• L’ordinateur de banque type utiliserait un SGBD
relationnel. Ils sont:
• rapides,
• facilement disponibles, et
• leur coût-efficacité correspond à ce type d’application
financière

• Le GAB pourrait également utiliser une base de

données, mais le paradigme en est moins évident
 Gérer les ressources globales
• Le concepteur du système doit identifier les
ressources globales et déterminer les mécanismes
permettant de contrôler leur accès

• Il existe plusieurs sortes de ressources globales:

– Unités physiques, comme les processeurs, les lecteurs
de bande et les satellites de communication
Gérer les ressources globales
– Espaces, par exemple l’espace disque, l’écran
d’une station de travail et les boutons d’une souris

– Noms logiques, tels que les identifiants d’objets,

les noms de fichiers et les noms de classes

– Accès aux données partagées, par exemple les

bases de données
 Exemple du GAB
• Les codes banque et les numéros de compte
sont des ressources globales
– Les codes banque doivent être uniques dans le
contexte d’un consortium donné

– Les numéros de compte doivent être uniques

dans le contexte d’une banque
 Choisir une stratégie de contrôle
du logiciel
• Il existe deux types de flux de contrôle dans
un système logiciel:
– Le contrôle externe et
– Le contrôle interne
 Gérer les cas limites
• Même si l’essentiel de la conception
concerne le comportement du système à
l’état stable, vous devez prendre en compte
les cas limites et traiter les types de
problèmes suivants:
– Initialisation
– Terminaison
– Échecs
 Arbitrer les priorités
• Le concepteur du système doit définir des priorités
qui serviront pendant le reste de la conception

– Ces priorités permettent de concilier des buts

souhaitables mais incompatibles

– Par exemple, on peut souvent rendre un système plus

rapide en ajoutant de la mémoire, mais cela augmente
la consommation électrique et coûte plus cher
 Exemple du GAB
• La station GAB est un produit de masse. En
conséquence, le coût de fabrication constitue une
préoccupation et le produit résultant doit présenter
une interface utilisateur impeccable

• Le logiciel doit être robuste et résistant aux pannes

• Le coût de développement est un critère moins

important, puisqu’il peut être amorti par la vente
de nombreux exemplaires
 Styles architecturaux courants
• Il existe plusieurs modèles de styles architecturaux
courants dans les systèmes existants

• Chacun d’eux est bien adapté à un certain type de système

• Si votre application présente des caractéristiques

similaires, vous pouvez économiser des efforts en utilisant
l’architecture correspondante, ou au moins en la prenant
comme point de départ de votre conception
 Systèmes architecturaux courants
• Voici une liste de types de systèmes:

– Transformation par lots (batch). Effectue des traitements

séquentiels. L’application reçoit les entrées et l’objectif consiste à
calculer une réponse

– Transformation continue. Système dans lequel les sorties

dépendent activement d’entrées qui changent

– Interface interactive. Système dominé par des interactions entre le

système et des agents externes, comme des êtres humains ou des
équipements
Systèmes architecturaux courants
– Simulation dynamique. Système qui simule l’évolution
d’objets du monde réel

– Système temps réel. Système interactif dans lequel les

actions sont soumises à des contraintes de temps très
fortes

– Gestionnaire de transactions. Système dont la fonction

première est de stocker et retrouver des données
 L’architecture du système
GAB
• Le système GAB est un hybride d’interface
interactive et de gestionnaire de transactions
– Les stations d’entrée sont des interfaces
interactives, leur but étant d’interagir avec un
humain pour recueillir les informations
nécessaires à la formulation d’une transaction

– Le consortium et les banques représentent avant

tout un gestionnaire de transactions réparti
 Conception
• Conception du système

• Conception des classes

 Introduction
• La phase d’analyse détermine ce que l’implémentation doit
réaliser, et la conception du système détermine le plan
d’« attaque »

• L’objectif de la conception des classes est de finaliser la

définition des classes et de choisir les algorithmes des
opérations

• Cette partie explique comment étoffer le modèle d’analyse

afin d’obtenir une base pour l’implémentation
 Vue d’ensemble de la conception
des classes
• La conception des objets comprend les étapes
suivantes:

– Combler le fossé entre les exigences de haut niveau et les

services de bas niveau

– Réaliser les cas d’utilisation par des opérations

– Formuler un algorithme pour chaque opération

– Décomposer récursivement jusqu’à obtenir des opérations de

conception qui desservent des opérations de plus haut niveau
Vue d’ensemble de la conception
des classes
– Remanier le modèle pour obtenir une conception plus
nette

– Optimiser les chemins d’accès aux données

– Réifier les comportements qui doivent être manipulés

– Ajuster la structure des classes pour augmenter

l’héritage

– Organiser les classes et les associations

 Combler le fossé
• Les exigences de haut niveau proviennent de
plusieurs sources:
– Cas d’utilisation,
– Fonctionnalités de l’application et
– Opérations et services du système

• Les ressources comprennent:

– L’infrastructure du système d’exploitation,
– Les bibliothèques de classes et
– Les applications précédentes
 Le fossé de la conception
Fonctionnalités désirées

Le fossé
?
Ressources disponibles

Si vous pouvez développer chaque fonctionnalité à partir des ressources,

vous avez terminé
 Réaliser un cas d’utilisation
• Durant la conception des classes, nous allons
expliciter les opérations complexes, dont la
plupart sont issues des cas d’utilisation

• Pour commencer, dressez la liste des

responsabilités d’un cas d’utilisation ou d’une
opération
– Une responsabilité est quelque chose qu’un objet sait
ou qu’il doit faire
 Exemple du GAB
• L’un des cas d’utilisation du GAB est exécuter
une transaction
– Une Transaction est un ensemble de MiseAJour et que
la logique varie selon qu’il s’agit d’un retrait, d’un
dépôt ou d’un transfert

– Transfert et retrait vérifient toutes deux que le compte

source dispose de fonds suffisants
• Une conception raisonnable fusionnerait ces comportements et
ne les développerait qu’une seule fois
 Concevoir les algorithmes
• Formulez maintenant un algorithme pour
chaque opération

• La spécification de l’analyse énonce le

quoi, ce que chaque opération fait pour ses
clients, mais l’algorithme montre comment
elle est réalisée
Étapes de conception des algorithmes

• La conception des algorithmes comprend les

étapes suivantes:
– Choisir des algorithmes qui minimisent le coût de
l’implémentation des opérations
– Sélectionner les structures de données appropriées aux
algorithmes
– Définir de nouvelles classes et opérations internes
lorsque c’est nécessaire
– Affecter les opérations aux classes appropriées
 Vue d’ensemble de la conception
des classes EntréeSur
Transaction
1
*
dateHeure
1
StationDEntrée *
MiseAJour
Transaction montant
Transaction Distance type
*
Caissier *
GAB Reçu
StationCaissier SaisiePar
*
enregistrerTransaction
espècesDisponibles 1
0..1 AutoriséePar
vérifierCarteBancaire 1 Caissier 1
vérifierMontant CarteBancaire AutorisationCarte
codeStation nom codeSecret
distribuerBillets 0..1
numéroSérie
recevoirFonds Banque * 1
limite
ajouterCompte
0..1 nom Émet
vérifierCodeSecret 0..1
supprimerCompte
1
créerCompteEpargne Emploie fermer
code
créerCompteChèque
Compte *
1
*
Station solde
code créerAutCarteBancaire code limiteCrédit Client
Consortium Banque 0..1 vérifierMontant Employé 1 nom
1
code type adresse
code fermer
vérifierCarteBancaire Compte vérifierMontant montantTemp
Carte getMontant
1 débiter
1 0..1 getCompte
créditer *
 Plan

• Analyse
• Conception
• Implémentation
 Plan
• Modélisation de l’implémentation

• Langages orientés objets

• Bases de données
 Optimisation des classes
• L’objectif de l’implémentation est de mettre
en œuvre les modèles issus de l’analyse et
de la conception

• Il est parfois utile d’optiminiser les classes

avant d’écrire le code, afin de simplifier le
développement ou d’améliorer les
performances
 Possibilités d’optimisation
• Partitionner une classe
• Fusionner des classes
• Partitionner / fusionner des attributs
• Promouvoir un attribut en classe /
rétrograder une classe en attribut
 Exemple du GAB
• Nous pourrions souhaiter scinder AdresseClient
en plusieurs classes pour préremplir des données

• Par exemple, nous pourrions précharger les

données de ville, département et codePostal pour
faciliter la gestion du service clientèle lors de la
création d’un nouvel enregistrement de Client
Promotion d’un attribut en classes
Personne Personne Adresse
nom * 0..1 rue
nom
numéroDeTéléphone ville
numéroDeTéléphone
adresse département
codePostal

Adresse Ville *
Personne
rue nomDeVille
nom * 0..1 * 0..1
*
numéroDeTéléphone
* * 1
0..1 Département
nomDeDépartement
1
0..1
CodePostal *
codePostal
*
 Optimisation des généralisations

• De même que vous reconsidérez les classes,

vous pouvez reconsidérer les
généralisations
– Il est parfois utile de supprimer une
généralisation ou d’en ajouter une avant de
coder
 Exemple du GAB
• Nous pouvons maintenant considérer
l’application GAB et celle du guichet tenu
par le caissier
– Nous supprimons les informations sur le
caissier du modèle de classes du domaine
Mise en œuvre des associations
• Les associations sont le « ciment » de notre
modèle de classes et fournissent les
chemins d’accès entre les objets
Associations unidirectionnelles
• Si une association est traversée dans une seule
direction, vous pouvez l’implémenter sous forme
de pointeur – un attribut contenant une référence à
un objet

• Dans la pratique, il peut s’agir:

– d’un pointeur ou d’une référence, selon le langage de
programmation choisi
– ou même d’une clé étrangère dans une base de données
Implémentation d’une association
unidirectionnelle
travaillePour
Modèle de classes: Personne Société
* 1

Personne Société
Implémentation:
employeur
 Associations bidirectionnelles
• Il existe trois approches pour les
implémenter:
– Implémentation unidirectionnelle
• Implémenter les associations unidirectionnelles sous
la forme de pointeur dans une seule direction et
effectuer une recherche lorsque la traversée dans le
sens opposé est nécessaire
Associations bidirectionnelles
– Implémentation bidirectionnelle
• Implémenter les associations bidirectionnelles par
des pointeurs dans les deux directions

Personne Société
employeur employés

Ensemble
Associations bidirectionnelles
– Implémentation avec un objet-association
• Cela consiste à implémenter les associations
bidirectionnelles par des objets-associations
distincts, indépendants de toute classe
:Personne travaillePour :Société

:Personne

:Personne

:Personne
:Société
:Personne
 Associations complexes
• Classes-associations
• Transformer l’association en classe
• Association ordonnées
• Utiliser un ensemble ordonné de pointeurs
• Séquences
• Comme pour une association ordonnée, mais avec une liste de
pointeurs
• Bags
• Comme pour une association ordonnée, mais avec un tableau
de pointeurs
 Associations complexes
• Associations qualifiées
• Implémenter comme un objet-dictionnaire
• Associations n-aires
• Promouvoir l’association en classe
• Agrégation
• Traiter l’agrégation comme une association ordinaire
• Composition
• Vous pouvez traiter la composition comme une association
ordinaire. Vous aurez besoin d’un peu de code supplémentaire
pour appliquer la dépendance de la partie de l’assemblage
 Plan
• Modélisation de l’implémentation

• Langages orientés objets

• Bases de données
 Modèle abrégé du GAB
Banque code délivre 1 * CarteBancaire
nom Carte 0..1
AutorisatioCarte
vérifierCodeSecret 1 numéroDeSérie
codeSecret 0..1
créerCompteEpargne limite
créerCompteChèque carteActive
ajouterCompte
créerAutCarteBancaire Compte supprimerCompte
vérifierMontant fermer
solde
codeCompte
limiteCrédit
Client
* *
nom
1
fermer * 1 adresse
0..1 vérifierMontant montantTemp
enregistrer getSolde
* 1
0..1 compteActif getCompte

0..1
CompteChèques CompteEpargne
0..1 SessionGAB
autorisationDeDécouvert taux
heureDébutSession
Implémentation de la structure
• La première étape de l’implémentation d’une
conception OO consiste à mettre en œuvre la
structure spécifiée par le modèle de classes

• Les tâches suivantes doivent être réalisées:

– Implémenter les types de données;
– Implémenter les classes;
– Implémenter le contrôle d’accès;
– Implémenter les généralisations;
– Implémenter les associations
 Types de données
• Si vous n’avez pas encore affecté les types
de données aux attributs, il est temps de le
faire maintenant

• Certains types de données méritent une

attention particulière
 Types primitifs
• Les nombres à virgule flottante, les entiers, les
caractères et les booléens peuvent exprimer des
valeurs simples

• Lorsque c’est possible, employez des valeurs

numériques plutôt que des chaînes de caractères
• Elles permettent une meilleure efficacité du point de vue de
l’espace mémoire et du traitement et facilitent la maintenance
de l’intégrité des attributs
 Types objet
• Vous pouvez utiliser des objets pour
regrouper et organiser des valeurs d’attribut
en types plus riches

• Les structures de C++ ne sont pas

techniquement différentes des classes,
hormis le fait que tous les membres sont
publics par défaut
 Types objet en C++
struct adresse {
string rue;
string ville;
string departement;
adresse() : rue(«  »), ville(«  »), departement(«  ») {}
};
class Client {
string nom;
adresse adr; //attribut objet
float montantTemp;
public:
//…
string ville() { return adr.ville; } // utilise la délégation
};
 Types objet en Java
class Adresse {
String rue=«  »;
String ville=«  »;
String departement= «  »;
};
public class Client {
private String nom;
// notez la construction explicite de l’attribut
private Adresse adr = new Adresse(); // attribut objet
private float montantTemp;
//…
String ville() { return adr.ville; } // utilise la délégation
};
 Types références
• Vous pouvez employer des références
d’objets en Java, et des références et des
pointeurs en C++ pour implémenter les
associations
 Classes
• Vous devez déclarer chaque attribut et chaque méthode
d’un modèle de classe dans la classe C++ ou Java
correspondante

• Il est également nécessaire d’ajouter les attributs et les

méthodes destinés à l’implémentation des associations

• Une classe doit définir des méthodes publiques pour les

services que les clients peuvent requérir ou invoquer
 Exemple du GAB
• Pour l’étude de cas du GAB, nous placerions chacune des
classes dans un fichier séparé

• Par exemple, le fichier source Banque.java contiendrait:

package infoBanque;
public class Banque {…}

Et le fichier Client.java contiendrait:

package infoBanque;
public class Client {…}
 Exemple du GAB
• Les fichiers Banque.java, Client.java, et ceux des autres
classes du package infoBanque doivent se situer dans un
répertoire nommé infoBanque

• Pour que Banque et Client soient visibles de la classe

SessionGAB, qui ne fait pas partie du package infoBanque,
le fichier source SessionGAB.java doit débuter par:
import infoBanque;
public class SessionGAB {…}

L’instruction import permet à l’implémentation de SessionGAB de

voir et d’utiliser les méthodes publiques des classes publiques
situées dans le package infoBanque
 Héritage en Java
• L’implémentation de l’héritage est réalisée par le mot-clé
extends
class Compte {
private float solde;
public void Enregistrer(float montant) {..}
public float Solde() {return solde;}
}
class CompteEpargne extends Compte {
private float taux; // ajout de l’attribut taux d’intérêt
float CalculInterets() {
// calcul des intérêts dûs non payés
}
}
Associations unidirectionnelles

Personne Société
employeur

Si nous n’avons pas besoin de retrouver la collection des

employés d’une société, un pointeur de Personne vers
Société s’avérera suffisant

En Java, la classe Personne peut simplement contenir un champ

de type Société
Associations unidirectionnelles
public class Societe {}
public class Personne {
private Societe employeur;
…
}
 Associations bidirectionnelles
• Les associations bidirectionnelles entraînent
la maintenance des liens pour les deux
extrémités de l’association

• Par exemple, si un client peut avoir

plusieurs comptes et qu’on veuille être en
mesure de naviguer dans les deux directions
de l’association
 Associations bidirectionnelles
public class Compte {
private Client client; // l’extrémité un de un-a-plusieurs
…
}

Import java.util.*; // pour pouvoir accéder à la classe HashSet

public class Client {
// liste de références de comptes
private HashSet comptes = new HashSet();
…
}
 Implémentation des fonctionnalités

• Pour chaque classe, spécifiez la signature

des méthodes (nom de la méthode,
paramètres, type de retour)

• Des méthodes peuvent aussi résulter

d’attribuer dérivés, du modèle d’états et du
modèle d’interactions
 Plan
• Modélisation de l’implémentation

• Langages orientés objets

• Bases de données
 Implémentation du schéma de bases
de données: concepts de base
• Il est facile de traduire le modèle de classes
en code SQL

• De nombreux outils en sont capables, mais

vous devez néanmoins connaître les règles
 Implémentation des classes
Table Client

Client
IDclient nom montantTempo
nom
montantTempo

getMontant
getCompte
 Implémentation des associations
Compte AutorisationCarte
* * codeSecret
solde
limiteCrédit limite

Table Compte Table AutorisationCarte

IDcompte solde limiteCrédit IDautorissation codeSecret limite

Carte

Table Compte_ AutorisationCarte

IDcompte IDautorissationCarte
(référence Compte) (référence AutorissationCarte)
 Implémentation des associations
AutorisationCarte CarteBancaire
1 *
codeSecret numéroDeSérie
limite

Table CarteBancaire

IDcarteBancaire numéroDeSérie IDautorisationCarte

(référence
AutorisationCarte)
 Implémentation des associations
Client Adresse
1 0..1
nom adresse
montantTempo

Table Adresse

IDadresse Adresse IDclient

(référence Client)
 Implémentation des associations
Banque codeCompte Compte
1 0..1 solde
nom
limiteCrédit

Table Banque

IDbanque nom

Table Compte

IDcompte Solde limiteCrédit IDbanque codeCompte

 Généralisation
Compte
solde
limiteCrédit

CompteChèques CompteEpargne

autorisationDeDécouvert

Tables: - Compte
- CompteChèques
- CompteEpargne