Professional Documents
Culture Documents
Académie Internet
Support de cours
mnkenlif@yahoo.fr
« Le logiciel est l'ensemble des programmes, procédés et règles, et éventuellement de la documentation, relatifs au
fonctionnement d'un ensemble de traitements de l'information' » (arrêté du 22 déc. 1981)
Un logiciel pourra donc être considéré comme un ensemble de programmes informatiques (codes sources, éditables,
exécutables) mais également les données qu’ils utilisent et les différents documents se rapportant à ces programmes et
nécessaires à leur installation, utilisation, développement et maintenance : spécifications, schémas conceptuels, jeux de
tests, mode d'emploi, etc.
1.2 Crises :
• Malgré les évolutions citées plus haut, on note que au fur et à mesure que les coûts du matériel diminuent, les
coûts des programmes informatiques (curieusement) augmentent !
La diminution des coûts du matériel (hardware) a conduit à associer l’ordinateur à de plus en plus de produits. Les
coûts des logiciels connaissent une très forte croissance, dominant maintenant le coût du matériel et peuvent
représenter plus de 80 % du coût total d’un système informatique. (ex coût de la mémoire économisée).
• A la fin des années 70, on ne sait pas « faire » des logiciels (plusieurs tentatives de logiciels vont échouer)
- Les besoins et contraintes de l’utilisateur ne sont pas respectés (pas de facilité d’emploi, interfaces
homme/machine inexistantes)
- Les coûts ne sont pas maîtrisés
- On relève régulièrement des retards dans la livraison des produits (non maîtrise du temps)
- On note une grande rigidité dans les solutions mises en place
- Quelque fois on arrive à des incohérences pendant l’utilisation
- On est aussi confronté au manque de performance et de robustesse (fiabilité)
- Les codes sont difficiles à maintenir
- On arrive parfois à des logiciels non utilisables
Le génie logiciel est basé sur des méthodologies et des outils qui permettent de formaliser et même d'automatiser
partiellement la production de logiciels, mais il est également basé sur des concepts plus informels, et demande des
capacités de communication, d'interprétation et d'anticipation. De fait, la « crise du logiciel » n'est pas complètement
résolue aujourd’hui. Le génie logiciel reste un « art »' qui demande de la part de l'informaticien une bonne formation
aux différentes techniques (le savoir), mais également un certain entrainement et de l'expérience (le savoir faire).
Codage
Test
Mise au point
Faisabilité
Analyse des -> spécification / cahier des charges
besoins
Conception du -> plan de tests
produit
Conception
Détaillée
documents de fonctionnement -> Codage
Intégration
Exploitation et
maintenance
Analyse Installation
des besoins et test du
de
Faisabilité ----------------------------------------------------------------------------------> système
Conformité/complétion/Correction
Spécifications --------------------------------------------------------> Acceptation
Conception ------------------------------> Intégration
architecturale et tests
Conception --------> Tests
détaillé unitaires
Programmation
Codage
Figure 3. Modèle en V
Dans le modèle en cascade, chaque spécification faite aux étapes de gauche doit correspondre à une procédure de
test (jeu de test à décrire) pour s’assurer que le composant correspond à la description faite aux étapes de droite.
Identification
des incréments
Spécification
-----------
des incréments
| Codage des
| incrémets
| Evaluation des
| incréments
| |
-------------------------------------------------
1.6 Méthodes
Dans l’Ingénierie d’un système logiciel, on retrouve les méthodes et outils servant tout au long du processus de
développement.
On peut y retrouver au moins 4 types de méthodes :
• Méhodes de planification stratégique du développement des systèmes applicatifs.
Il s’agira de définir un processus décisionnel en se basant sur :
- Une politique informatique (mission ? objectifs ? règles ?)
- Une stratégie informatique (projets ? budgets ?)
- Une tactique informatique (faire plus avec moins)
- Une action informatique (exploitation courante)
• Méthodes de développement proprement dit.
- Spécification des besoins
- Conception générale et détaillée
- Réalisation
- Installation : mise en exploitation, gestion des versions, apprentissage, suivi de fonctionnement et
d’utilisation
- Maintenance
• Méthode de conduite des projets.
Il s’agit d’estimer les moyens prévisionnels, les délais et les coûts
- planification
- évaluation des charges, coûts et moyens
- animation et conduite des travaux lors des étapes du cycle de développement
- choix des méthodes à utiliser
- contrôle d’avancement et d’exécution de tâches
- organisation générale du projet
- gestion des relations contractuelles avec les utilisateurs
- définition des profils des participants au projet
- gestion et formalisation des dossiers
- gestion des relations contractuelles avec les fournisseurs
- suivi analytique des projets
• Méthodes d’assurance qualité
D’après l’AFNOR, c’est « l’attitude du produit à satisfaire les besoins (exprimés) des utilisateurs.
Comment peut-on obtenir la qualité ?
- Définir clairement des exigences de sortie
- Mesurer la conformité à chaque phase
Cela implique 4 grands temps :
- Définition du processus et orientation de l’action qualité
o Diagnostic de la non qualité : problèmes, causes, poids, coûts, gain attendu de son
éradication
o Manuel qualité (spécifique au logiciel à réaliser)
o Plan qualité : politique, priorotés, action, budgets, plannings, stratégies de conduite
(pourrait servir pour n’importe quelle entreprise)
o Fonction qualité
1.7 La Spécification
La phase la plus délicate dans le processus de développement du logiciel, c’est celle des spécification.
Bertrand Meyer [Meyer 90] a défini les 7 pièges qui guettent lors d’un procéssus de spécification, mais également les 7
mots clés de réussite.
1.7.1 Les 7 péchés :
- Bruit : élément qui n’apporte aucune information (!) / redondance (!)
- Silence : caractéristique d’un problème auquel ne correspond aucune partie du texte
- Surspécification : lorsqu’on se lance dans un développement qui donne des détails inutiles (par exemple
anticiper sur les tables de la BD…)
- Contradiction : dans les séquences de spécification
- Ambiguités : une phrase peut avoir 2 ou plusieurs sens
- Référence en avant : étant à une page, vous faites allusion à un concept qui sera présenté plus loin
- Vœu pieux : attention à des éléments non vérifiables (!)
1.7.2 Les 7 caractéristiques d’une bonne spécification :
- Conformité (aux besoins réel et non aux besoins supposés exprimés, souvent limités)
- Communicable
- Faisable
- Modifiables
- Validable
- Complète
- Cohérente
1.7.3 Les méthodes
Lors de la phase de spécification, nous avons besoin au départ d’interviews bien faites, pouvant déboucher sur une
bonne documentation.
Les méthodes de spécification de logiciels seront de trois catégories :
- Informelle (structurée)
- Semi-formelle
- Formelle (mathématique)
Les méthodes de spécification intègrent :
- Modèle
- Démarche
- Langage
- Outils
• Méthodes Informelles
Elles n’ont pas un formalisme supportant une vérification, une validation (informatique ou simulation mathématique)
Cas de SADT (dans son approche fonctionnelle), BOOCH (dans son approche objet initiale), MERISE…
• Méthodes Semi-formelles
Elles permettent des vérifications, mais pas sur tous les apspects.
Cas de SADT avec SART, Réseaux de Petri, E/A avec langages … (entité association)
• Méthodes Formelles
Elles intègrent des langages permettant de définir toutes les contraintes et de garantir les vérification et la validation
complète. Ces langages basés sur les mathématiques vont pouvoir prendre en compte n’imorte quel concept abstrait ou
logique. Les outils sont :
- Automates
- Logique (temprelle, modale)
- Algebre (algebre universelle, algebre de processus)
- Mixte
Un exemple : VDM (Vienna Description Method) : il utilise la théorie des ensembles pour décrire les entités et les
objets ; mais aussi les formules de la logique de prédicats pour spécifier les propriétés (classes, etc.)
• Approche Objet
Les données et les fonctions sont encapsulées dans les mêmes « boites » qui dialoguent entre elles (les objets) par
envoi de messages.
Exemples: Booch, HOOD, OOA, OMT, UP, etc.
• Approche Modèles
Voir MDE (Model Driven Ingineering) plus loin.
• Approche Agiles
Voir méthodes Agiles plus loin.
Dans tous les cas, lors de votre démarche éssayez toujours de prendre en compte :
- Un maximum de modèles de besoins
- Des modèles d’analyse suffisants
- Une représentation des processus (fonctions + données)
- Des modèles de contrôle suffisants
- Une lisibilité claire du dictionnaire de données
- Une bonne illustration des entrées et sorties (éventuellement les temps de réponse)
• Dans une approche orientée objet par exemple, il est préférable de décrire les méthodes de test en même
temps que les autres méthodes de la classe, et les encapsuler directement, en indiquant les valeurs attendues à
chaque fois.
• Autres Recommandations :
- Les méthodes de test ne doivent pas être longues et doivent être au mieux simplifiées. Elles doivent être bien
commentées.
- Les jeux de tests doivent être définis clairement et justifiés
- N’hésitez pas à effectuer certains tests au fur et à mesure de la mise en œuvre
- Certaines méthodes doivent illustrer clairement les modes d’utilisation des autres méthodes jugées importantes
- En cas de nécessité, faire appel à des générateurs (aléatoires…) de tests et contrôle de tests automatiques (exi.
JTests, assert etc.)
L'abscence d'une forme structurée de tests engendre notamment les problématiques suivantes :
Le code source n'est pas testé en profondeur : cela a pour conséquence des aléas de « post-publication », plus ou
moins critiques. Le plus souvent il s'agit d'instabilités dans l'application ou des problèmes de sécurité classiques.
[Grossglauser07]
Le processus qui vous est proposé ci-dessus fait abstraction des contraintes liées à la gestion de projet (cahier des
charges, organisation interne, etc.) ainsi que de la phase d'analyse. Il est basé sur le développement piloté par les tests
(TDD) et s'adresse particulièrement aux développeurs PHP autonomes.
Si vous développez en équipe, la base restera sensiblement la même mais vous devrez fournir des précisions au niveau
de l'organisation et du partage des tâches, notamment.
Le développement piloté par les tests (Test-Driven Development, ou TDD) est une méthode de développement mettant
les tests unitaires au premier plan, on peut résumer son processus en cinq étapes :
1 Ajouter un test,
2 vérifier qu'il ne passe pas,
3 implémenter la fonctionnalité,
4 exécuter les tests unitaires - déboguer en cas d'échec,
5 refactoriser le code source - exécuter à nouveau les tests unitaires, passer à l'objectif suivant...
En reprenant le processus ci-dessus, vous observerez que l'approche TDD débute dès la phase de conception.
Dans l'idéal, la structure de votre application devrait être modélisée dans un éditeur UML puis son squelette généré
directement dans des fichiers PHP.
Exercice 1 : Qu’est ce qui d’après vous pourait faire en en sorte qu’on ne maîtrise pas la fabrication du
logiciel ? donner des exemples concrets.
Exercice 2 : Proposer un plan qualité pouvant permettre de contrôler les phases du cycle de développement
de logiciels dans une structure.
2.1 Introduction
Des méthodologies développées permettent de modéliser des systèmes à risques, pour contribuer à l'intégration de la
Sécurité Opérationnelle dans la phase d'analyse et de spécification des « systèmes automatisés ». Il s’agit de SADT et
Réseaux de Petri (RdP).
- L'approche systémique, hiérarchique et structurée du SADT, est généralement bien adaptée pour représenter au
mieux les connaissances structurelles et fonctionnelles du système étudié.
- Le formalisme des RdP, adapté à la prise en compte des problèmes de concurrence, de synchronisme et de
parallélisme, constitue un excellent outil de spécification fonctionnelle d'un problème et de mise en évidence
des contraintes. Les propriétés mathématiques qui découlent de l'analyse des RdP permettent une étude
comportementale et structurelle essentielle à la validation d'une spécification.
2.2.1 Description
Le Réseau de Pétri (RDP) décrit « mathématiquement » des systèmes grâce une représentation graphique dont les arcs
et les nœuds sont valués avec des marquages.
Il offre la possibilité de parallélisme, synchronisation, concurrence, exclusion, etc.
Un RdP a des propriétés intrinsèques (dépendant ou non du marquage de départ) comme les branches mortes
(inaccessibles), cycles, etc.
Les places Pi et les transitions Ti d'un réseau de Petri, en nombre fini et non nul, sont reliées par des arcs orientés. Un
réseau de Petri est dit graphe biparti alterné , c'est à dire qu'il y a alternance des types de noeuds : tout arc, qui doit
obligatoirement avoir un noeud à chacune de ses extrémités, relie soit une place à une transition soit une transition à une
place.
Pour définir l'état d'un système modélisé par un réseau de Petri, il est nécessaire de compléter le réseau de Petri par un
marquage. Ce marquage consiste à disposer un nombre entier (positif ou nul) de marques ou jetons dans chaque place
du réseau de Petri. Le nombre de jetons contenus dans une place Pi sera noté mi. Le marquage du réseau sera alors
défini par le vecteur M = {mi}.
[KaiserCottet01]
L'évolution de l'état du réseau de Petri correspond à une évolution du marquage. Les jetons, qui matérialisent l'état du
réseau à un instant donné, peuvent passer d'une place à l'autre par franchissementiou tir d'une transition. Dans le cas
des réseaux dits à arcs simples ou de poids 1, la régle d'évolution s'énonce de la manière suivante :
[KaiserCottet01]
Un RdP peut être décrit entièrement avec les matrices d’incidences (ou caractéristiques) U- y U+ et un « marquage ».
Les “jetons” ont généralement une interprétation semantique qui designe un changement d’état dû au franchissement
de la transition.
Les interfaces avec l’extérieur” se matérialisent par des transitions sans place.
Il existe de nombreux développements et alternatives : les réseaux temporisés, colorés, continus… hybrides etc.
NB : Les formlismes tels que « Grafcet » et « MERISE » (MCT) se sont à la base inspirés des réseaux de Petri.
NB : si une transition est validée, cela n'implique pas qu'elle sera immédiatement franchie. Ces règles introduisent en
effet un certain indéterminisme dans l'évolution des réseaux de Petri, puisque ceux-ci peuvent passer par différents états
dont l'apparition est conditionnée par le choix des transitions tirées. Ce fonctionnement représente assez bien les
situations réelles où il n'y a pas de priorité dans la succession des événements.
[KaiserCottet01]
Remarque : cette représentation permet de déterminer certaines propriétés d'un graphe. Par exemple si le graphe
présente une zone non bouclée, cette partie du marquage une fois atteinte constitue un arrêt de l'évolution du RdP et
celui-ci sera déclaré avec blocage.
2.3.1 Présentation
SADT est une méthode graphique établie par Douglas T. ROSS (Softech) vers 1974. Parallèlement, le programme
ICAM (Integrated Computer-Aided Manufacturing 1972) de l'US air force en commanda une définition domaine
publique nommée IDEF0 (1975).
ICAM établit ensuite d'autres modèles pour les aspects informationnels (IDEF1) et dynamiques (IDEF2).
SADT reste encore plus répandu que SA/RT, qui lui est à présent préférée pour une meilleure prise en compte des
aspects dynamiques.
SADT part du constat selon lequel le monde est constitué de données et d’actions (comme c’est par exemple le cas avec
les noms et les verbes en Langage Naturel).
Un modèle SADT est une suite hiérarchisée de diagrammes : (datagrammes et actigrammes) obtenue par raffinements
successifs.
Chaque « boite » peut-être à nouveau décomposée en un diagramme plus détaillé (Zoom).
Au niveau général se trouve le diagramme de contexte (niveau –1), montrant les sources, les destinations.
Chaque diagramme est
- soit un diagramme fils analysant une partie du diagramme père,
- soit un diagramme père synthétisant les diagrammes enfants, soit les 2.
En fin de chaîne, un processus non décomposé est accompagné d’une mini spécification précisant comment sont
produites les sorties à partir des entrées.
Kit SADT :
- diagrammes d'activité
- conditions d'activités
- diagrammes de données
- diagrammes explicatifs (ou textes uniquement)
- liste hiérarchique des diagrammes
- glossaire
Un modèle est un ensemble de kits établis suivant différents points de vue, ou buts ou contextes (Point de vue de
l'utilisateur, du gestionnaire, de la maintenance de la production …)
2.3.3 SADT/IDEF0
Les diagrammes
Le diagramme de contexte représente le système avec ses entrées et ses sorties
entrée 1
sortie
entrée 2
SYSTEME
(e3)
mecanisme
c1
commande
entrée 2
fonction 1
e2
entrée 1
e1 e1a fonction 2
sortie
e1b fonction 3 s1
mecanisme
m1
Fonctions principales
A0
Les fonctions 1, 2, 3 peuvent faire l'objet d'une décomposition dans les diagrammes A1, A2, A3. Le diagramme A1
pouvant être décomposé en A11, A12, etc.
Chaque diagramme (ex : A0) peut comporter ou être annoté à l'aide de graphiques non formalisés (suffixe F, ex A0F1,
A0F2, etc), de textes libres (suffixe T, ex A0T1, ...), ou de glossaires (suffixe G, ex A0G1,...)
La fonction
e1
s
e2
Verbe
+ complément
Axx
m
Si une fonction est décomposée, le nom du diagramme fils est noté en bas à droite de la boîte.
Les flots
Les flots de données sont échangés entre les fonctions.
commandes
sorties
entrées
Fonction
Axx
mécanismes
Suivant le coté de connexion avec la boîte, ils ont un des quatre rôles suivants :
• Entrées : Ce sont les « entités » nécessaires à la fonction transformées par elle en « sorties ».
• Commandes : Ce sont les entités qui commandent le déroulement interne de la fonction (au moins une
commande est obligatoire)
• Sorties : Ce sont les « entités » produites par la « fonction ».
• Mécanismes : Ce sont les « entités » nécessaires à la réalisation mécanique de la « fonction » (machines,
personnels, etc)
Plusieurs flèches peuvent être connectées. Les flots peuvent être décomposés ou composés.
Une flèche en provenance de l'extérieur du diagramme comprend en plus de son nom un code (e/s/c/m) suivi de son
numéro d'ordre par rapport à la boîte.
Un nom de flot entouré de parenthèse (e3) n'est pas retrouvé dans le diagramme enfant. (IDEF0)
Certaines conventions permettent de simplifier la représentation en utilisant des flèches à double sens.
commandes
écriture lecture
Donnée
Les datagrammes utilisent le même formalisme que les actigrammes. Simplement chaque boîte symbolise une donnée
du système ou un fichier.
Le datagramme est construit indépendamment de l'actigramme, il n'en est pas la traduction inversée, ce qui pose un
problème de traçabilité. Les données en sont plus détaillées.
De même le processus de collection des informations, d'interview, de conduite de réunion est décrit.
2.3.4 LES EXTENSIONS IDEF1/IDEF2
L'ICAM n'a pas retenu les datagrammes de SADT. Deux autres modèles ont été définis pour ajouter les aspects
informationnels et dynamiques à celui fonctionnel des actigrammes de SADT/IDEF0.
ATTRIBUTS
1:M
M:N 1:1
ATTRIBUTS ATTRIBUTS
ATTRIBUTS
NOM CLASSE ENTITE
NOM CLASSE ENTITE NOM CLASSE ENTITE
M:1
ATTRIBUTS
Facility Diagrams
Cet outil est un éditeur graphique doté d'un ensemble de symboles permettant de réaliser des diagrammes explicatifs
non liés directement à la méthode.
2.4 Conclusion
Pour une application à caractère distribué, les réseaux de Petri, de par leur fonctionnement asynchrone, s’imposeront
assez naturellement, sauf si les traitements de données constituent l’essentiel des opérations à modéliser. En effet,
l’interaction avec des données est bien prise en compte par le modèle « réseau de Petri à objets », mais si la structure de
contrôle est quasi inexistante, alors elle constituera plutôt une gêne qu’un avantage. Il faut s’orienter dans ces conditions
vers des modèles basés sur les flux de données (SADT, SA-RT). Un critère important qui peut conduire au choix des
réseaux de Petri est le besoin de pouvoir établir des preuves formelles de propriétés (vivacité ou atteignabilité par
exemple) devant absolument être satisfaites par l’application. La représentation formelle est alors un support de la plus
grande importance.
3.1 Introduction
Deux types de motivation orientent actuellement les concepteurs dans le choix des méthodes de conception: la
possibilité de prendre en compte des applications et des systèmes de plus en plus complexes
[Gardarin97][Leray92][Zoller97] et le soucis de diminuer les coûts de réalisation et de maintenance. Avec l’ère des
nouvelles technologies, des réseaux informatiques et systèmes répartis, les applications ont atteint elles aussi un niveau
de complexité croissant et de ce fait, elles nécessitent à l’heure actuelle, des outils de programmation sophistiqués. On
constate que les applications dites technique, telles que la CAO, la cartographie, les systèmes de contrôle temps réel, le
CoDesign, représentent une activité croissante et nécessitent une plus grande participation des personnes aussi bien pour
l'effort de conception et validation que de maintenance et d'évolution.
Ces constats ont mis en évidence la nécessité de promouvoir l’abstraction de données, la modularité et la réutilisabilité
[Manhes98] des composants fabriqués.
Ainsi, beaucoup de méthodes ont vu le jour, chacune tentant à sa manière d’apporter une solution satisfaisante et parmi
elles, les méthodes objets (orientées objet) et leurs techniques d’analyse et de conception appropriées.
Exemple:
Objet (instance)
. Classe VOITURE .
-immatriculation
Démarrer () - marque
Rouler () -…
Stopper ()
Les principes énoncés plus haut offrent des qualités pour mettre en œuvre des méthodes rigoureuses. Ainsi, on doit
retrouver dans une approche objet au moins 4 principes obligatoires: abstraction, encapsulation, modularité, hiérarchie ;
auxquels on peut ajouter 3 principes complémentaires : typage, simultanéité, persistance.
Abstraction ( ≡ définition d’une classe)
Elle fait ressortir les caractéristiques essentielles d’un objet (qui le distinguent de tous les autres) et donc procure
des frontières conceptuelles vigoureusement définies du point de vue de l’observateur (utilisateur).
Identification classes
et objets
Le formalisme UML 2.0 est composé de 13 types de diagrammes (9 en UML 1.3). UML n'étant pas une méthode, leur
utilisation est laissée à l'appréciation de chacun, même si le diagramme de classes est généralement considéré comme
l'élément central d'UML. De même, on peut se contenter de modéliser seulement partiellement un système, par exemple
certaines parties critiques.
Nom de l'association
de communication
La façon de décrire le contenu d’un cas d’utilisation varie énormément et UML ne souhaite pas imposer une norme.
Vous pouvez par exemple ajouter une ligne de précondition (ce qui doit être VRAI au début du cas d’utilisation).
Un format simple pour capturer un cas d’utilisation consiste à décrire le scénario de base sous forme d’étapes
numérotées et les variantes de cette séquence, comme ci-dessous (une application de commerce électronique).
ACHAT :
1. Le client parcourt le catalogue et sélectionne les produits qu’il souhaite acheter
2. Le client valide ses choix
3. Le client fournit les informations concernant la livraison (adresse, livraison en 24 heures ou 3 jours)
4. Le système affiche les éléments de facturation et les informations concernant la livraison
5. Le client fournit les informations concernant sa carte de crédit
6. Le système valide la transaction
7. Le système confirme la transaction immédiatement
8. Le système expédie un Email de confirmation au client
Alternative : Echec de l’autorisation
A l’étape 6, la transaction n’est pas validée par le système
Autoriser le client à saisir à nouveau les informations concernant sa carte de crédit et réessayer
Alternative : Client régulier
3a. Le système affiche les informations associées à ce client concernant la livraison, les critères de tarification, et les
quatre derniers chiffres de son numéro de carte de crédit
3b. Le client peut accepter ou modifier les valeurs affichées
Retourner au scénario principal de l’étape 6
La quantité de détails dont vous avez besoin dépend du risque que présente le cas d’utilisation. Plus le risque est
important, plus vous devez détailler.
Un acteur est un rôle que l’utilisateur joue par rapport au système. Les acteurs réalisent les cas d’utilisation. Un seul
acteur peut réaliser plusieurs cas et, inversement, un cas peut avoir plusieurs acteurs.
Simuler
Convertir Fonction
Vitesse
Include
Use
Stabilité Include
Use Afficher
Résoudre équations Include solutions
précision
Include
Use
Include
Erreur
Figure 21 Diagramme
ActVenSys de cas d’utilisation de la simulation des systèmes continus
TranDirSys Include
Tracer courbes
Envoyer
Système externe
(séquentiel)
[Nkenlif04]
[Fowler03]
SYSTEM
SEQUENTIEL
0 .. *
Est décrit par
1
(package)
RECVENSYS
GRAFCET
RECEPTIVITE LOGIQUE
RECEPTIVITE TEMPORELLE
Appartient à
RECEPTIVITE
1 .. * GRAFCET
Conditionne
1 .. * 1 .. *
0 .. 1
0 .. 1
1 .. *
1 ETAPE
TRANSITION
1 .. * 0 .. *
0 .. *
MACRO-ACTION
Décrit
ACTDIRSYS
LIEN SELECTIF
ACTION DETAILLEE
LIEN PARALLELE
[Nkenlif04]
Figure 25. Un exemple de Diagramme de classes : cas des systèmes séquentiels automatiques et interactions
Visibilité de Classe
Agrégation et composition
L’agrégation est la relation « est une partie de », comme le moteur et les roues sont des parties d’une voiture.
Cependant, UML offre une variété d’agrégation plus forte, nommée composition. Dans la composition, l’objet
« partie » ne peut appartenir qu’à un seul « tout ». De plus, on suppose généralement que les parties sont créées et
meurent avec le tout (la destruction du tout se propage en cascade à ses parties).
Du point de vue des spécifications, cette association qualifiée impliquerait une interface telle que la suivante :
class Commande
{
public LigneCommande getLigne (Produit unProduit) ;
public void ajouterLigne (Nombre montant, Produit unProduit) ;
…
}
Ainsi, tout accès à une ligne donnée nécessite un Produit comme argument. Une multiplicité de 1 indiquerait qu’il doit y
avoir une ligne pour chaque Produit, et une multiplicité de * que l’on peut avoir plusieurs Lignes de Commande par
Produit, mais que l’accès aux lignes est toujours indexé par Produit.
Du point de vue implémentation, cela suggère l’emploi du tableau associatif ou d’une structure de données similaire
class Commande
{
private Map _lignes ;
…
}
Emploi
Période : IntervalleDate
Opération ( )
Une autre façon de représenter cette information consiste à faire de Emploi une classe à part entière. Les multiplicités
doivent être modifiées en conséquence.
Dans ce cas, chacune des classes de l’association d’origine a un rôle monovalué par rapport à la classe Emploi. Le rôle
« employeur » est maintenant dérivé, bien qu’il ne soit pas indispensable de le représenter.
Employeur
Emploi
* 0..1
1 0..1 Période : IntervalleDate * 1
Personne Entreprise
Opération ( )
[Fowler03]
Classe paramétrables
Ce concept permet de définir des comportements pour des ensembles, en général en créant une classe patron Set.
Plusieurs langages de programmation, particulièrement C++, utilisent la notion de classe paramétrable (« template »)
ou de patron (« pattern »).
class Set <T>
{
void inserer (T nouvelElemnt) ;
void supprimer (T unElement) ;
…
}
Cela fait, vous pouvez utiliser la définition de la classe paramétrable Set pour créer des classes dérivées afin de
mémoriser des éléments spécifiques.
Ser <Employe> employeSet ;
Voici le formalisme de representation d’une classe paramétrable en UML:
Set T
Paramètre de
Période : IntervalleDate Classe Paramétrable
Inserer ( )
Supprimer ( )
Le T du diagramme est un paramètre substituable qui représente le type (vous pouvez avoir plusieurs paramètres).
NB : Ce concept est inutile dans des langages à typage faible comme Smaltalk, puisque la question ne se pose pas.
visibilité
Il est possible d’étiqueter tout attribut ou opération par un indicateur de visibilité. Vous employez n’importe quel
marqueur, sa signification dépendant du langage. Mais UML fournit trois abréviations : + (public), - (private) et #
(protected).
L’exemple suivant montre l’utilisation du langage OCL. La contrainte que nous voulons exprimer est la suivante :
« une charge de véhicule ne doit pas excéder la charge maximale supportable par celui-ci.
Vehicule Typeehicule
NumImmatriculation Nom
Kilometrage ChargeMax
Charge est de type Volume
EstLibre Hauteur / Largeur
* 1 VitesseMaxVide
VitesseMaxCharge
OCL définit plusieurs types de collections d’objets, ainsi que de nombreuses opérations de manipulation de ces
collections. « Set » est un ensemble au sens mathématique. L’expression « Colis.anomalieColis » retourne l’ensemble
des objets AnomalieColis liés à l’objet Colis concerné. L’opération prédéfinie permet de tester si l’ensemble est vide.
A propos de OCL
OCL est un langage formel d’expression de contraintes adapté aux diagrammes d’UML (depuis la version 1.1
d’UML), et en particulier au diagramme de classes. Il permet de spécifier des contraintes sur l’état d’un objet ou d’un
ensemble d’objets, avec une grammaire élémentaire et accessible (OCL peut être interprété par des outils). OCL limite
les ambiguités du langage naturel (bien que lui étant proche), et se rapproché bien du langage technique (langage
mathématique, informatique…)
Exemple de contrainte :
– invariants sur des classes ;
– préconditions et des postconditions à l’exécution d’opérations :
– préconditions doivent être vérifiées avant l’exécution,
– postconditions doivent être vérifiées après l’exécution ;
– gardes sur des transitions de diagrammes d’états-transitions ou des messages de diagrammes d’interaction ;
– ensembles d’objets destinataires pour un envoi de message ;
– attributs dérivés, etc.
Diagramme d’état-transition
• Les diagrammes d'état-transition permettent de décrire les changements d'états d'un objet ou d'un composant,
en réponse aux interactions avec d'autres objets/composants ou avec des acteurs.
• Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des valeurs des
attributs d'un objet.
• Une transition représente le passage instantané d'un état vers un autre.
• Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement qui
conditionne la transition.
• Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas l'événement qui les déclenche.
• En plus de spécifier un événement précis, il est aussi possible de conditionner une transition, à l'aide de
"gardes" : il s'agit d'expressions booléennes, exprimées en langage naturel (et encadrées de crochets).
Double cliquer
Cliquer sur “ étape ” Sélectionner type d’action
Saisie paramètres de l’action
[Nkenlif04]
Figure 36. Un exemple de Diagramme d’états – transitions ( classe ETAPE d’un système séquentiel)
Activité 1
Débranchement
Activité 3 Activité 4
[Garde : si oui]
[Sinon] Jonction
Fusion
Activité 6
Ecrire
[Nkenlif04]
Figure 39 Séquencement d’opérations entre les macro-objets d’un système hybride (l’ascenseur)
simuler
1. paramètres
Polynôme
Equation différentielle
3.Résolution()
2. résoudre
2. paramètres
8. solutions
solutions
Fonction de transfert
Perform
Rep_lib
1. convertir ()
Consigne
4. matrice ()
5. fonction()
9.
10
6. réponsef ()
Diagramme de communication :
[Fowler03]
Nom de parquetage 1
La maîtrise d'un projet informatique peut nécessiter un savoir de plus en plus vaste dans différents domaines (logiciels,
langage(s), code, APIs, ...).
Nous allons présenter le Développement Orienté Modèle (MDD - Model Driven Development, ou MDE - Model
Driven Enginering), tel qu’il est spécifié par l’OMG (Object Management Group). Ces spécifications sont regroupées
sous le concept de MDA (Model Driven Archtecture), et mettent à disposition de nombreux outils conceptuels.
4.1 Évolutions
L’OMG (Object Management Group) est un consortium développant et promouvant la théorie et la pratique des objets
distribués. Il est constitué de plus de 1000 structures membres. Il a proposé dès le début des années 90, l’architecture
OMA (Object Management Architecture), qui comprend des produit et standards/documents qui définissent les
mécanismes d’interopérabilité, de distribution et de communication dans un réseau. Les standards de réalisation étant
CORBA (Common Object Request Brokers Architecture), UML (Unified Modeling Language), MOF (Meta Object
Facilities et XMI (XML Metadata Interchange).
MDA (Model Driven Architecture) est une extension de OMA pour faire évoluer et généraliser cette interopérabilité le
long de tout le cycle de vie du logiciel (conception, déploiement, maintenance).
L’idée principale ici est d’arriver à la séparation entre les spécifications des fonctionnalités et la caractérisation de ces
fonctionnalités pour une plateforme spécifique.
Modèles : ils représentent une partie d’une fonction, de structure ou de comportement d’un système. Ils sont composés
d’une syntaxe (forme définie) et d’une sémantique (signification). On distingue les modèles indépendants de la plate-
forme (PIM, Platform Independant Model) et les modèles dépendants de la plateforme (PSM, Platform Specific Model).
Abstraction : représente le fait de supprimer les détails non pertinents d’un modèle. Le rafinement consiste à
introduire dans un modèle abstrait quelques éléments de réalisation de cette abstraction. Un modèle est toujours
construit selon une vue particulière du systèeme.
Plateforme : elle est constituée des détails technologiques non pertinents pour les fonctionnalités d’un composant
logiciel.
Figure 45. Evolution des approches du Génie Logiciel sur le plan historique
● Au niveau de la modélisation
● Diagrammes de classes
● Abstraction
● Fonctionnalités, systèmes, etc.
● Classes du programme final
● Intégration des « design patterns »
L’idée de MDE c’est de concevoir un paradigme paliant aux insuffisances du paradigme Objet, qui s’est imposées en génie logiciel
depuis les années 1980. Ce paradigme n’est pas ammené à remplacer l’approche Objet, mais à la compléter.
• L’approche UML et le développement Objet considère que « Tout est Objet ». Les relations fondamentales qui y sont
mises en oeuvre sont l’héritage (d’une super-classe par une classe simple) et l’instanciation (d’une classe par un objet).
- Modélisation
- Représentation des classes, etc.
- Possibilité de génération de code
- Statique
• L’approche MDE considère elle que « Tout est modèle ». Les relations fondamentales sont la représentation (du système
par le modèle), et la conformité (du modèle à un méta-modèle).
- Méta-modélisation
- Représentation de l'application
- A différents niveaux d'abstraction : système, fonction, classe
- Dissociation des aspects indépendants
- Interaction utilisateur-système, architecture, plate-forme, etc
● La méta-programmation
● Manipulation du programme
- Au niveau code
- Interface de manipulation (autorisant l’ajout de méthodes, d'attributs)
● Avant la métamodélisation, cette étape préalable s’appuie sur une interface de base pour réaliser le
métaprogramme.
Les modèles créés (PIM) sont associés à des modèles de plate-forme (PM), et transformés, pour obtenir un modèle
d'application spécifique à la pate-forme (PSM).
En général, la réalisation de modèles spécifiques de domaines consiste à créer un « langage » permettant de mieux
appréhender un problème. A ce niveau, on peut distinguer deux approches :
- Création de toutes pièce d’un langage conforme aux spécifications MOF
- Création d’un profil UML particulier (Un profil, proposition d’une communauté, regroupe un ensemble d’éléments
(composants, stéréotypes, icônes, propriétés…) qui s’appliquent à un contexte particulier tout en conservant le métamodèle
d’UML intact.).
Il faut noter que l’intégration de MDA dans l’industrie logicielle exige forcément d’adopter une nouvelle logique
économique.
La mise en place d’Usines Logicielles, telle que envisagée, s’accompagnerait d’une modularisation possible des
logiciels, qui sont disponibles non plus en tant qu’entités monobloc, mais en tant qu’ensemble de composants
assemblables, éventuellement proposés par des entreprises différentes.
• Les Chalenges :
- Définition précise de la frontière entre PIM et PSM
- Méthodologie MDA (stratégique)
- Explicitation des transformations (UML vers EJB, UML vers WS, …)
On retrouve deux types de transformations : « modèle à modèle », et « modèles à code »
- Outillage
• XMI
XMI est un format standard de représentation de modèles UML. Il est basé sur XML. Ce format est utilisé
par les éditeurs UML pour réaliser les imports / exports de modèle d'un outil vers un autre outil.
L'OMG n'a pas jugé utile de standardiser un processus associé à ces outils. Leur rôle est de répondre aux besoins des
utilisateurs de manière générique, et non de proposer de solutions définitives pour certains types d'applications précises.
En terme de produits, MDA est implémenté dans un outil qui intègre la modélisation et le développement. Il gère des
classes servant les objets métiers, leur présentation et leur persistance.
PIM
PSM
CODE
L’intégration des Design Patterns (patron) dans MDE est effective aujourd’hui.
● Modèles pré-existants
- Déjà validés
- Facilitent la modélisation
● Manipulation simple des modèles
- Réutilisation
- modifications
[Parrend07]
[Parrend07]
[Parrend07]
● Plateforme Eclipse: incluant Eclipse, EMF (Eclipse Modeling Framework), SDO (Service Data Objects) et
XSD (XML Schema Infoset Model).
SDO permet d'unifier l'accès à des données hétérogènes, par exemple stockés sous forme XML, en Base de
Données Relationnelle, dans des Services Web, par les applications. XSD est une librairie qui permet de
manipuler, créer et modifier des schémas XML.
Pour créer un modèle EMF (au format « Ecore »), plusieurs formats de fichiers sont supportés :
1 Java Annoté
2 XML Schéma
3 Format Rational Rose
● Poseidon :
nous listons ci-dessous les différentes transformations réalisées dans un processus intégrant l’outil Poseidon :
* Création de modèles UML,
* Ajout des commentaires Javadoc dans le modèle UML,
* Sauvegarde de votre modèle,
* Exportation en tant que Classe Java (les diagrammes de classes sont exportés, les autres existent uniquement à fin de
documentation),
* Exportation sous format XMI,
* Exportation en tant que graphique (si besoin),
* Lancement de la plate-forme Eclipse, et importation du fichier XMI créé.
* Réalisation de programme exécutable
Une méthodologie de référence est véritablement nécessaire pour rendre MDA réellement opérationnel.
Nous présentons ci-dessous, une méthode de développement d'application correspondante. Elle a pour vocation
d'améliorer la productivité, c'est à dire le temps de création de la première version de l'application, de même que
l'évolutivité, c'est à dire la possibilité d'améliorer et d'étendre cette application.
* Prototype
Réalisation d'une architecture comportant les fonctionnalités minimales (IHM et fonctionnalités clés) selon la
méthode linéaire.
* Architecture complète
Intégration des différents principes de fonctionnement : type de client (lourd/léger), support de mobilité, etc., selon
la méthode linéaire.
On obtient un squelette d'application, comportant tous ses éléments, mais sans implémentation.
* Mise en place des fonctionnalités
Compléter chaque fonctionnalité l'une après l'autre, selon la méthode linéaire.
* Récursivité
Les étapes 2, 3 peuvent être réalisés par suite d'affinements successifs. Chaque affinement doit permettre de
nouveaux types d'usage (extension des fonctionnalités), les version intermédiaires doivent être exploitables.
* Validation de la version finale
* Evolutions
Elles peuvent se faire selon le même principe que les affinements succesifs ayant conduit à la version complète du
produit.
La capitalisation des modèles, et leur exploitation performante suppose une vision macroscopique des éléments
disponibles. L’approche Méga-modèle semble très prometteuse, mais aucune implémentation n’est disponible librement
actuellement.
Comme intérêt, on peut noter la capitalisation des modèles et de leurs liens avec les autres éléments mis en oeuvre dans
le processus de développement.
4.11 Conclusion
De nombreux outils sont disponibles pour la manipulation de modèles, et progressivement, des modèles existent pour
les principaux domaines d’application de MDA. Pour les domaines connexes, il est possible de créer des langages
spécifiques de domaine relativement facilement.
Cependant, l’aspect de réutilisation, de capitalisation et de mise à disposition des modèles - c’est à dire à un passage, de
fait, à un niveau d’abstraction supérieur - reste mal aisé. [Bezivin04] propose un framework de gestion des modèles et
de leurs relations basé sur les Mégamodèles.
L’intégration de MDA dans l’industrie logicielle rend possible, voire nécessite, l’adoption de nouvelles logiques
économiques. La mise en place d’Usines Logicielles, présentées plus haut, s’accompagne d’une modularisation possible
des logiciels, qui sont disponibles non plus en tant qu’entités monobloc, mais en tant qu’ensemble de composants
assemblables, éventuellement proposés par des entreprises différentes. Cette modification dans la conception même du
logiciel permet l’apparition de chaîne de fournisseurs, et donc d’améliorer la productivité et la compétitivité d’une
industrie encore peu mature [Greenfield03].
Les projets informatiques possèdent de plus en plus des aspects très complexes. Ceci est du à plusieurs facteurs :
- la "taille" du projet,
- la "complexité" du système étudié (comportement, structure),
- « l'hétérogénéité » du projet (plusieurs systèmes d'exploitation, intégration de bases de données, systèmes en
réseaux, ...).
- ...
Ces facteurs sont en quelque sorte intrinsèques aux projets et participent d'une "manière fixe" à la complexité perçue.
Pourtant, cette dernière est aussi d'essence subjective dépendant directement du "savoir" et de la compétence du modélisateur
Du fait de la densification des moyens et des outils mis à disposition, la maîtrise d'un projet informatique peut nécessiter un
savoir de plus en plus vaste dans différents domaines (logiciels, langage(s), code, APIs, ...) .
• 2- Priorité aux applications fonctionnelles opérationnelles par rapport à une documentation pléthorique
• On privilégie le code testé
Les processus lourds génèrent une documentation exhaustive avec tous ses inconvénients : ambiguïté du
langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Ces documents ne sont qu'une
illusion d'avancement du projet.
Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui
fonctionne. La documentation n'est qu'un support concret qui aide à produire le logiciel.
Figure 59. Histogramme de mise en perspective des méthodes agiles, RUP et RAD
Les méthodes agiles privillégient le développement à itération courte (XP, Scrum, Lean ...)
La « modélisation agile » est promue par Scott Ambler [Scott02], qui adapte les valeurs de XP à la modélisation.
Les mots clés de la modélisation agile sont :
· Communication
· Simplicity
· Feedback
· Courage
· Humility
Les clés d’une modélisation réussie consistent à promouvoir une communication efficace entre tous les participants du
projet, de se forcer à développer la solution la plus simple possible qui satisfasse tous les besoins, à obtenir des retours
rapides et fréquents, à avoir le courage de prendre des décisions et à s’y tenir, et à avoir l’humilité de reconnaître qu’on
ne sait pas tout et que les autres ont une valeur à apporter à ses propres efforts.
Les méthodes Agiles sont conçues pour s’adapter au changement. A partir des valeurs fondamentales décrites au
paragraphe précédent, ont été déterminés treize principes clés décrits dans le « Manifeste Agile ». Nous les listons ci-
dessous :
[Scott02]
[Schwaber04]
[Craig03]
[MANTEL07]
Le processus schématisé à droite illustre une organisation lean, dans laquelle le client « tire » les fonctionnalités de la
première cellule, plutôt que de les pousser dans la chaîne de production et d’attendre qu’elles soient réalisées. Le TDR
est donc l’aboutissement d’une démarche de changement de ses pratiques vers un processus lean.
Dans cette organisation, le codage devient en pratique la dernière activité d’ingénierie logiciel avant la livraison. Il faut
quand même compter quelques ajustements au cours de ces différentes étapes, car le codage peut mettre en lumière des
faiblesses dans les exigences ou dans la conception. Ces faiblesses sont adressées en réajustant les tests fonctionnels et
unitaires.
Une telle organisation ne peut être supportée qu’avec les outils adéquats. FIT se révèle trop limité pour répondre
totalement à ce besoin, notamment sur l’aspect TDR. Il faut disposer d’outils permettant une meilleure collaboration
des différents acteurs du processus, et une structuration plus contextuelle de l’information. La forme du wiki paraît
idéale pour répondre à cet objectif en permettant une structuration et une contextualisation efficace de l’information,
ainsi qu’une facilité de mise à jour.
De la précision du modèle dépend la profondeur des tests que l’on peut générer. L’approche impose donc un fort
investissement dans les activités de modélisation. Elle a du sens pour les organisations déjà matures sur cet aspect pour
qui l’apprentissage sera modéré.
5.5 Conclusion :
Les méthodes agiles ont désormais fait leurs preuves, aussi bien sur des projets aux délais très serrés que sur des projets
d'enjeux stratégiques. Ces méthodologies ont fait l'objet de différentes formalisations, adaptées à différents concepts,
l'un des plus répandus étant certainement SCRUM. Même les méthodologies visant les grands projets, comme RUP
(Rational Unified Process), y ont puisé largement.
Toutefois, les méthodes agiles bien que répondant à une demande et à des besoins réels, ont besoin d’une meilleure
normalisation, et d’un peu plus d’éléments d’assurance qualité.
Le mouvement agile va certainement apporter quelque chose aux entreprises. Cependant, sans en comprendre les
principes fondamentaux, on ne peut avoir de gain sérieux.
Nous avons déjà vu au chapitre 1 que dans l’Ingénierie des systèmes logiciels, on retrouve des méthodes et surtout
plusieurs outils servant tout au long du processus de développement.
• La couche de présentation contient les composants qui doivent interagir avec l'utilisateur de l'application, comme
les pages Web, les formulaires, ainsi que tout ce qui régit le comportement de l'interface utilisateur.
• La couche métier intègre les fonctionnalités et les traitements propres à l'application. Les fonctionnalités simples
peuvent être implémentées avec des composants sans états, alors que les transactions complexes et longues peuvent
utiliser des composants d'ordonnancement avec états. Les composants métier sont généralement dissimulés derrière
une sous-couche d'interface de service qui agit comme une façade afin de dissimuler la complexité de
l'implémentation. Cela participe de ce que l'on appelle communément une architecture orientée par les services (SOA
= « Service-Oriented Architecture »).
• La couche d'accès aux données fournit une interface simple pour accéder aux données et les manipuler. Les
composants de cette couche abstraient la sémantique de la couche de données sous-jacente, permettant ainsi à la
couche métier de ce concentrer sur la logique applicative. Chaque composant fournit typiquement des méthodes pour
créer, lire, mettre à jour et effacer (CRUD = « Create, Read, Update, Delete ») des entités de données.
• La couche de stockage des données comprend l'ensemble des sources de données de l'application d'entreprise. Les
deux types les plus communs de sources de données sont les bases de données et les systèmes de fichiers.
Note 1: on fait souvent face à des compromis car ces facteurs sont souvent contradictoires (e.g. Java est de haut-
niveau, de haute puissance expressive, sécuritaire et (en principe) portable, mais pas très performant)
Note 2: parfois il est possible d'écrire un programme en utilisant plus qu'un langage, ce qui permet d'utiliser le
langage le plus approprié pour chaque partie. (Exemple : intégration C->Pascal, Assembleur->C …)
Les AGL apportent une réelle solution à certains problèmes du génie logiciel et contribuent nettement à l'amélioration
de la productivité et de la qualité du logiciel, notamment en faisant le suivi des différentes phases du processus logiciel
et en offrant un cadre cohérent et uniforme de production. Néanmoins, cet enthousiasme doit être modéré: le processus
logiciel est encore loin d'être maîtrisé et les différentes formalisations qui en sont proposées font encore l'objet de
controverses, et dans tous les cas, sont bien loin d'être totalement automatisables. L'informaticien a encore de belles
années de travail devant lui avant d'être supplanté par des AGL...
Certains environnement, plus évolués, sont dédiés à un langage particulier. Il existe par exemple des environnements
dédiés à InterLisp, Smalltalk, Loops (l'environnement Loops fonctionne sur une machine dédiée à Loops), Oz... Ces
différents environnements proposent des bibliothèques de composants, une interface graphique, des éditeurs dédiés au
langage, des interprètes, debuggers, ... Ces environnements permettent un développement rapide et convivial. En
revanche, l'application développée est intégrée dans (et généralement inséparable de) l'environnement, ce qui peut poser
des problèmes de portabilité et de coût. Enfin, il existe des générateurs d'environnements de programmation : Mentor,
Gandalf, Synthesizer Generator, ... A partir de la description formelle d'un langage (à l'aide de grammaires attribuées,
de la logique), ces différents systèmes génèrent un environnement de programmation dédié au langage, contenant un
éditeur dédié au langage, un pretty-printer, un debugger, un interpréteur, ...
Base de données
SE (Système d’Exploitation)
Outils
Concept.
Outils Outils
Program. Gestion d’objet spécifiques
BD
Noyau Outils
Outils
d’édition gestion
auto.
Outils Interface
d’accès publique
6.6 Intérêt de la qualité d'un logiciel, et de son contrôle à l’aide des outils appropriés
[Linsolas09]
plusieurs solutions performantes existent pour le contrôle de la qualité du logiciel.
Mais rappelons ce que c’est que la qualité d'un logiciel, et en quoi est-il important de la contrôler !
En paraphrasant Wikipédia, la gestion de la qualité est l'ensemble des activités qui concourent à l'obtention de la
qualité dans un cadre de production de biens ou de services (dans notre cas, d'un logiciel informatique). Plus
largement, c'est aussi un moyen que se donnent certaines organisations, dans des buts tels que la mise en conformité
par rapport aux standards du marché.
Dans le monde informatique en général, et en Java en particulier, la qualité d'une application va être directement liée à
la qualité du code. De nombreux outils s'affairent à contrôler certains aspects de cette qualité du code : exécution de
tests unitaires, analyse de la couverture du code par ces tests, vérifications du respect des règles de codage, etc. Il est
donc possible de contrôler la qualité de son code grâce à ces outils, et d'avoir une confiance accrue en son application !
Le contrôle de la qualité va donc pousser l'équipe de développement à adopter et à respecter certains standards de
développement. Le but de tout cela étant bien entendu de rendre le code plus sûr, mais de permettre d'y déceler les
erreurs le plus rapidement possible... et donc de les corriger !
Le "Toyota Way" correspond à une méthodologie extrêmement appréciée aujourd'hui, aussi appelée le "Lean". Celle-ci
est basée sur 14 principes dont l'un d'eux est le "Build a culture of stopping to fix problems, to get quality right the
first time". Ce principe est là pour nous rappeler qu'il est impossible d'accélérer et de soutenir une fréquence de
production sans que la qualité soit au coeur de toutes les actions. Autrement dit, il n'est pas possible d'aller vite sans
qualité, mais qu'il n'est pas possible non plus de faire de la qualité sans vitesse. C'est aussi pour cela qu'il est aujourd'hui
primordial de disposer d'une intégration continue et d'un processus itératif et incrémental.
[Linsolas09]
Figure 68. Le coût de correction d’une erreur croit exponentiellement avec le temps
Comme le rappelle Tom DeMarco, "You can't control what you can't measure", "On ne peut contrôler ce que l'on ne
mesure pas"... D'où l'importance d'utiliser un outil de qualité tels que « Sonar » (voir plus loin dans le chpitre).
6.7 Les « processwares » :
Les processware ou Intergiciel, sont des progiciels d’interconnexion entre applications.
Un processware est une application qui fournit les traitements de gestion entre différents progiciels.
6.8 Choix de l’outil de développement :
Le choix d’un outil de développement répond à plusieurs types d’interrogations.
Le premier groupe de questions est centré sur une analyse fine du projet à réaliser et sa faisabilité.
- disposons nous de ressources techniques et du temps nécessaires en interne ou devons nous passer par un
prestataire extérieur ?
- qui sera le chef de projet et comment se fera le suivi ?
- quelle est la composition de l’équipe opérationnelle envisagée ?
Le second groupe concerne les spécificité techniques du langage lui même :
- quel est le niveau de portabilité du langage (outils) ?
- permet – il de développer des applications client-serveur ?
- quel sera le supports technique offert ?
Note : Un logiciel est évalué selon des critères relatifs à la qualité de traduction d’éléments d’un diagramme de classes :
- associations
- classes-associations
- agrégations
- contraintes inter-relations
- héritage
- rétro-conception d’une base de données.
Suivant l’approche de réalisation de logiciels MDA (Model Driven Architecture), les objectifs des outils sont de
permettre de modéliser un système dans un modèle PIM (Platform Independent Model) en utilisant un langage de
spécifications approprié, puis de pouvoir traduire dans un ou plusieurs PSM (Platform Specific Model) réalisant ainsi
l’implémentation concrète du système. Quand le domaine d’implémentation se cantonne aux bases de données, UML
peut être utilisé comme modèle PIM, alors que SQL le sera au niveau du PSM.
Depuis plus de 35 ans, la conception des BD était réalisée à l’aide du modèle entité-association. La notation UML qui
s’impose dans bien des domaines de l’informatique s’adapte de mieux en mieux aux bases de données. Le premier pas a
été réalisé par Rational Rose avec son profil UML (UML profile for Data Modeling). Ce profil permet de décrire des
bases de données notamment à l’aide de stéréotypes prédéfinis (Table, RelationalTable, View, etc.).
[Arbogast06]
• Couche de présentation : AndroMDA offre actuellement un choix entre deux technologies pour implémenter des
couches de présentation web : Struts (plus d'infos ici et là, ou encore ici) et JSF (« JavaServer Faces » - framework
de programmation Java). Il accepte en entrée des diagrammes d'activité UML pour spécifier les enchaînements de
pages, et génère des composants pour les frameworks Struts ou JSF.
Remarques :
- Puisque AndroMDA est totalement modulaire, il est fondamentalement extensible et il y a de très nombreuses possibilités
d'ajout de modules qui génèreront une implémentation pour des technologies propres à votre environnement. l'équipe
d'AndroMDA a créé récemment une nouvelle initiative pour coordonner et encourager la création de modules
additionnels. Sachez par exemple qu'un effort important est en cours pour finaliser une pile de modules pour .NET, qui
devrait à terme vous permettre de générer à votre convenance une application Java et/ou .NET à partir des mêmes
modèles.
- Contrairement à certains générateurs de code classiques, AndroMDA ne se contente pas de générer des fichiers de
classes Java : il génère également les fichiers de configuration XML traditionnellement nécessaires dans la plupart des
frameworks Java, comme les fichiers de mapping d'Hibernate, les fichiers de description de beans de Spring ou encore
les fichiers de configuration d'Axis. En fait, ce qui est intéressant, c'est qu'alors même que vous n'avez pas encore bouché
les trous d'implémentation, simplement avec votre modèle, AndroMDA génère une application qui compile et peut déjà
être déployée sans erreur dans un serveur d'applications ! Bien sûr il manque des fonctionnalités, mais toute
l'infrastructure est prête.
Principales fonctionnalités
Nous listons ici les principales fonctionnalités de l'outil Sonar.
• Tableau de bord complet des différents projets suivis.
• Détection rapide du code à risque.
• Mesures quantitatives : nombre de classes, duplication de code, etc...
• Mesures qualitatives : couverture et taux de réussite des tests, complexité du code, respect des règles de codage...
• Historiques des statistiques, pour en voir l'évolution au cours du temps.
• Support de plus de 600 règles de qualité (suivant la norme ISO 9126-3).
6.10.3 Utilitaires :
• L'utilitaire de ligne de commande : phpunit est le principal outil dédié à la configuration et à l'exécution des
tests unitaires. Cet utilitaire est optimisé pour les systèmes Unix/Linux. Mais, il peut également fonctionner
sous Windows. La liste des commandes est disponible en tapant :
phpunit --help
• Indicateur de résultat : Un indicateur de résultat est fourni pour chaque méthode de test exécutée :
Tiré de [Grossglauser07]
Indicateur Description
. Le test passe.
F Le test a échoué (Failure).
E Le test a généré une erreur PHP.
S Le test est ignoré (Skipped).
I Le test est marqué comme incomplet (Incomplete).
Deux outils permettent aujourd’hui de combiner wiki et moteur de tests : Fitnesse et Greenpepper.
• Fitnesse (http://fitnesse.org/) est un outil libre qui utilise une version modifiée de FIT comme moteur de tests
et permet de décrire ses tests dans un wiki. Il nécessite par contre de déployer le code source sur un serveur
pour pouvoir exécuter ses tests. C’est un bon outil pour l’étape TDR et tests de recette, mais n’est pas suffisant
pour supporter une approche compréhensive du TDR jusqu’au code.
Environnement utilisateur HP
Environnement de View [OSF / Motif] New Ware
développement de Outils de gestion
logiciels APPLICATIONS
(Soft bench) et du réseau
Plateforme
Client ou Serveur [NIST, ECNA, C++] Services d’objets répartis
(distribuive Smaltalk de HP)
O.S.
Finalement, DOC est à cheval entre RPC procédural et RPC orienté objet (ORB). Mais, il se rapproche beaucoup
plus de l’ORB à cause des composantes (outils) C++, Smaltalk, DOMF, etc.
Note : Motif est une interface graphique utilisateur normalisée pour le système Unix (comme Windows l’était pour le
DOS initialement).
• L’outil de travail collaboratif : Visual Studio Team Foundation Server, arrivé avec Visual Studio 2005. Il permet de définir des
priorités sur des tâches, d'avoir une gestion des sources, etc.
Logiciels libres
• ATL open source : transformations de modèles vers ou depuis UML (etc.) ; ATL est un langage de type QVT (le standard
QVT définit un ensemble de langages permettant d exprimer des transformations de modèles à modèles).
• Dia
• Umbrello un modeleur UML sous GPL. Ne fonctionne pas correctement sous Windows ;
• ArgoUml un modeleur UML sous Licence BSD ;
• Gaphor un modeleur UML sous GPL la version actuelle est 0.7.1 ;;
• BOUML, un modeleur UML sous GPL pour Windows, Linux, MacOS X et Solaris;
• Eclipse GMT-XUML
• Eclipse UML2, Méta modèle UML2, sans interface graphique.
• Netbeans 5.5
• Staruml, en version libre.
• Acceleo, générateur de code source à partir de modèles UML.
Logiciels propriétaires
• Rational Rose : Un des outil les plus important du marché - http://www.rational.com / Racheté par IBM
• Together (rachété par Borland/Inprise) : Outil fortement couplé avec Java : - http://www.togethersoft.com;
• ArgoUML : Outil Open Source; - http://argouml.tigris.org
• Visio : Outil non complet de microsoft ; - http://www.microsoft.com/office/visio
• Together, de Borland ;
• Poseidon, basé sur ArgoUml (version commerciale) ;
6.13 Les questions que l’on doit se poser lorsqu’on est face à un système ou un projet (par
exemple de type client-serveur)
Caractéristiques de l’Outil de Développement
Client / Interface graphique
Sous quels systèmes d’exploitation ou système de multifenêtrage l’outils fonctionne-t-il ?
utilisateur
Où réside l’outil – sur le serveur, sur le client ou sur les deux ?
Outil
Plusieurs développeurs peuvent-ils l’utiliser simultanément ?
Middleware / Système d’exploitation Si l’outil est réparti. Quels réseaux supporte-t-il ?
/ Protocoles Les liaisons sont-elles propriétaires ou utilisent-elle du middleware pour passer les données ?
Middleware / Accès à distance aux Si ces données sont utilisées pendant le développement. Comment y accède-t-on ?
bases de données Les chaînages multiples en parallèle sont-ils permis ?
L’outil peut-il être connecté à d’autres applications ?
Middleware / RPC / ORB Comment ?
Peut-il accéder aux bibliothèques de classes ? Comment ?
Si l’outil (ou les données qu’il utilise) est archivé sur un serveur, pour quelles plates-formes
Serveur / SGBD / Référentiel
matérielles est-il disponible ?
Un logiciel doit présenter les six caractéristiques qualité définies par la norme ISO 9126 qui est issue des approches
de B.BOEHM et Mc CALL. Il s’agit de (voir l’ouvrage [Schach 92]) :
- Capacité fonctionnelle : accueillir un ensemble de fonctions et de propriétés bien définies pour l’exécution de tâches
dans le respect de l’application des normes, des prescriptions, et peut fournir des résultats avec une certaine précision.
- Fiabilité : maintenir son niveau de service dans des conditions précises et pendant une longue période.
A titre d’exemple, le tableau ci-dessous récapitule certaines métriques de qualité effectuées pour le cas du logiciel
SAHY (voir [Nkenlif04]).
7.1.2 Pourquoi accorder de l’importance à l’ergonomie de son site et plus généralement de ses
applications ?
Quelque soit le domaine dans lequel vous intervenez, les vecteurs de communication que vous utiliserez seront aussi
importants, si ce n’est plus important que le fond même de votre intervention.
Petite notion de PNL (Programmation Neuro-Linguistique)
2- Formulation du 4-Réception du
message message
1- Concept 5- Concept
3- Mode de
transmission du
message
[Morlais 01]
En regardant la figure ci-dessus, dans toute communication, ce qui importe, ce n’est pas l’étape 1 mais bien finalement
l’étape 5 ! Les outils que l’on vous a donné lors des précédentes interventions permettent de passer de l’étape 2 à l’étape
3. Nous allons maintenant approfondir le passage de l’étape 3 à 4.
Dans certaines entreprises multinationales les taches sont séparées mais c’est loin d’être le cas de toutes les structures.
Vous aurez donc à faire l’étape 2 et 3 en prenant en compte les étapes 4 et 5.
Le rôle de l’ergonomie des interfaces utilisateurs est d’établir la communication entre l’outil et l’opérateur.
L’ergonomie conditionne ainsi l’acceptabilité du système par l’utilisateur, la facilité et l’efficacité d’utilisation, la
facilité d’apprentissage (ces différents points ne sont pas toujours compatibles).
Il est illusoire de croire à la possibilité de faire « une bonne interface » ou « un logiciel ergonomique » en faisant
l’impasse sur la connaissance des futurs utilisateurs et sur leur manière de travailler. Toute conception d’interface doit
donc placer l’utilisateur au centre de l’étude. Et il est capital de bien comprendre le mode de fonctionnement de
l’utilisateur, c’est la raison pour laquelle nous allons maintenant aborder un groupe de sciences sans lequel l’ergonomie
ne saurait exister : les sciences cognitives (la cognitique est d’abord reservée aux cigiticiens).
Gardez donc en mémoire les préalables à l’ergonomie et n’oubliez pas que la question de fond reste « comment
l’utilisateur va-t-il appréhender/comprendre l’outil ? » et non comment faire quelque chose de beau !
Quand on veut rendre un site accessible sur le Web, il est bien sur capital d’être bien référencé si on veux être visité.
Les termes que l’on choisit dans la définition de ses mots clefs sont déterminant.
Pour se faire référencer auprès des moteurs de recherche qui utilisent des petits robots fournisseurs, ils
utilisent les mots clefs suivants qui se trouve dans la balise du titre :
Ce texte est repris en totalité ou en partie par le moteur de recherche, mais il arrive aussi que ces derniers
utilisent l’intitulé noté dans les balises « title » de la page c’est à dire ici :
<TITLE>c-mescourses.com : Finies les commissions, faire mes courses de chez moi, se faire livrer €
domicile les produits alimentaires de consommation, packs d'eau, lait, conserves, couches.</TITLE>
Notons que la balise destinée aux robots précise la langue utilisée. Cela peut limiter le trafic généré puisque
le site ne répond pas à toutes les demandes dont la langue cible est précisée et n’est pas « français », mais
cela permet de mieux cibler l’internaute et de ne pas générer du trafic « non susceptible d’être client » qui
coûte chère en tuyau et en matériel le serveur devant pouvoir répondre à tout le monde en même temps.
(préciser si besoin). Notons que les accents ne sont pas utilisés dans les mots clés. (voir pour les autres sites)
Remarque : si le travail de l’utilisateur s’appuie sur un formulaire papier, et si ce formulaire est bien construit, faire en
sorte que la disposition des champs dans la fenêtre soit proche de la structure du formulaire.
Aligner verticalement les champs de saisie et/ou d’affichage avec leurs libellés ; la justification peut se faire de
trois manières :
- 1 : si les « libellés » sont de dimension sensiblement identique, justifier les champs et les libellés à gauche ;
- 2 : si les libellés sont de dimensions très variables, justifier ces libellés à droite et les champs à gauche ;
- 3 : il est également possible de disposer les libellés au dessus des « champs de saisie » ; il faut alors les justifier à
gauche.
Prénom : Ancienneté :
Age :
Nom : Profession :
Prénom : Profession du
conjoint :
Prénom : Profession :
[Morlais 01]
[Morlais 01]
Placer l’en-tête de groupe au dessus de la boîte de groupe, et en incrustation dans le cadre s’il y en a un.
Ne pas utiliser de boîte de groupe pour les boutons de commande.
Ne pas utiliser systématiquement des boîtes de groupe quand il y a un en-tête : trop de cadres peuvent gêner la
lisibilité globale de la fenêtre. Utiliser alors des en-têtes de groupe sans représenter une boîte de groupe.
Les colonnes doivent être séparées par un double espace (1 caractère blanc x 2). Si cela ne peut pas être fait
(par manque de place), séparer les colonnes par des traits (lignes verticales).
Comment organiser les éléments à l’intérieur d’un tableau/d’une liste (c’est-à-dire sur quoi se baser pour
établir la chronologie des données) ?
- adopter l’ordre respectant les habitudes de travail de l’utilisateur ;
- le cas échéant, utiliser l’ordre alphabétique ou numérique.
Lors de la création de listes d’éléments, on peut être confronté à des éléments de texte trop longs pour contenir
dans l’espace d’une ligne de la liste. Dans ce cas, supprimer des parties de texte dans le milieu du libellé et y
insérer des points de suspension, conservant ainsi le début et la fin du libellé de l’élément. Attention toutefois :
dans certains cas, il sera plus judicieux de conserver le début du libellé et de faire suivre ce dernier par des
points de suspension.
Repérer chaque champ, liste, tableau, colonne ou groupe de données par un libellé. On distingue trois grands
types de libellés :
- le libellé de champ, à utiliser pour identifier une donnée affichée ou à saisir ;
- l’en-tête de colonne, à utiliser pour identifier la colonne d’un tableau ou d’une liste ;
- l’en-tête de groupe, à utiliser pour identifier un ensemble de données rassemblées sous la forme d’un
groupe.
7.3.2.5 La typographie
Concernant la taille des caractères :
taille minimum : 8 points ; des caractères de plus petite taille sont quasiment illisibles ;
taille maximum : 16 points ; l’utilisation de caractères de plus grande taille gêne la lisibilité.
Choisir la police de caractères en fonction de critères de lisibilité (éviter l’italique).
Eviter d’utiliser plus de trois polices de caractères différentes dans une même fenêtre ou sur plusieurs fenêtres
affichées simultanément.
De manière générale, utiliser une seule police de caractères dans un champ. Toutefois, il est possible d’utiliser
des codages particuliers (police différente, couleur, italique, gras, souligné...) pour différencier certains textes
tels que des mots clès, des liens, des libellés de champs de saisie obligatoire, etc.
Pour tous les libellés (champs de saisie et champs d’affichage, option de menu, boutons d’option, titre, etc.)
utiliser une majuscule à l’initiale. Ne mettre donc en majuscule que la première lettre du premier mot du libellé
et aucun autre mot de ce libellé.
7.3.2.6 La couleur
La couleur peut être employée pour coder visuellement l’information : différenciation et identification des informations
affichées.
La couleur ne doit pas être le seul moyen utilisé pour communiquer de l’information et ne devrait pas être le
seul élément qui distingue deux objets ; il doit y avoir d’autres indicateurs (libellés, forme, disposition) ;
Quand le principe des onglets est utilisé, si ces derniers sont liés (dépendants), les boutons <OK> et <Annuler> doivent
être placés en dehors de l’onglet. Si les onglets sont indépendants, ces boutons doivent être placés sur chacun des
onglets : le bouton <Annuler> devient <Fermer> et la demande de confirmation devient facultative (<OK> facultatif).
Centrer les libellés des onglets et les afficher sur une seule ligne.
Aligner les languettes des onglets à gauche et les accoler les unes aux autres.
Comme nous avons put le constater ensemble, la bonne ergonomie de ses applications Web ne tient pas à grand
chose, il suffit de faire attention à un certain nombre de critères.
Notez tout de même que, la prise en compte de ces recommandations ne se substitue pas à la connaissance des
utilisateurs ni à la connaissance de leur travail ; elle ne remplace pas une analyse du travail, elle est simplement
complémentaire à un travail d’analyse de la cible. Ces recommandations sont particulièrement applicables pour les sites
Internet qui ne ciblent pas de public particulier.
Quand on élabore un Intranet ou une application spécifique, l’analyse du fonctionnement et du comportement des
utilisateurs peut amener à ne pas prendre en compte certaine recommandation, voir à faire le contraire !
Note : Les techniques présentées pourraient tout aussi s’appliquer à un projet de SIG.
Pour obtenir une certaine qualité, il est indispensable de toujours travailler en équipe. Toutes les compétences ne seront
jamais cumulées par la même personne. On pourra dans un projet 3D retrouver par exemple, au moins un graphiste
2D/3D, un programmeur, un architecte/designer, etc.
Normalement, le chef de projet qui aura comme tâche d'organiser le développement et d'affecter les tâches, sera choisi
parmi les plus expérimentés. Il devra fire en sorte que les différents intervenants du projet travaillent ensemble de
manière coordonnée et sans gaspiller trop d'énergie ; soit en faisant la même chose que l’autre, soit en recommençant ce
que l’autre a déjà fait, même si intéressant.
NB : Ces mesures doivent être accompagnées d'autres mesures élémentaires comme les conventions de nommage, ou
l'affectation des tâches et des délais...
Une conséquence supplémentaire de cette mesure c’est le fait de pouvoir créer des composants indépendants et donc
réutilisables (pouvant être réutilisés dans un autre projet pour gagner en temps).
[Arbogast06] Sébastien Arbogast, MDA par la pratique, Date de publication : 18 mai 2006. http://sarbogast.developpez.com/
[Bezivin04] Jean Bézivin, Frédéric Jouault et Patrick Valduriez, On the Need
for Megamodels Preliminary Draft, OOPSLA 2004.
[Craig03] Craig Larman, Agile and Iterative Development: A Manager's Guide, Addison Wesley, 2003
[Fowler03] Martin FOWLER, UML Distilled: A Brief Guide to the Standard Object Modeling Language, Paperback: 192 pages,
Publisher: Addison-Wesley Professional; 3 edition (September 19, 2003), Language: English, ISBN: 0321193687
http://martinfowler.com/books.html#uml
[Greenfield03] Jack Greenfield et Keith Short, Software Factories Assembling Applications with Patterns, Models, Frameworks and Tools,
OOPSLA, 2003.
[Grossglauser07] Jean-Pierre Grossglauser, Introduction aux tests unitaires avec PHPUnit 3.1
Dernière mise à jour : 15/08/2007, http://jp-grossglauser.developpez.com/tutoriels/langages/php/phpunit/
[KaiserCottet01] Claude Kaiser, LES RÉSEAUX DE PETRI, Reproduit avec la permission de Francis Cottet, ENSMA
[Lemasson] Guillaume Lemasson, Introduction au développement en équipe pour la 3D
Date de publication : 10/04/07, http://lemasson.developpez.com/
[Linsolas09] Romain Linsolas, Contrôler la qualité de ses projets avec Sonar, mise à jour : 13/08/2009,
http://linsolas.developpez.com/articles/sonar/
[MANTEL07] Gilles MANTEL, Test-Driven Requirements, octobre 07, Valtech Technology
[Meyer 90] B. Meyer, « Conception et programmation par objet, pour du logiciel de qualité » Inter éditions 1990.
[Morlais 01] Christian de la Morlais, Ergonomie des applications Web, Séminaire : DataWeb et NTIC, IUT FV de Bandjoun,
Département d’Informatique, 2001
[Nkenlif04] Marcellin Nkenlifack, Modélisation Objet et Développement d’un Atelier de Simulation des Automatismes Industriels
Hybrides, Thèse de Doctorat/PhD, ENSP, Univ Yaoundé1, Cameroun, 2004
[OMGWWW] www.omg.org (site Web de l’OMG contenant les spécifications sur le métamodèle UML et le processus MDE)
[Parrend07] Pierre Parrend, Introduction à MDA : Principe, Date de publication : 04/12/2006
http://pparrend.developpez.com/tutoriel/mda-intro/
[ROQUES07] Pascal ROQUES, UML est-il soluble dans les méthodes agiles ?, octobre 07, Valtech Training
[Schach 92] Stephen R. Schach, Practical Software Engineering, IRWIN, Boston, 1992
[Schwaber04] Ken Schwaber, Agile Project Management with Scrum, Microsoft Professional, 2004.
[Scott02] Scott Ambler , Agile Modeling: Effective Practices for Extreme Programming and the
Unified Process, Wiley, 2002.
Autres sources
• www.cui.unige.ch/ScDep/Cours/GenieLogiciel/index.html
• http://www.gpa.etsmtl.ca/cours/gpa77
• http://cui.unige.ch/ScDep/Cours/GenieLogiciel/
• http://www.cours.polymtl.ca/inf2300
- Jidoka : notion d’empêcher un maillon de la chaîne de passer une pièce défectueuse au maillon suivant. Si un défaut
est identifié sur un élément dans la chaine de production, on arrête immédiatement la chaîne, on répare le défaut, et on
s’assure qu’il ne se reproduira plus, on redémarre ensuite la chaîne de production. Les défauts peuvent provenir des
machines, des matières premières, de la formation du personnel, etc.
Pour plus de détails, le lecteur pourra consulter l’ouvrage référence en la matière : The Machine That Changed the
World : The Story of Lean Production, de Womack, Jones, et Roos.