MÉTHODOLOGIES
DE CONCEPTION
DES LOGICIELS
SCIENTIFIQUES
CHAPITRE IV
IV. Méthodologies de conception des logiciels
scientifiques
Introduction
La nécessité d?une présence humaine dans
la boucle de conduite et de surveillance des systèmes automatisés
impose de tenir compte des capacités spécifiques et
complémentaires de chacun des deux décideurs l?homme (aptitude
innée) et l?ordinateur (aptitude acquise).
La machine est capable d?exécuter des mesures et de
traiter des actions précises sur des environnements quelconques, ainsi
que de stocker des informations et de procéder à leurs
traitements rapides. Mais elle est impuissante pour élaborer une
stratégie, soit par manque de connaissance de l?environnement, soit par
manque d?algorithme rapide et performant de traitement des informations et de
prise de décision soit tout simplement par l?impuissance de la machine
par rapport à la nature.
L?homme est capable d?analyser les situations par une
extraction et une hiérarchisation subjectives des informations qui lui
facilitent des prises de décisions rapides, mais ses performances sont
variables et dépendent de son état physiologique (fatigue,
santé...) et psychologique (motivation...), et de sa connaissance de la
dynamique du système à piloter et de la complexité de la
tâche de surveillance et de conduite.
Si les limites de la machine sont bien cernées, en
général les causes de variabilité des performances
humaines sont complexes à identifier certaines n?étant pas
liées directement à la tâche. L?évaluation
ergonomique des postes de travail a pour but de recenser ces causes. Elle doit
s?appuyer sur une connaissance du comportement et des limitations des
opérateurs au travail, ainsi que sur les moyens d?évaluation de
leurs performances 1 .
Le développement d?une suite d?outils logiciels de
traitement de problèmes mathématiques relatifs à la
technologiques généralement ou le génie électrique
spécialement, vu que le développeur doit porter une très
grande attention afin de produire un outil utilisable avec toute la
diversité des tâches d?un technicien du domaine. Cette
dernière application doit surmonter des risques multiples; avec le
nombre grandissant des symboles (icônes) (ni beaucoup, ni peu) qui
peuvent composer l?interface utilisateur.
Très schématiquement, un système
homme/machine comprend trois sous-systèmes interconnectés :
· l?opérateur humain,
· la machine qu?il surveille, pilote ou commande,
· l?interface de communication entre les deux.
Suivant le degré d?automatisation de la machine, les
décisions peuvent être entièrement allouées à
l?opérateur ou réparties entre l?homme et le système de
commande de la machine. Les activités des opérateurs dans ces
sous-systèmes sont regroupées en quatre classes principales :
· les activités de perception qui concernent la
recherche et l?acquisition d?informations et l?identification de situations,
d?objets et d?actions,
· les activités mentales regroupant le traitement
des informations, la résolution de problèmes et la prise de
décision,
· les communications qui comprennent les demandes, les
réponses, les échanges d?informations avec le système
et/ou d?autres opérateurs,
· les activités motrices qui regroupent à la
fois les actions discrètes sur des touches, des boutonspoussoirs ou des
actionneurs et des actions continues d?ajustement, de régulation et de
poursuite.
|
|
Fig. IV : Modèle de résolution de
problème de RASMUSSEN 1
La persistance de la mémoire visuelle est de l?ordre de
100 ms, alors qu?elle est de l?ordre de 1500 ms pour la mémoire
auditive.
Fig. IV : Mécanisme de reconnaissance
de forme 1 .
Le cycle du processeur sensoriel «ts»
est de l?ordre de 100 ms et varie inversement à l?intensité du
stimulus. Ceci signifie qu?il faut en moyenne 100 ms pour qu?un stimulus soit
représenté en mémoire sensorielle (c?est-à-dire
pour que l?individu ait la sensation de percevoir) et que lorsque le stimulus
est intense, la sensation de perception se manifeste rapidement.
En conséquence, deux événements
sensoriels similaires survenant dans le même cycle sont combinés
en un seul événement mais la durée du cycle dépend
de l?intensité du stimulus (de 50 ms à 200 ms voire plus en
conditions extrêmes).
Les sections qui suivront, décriront plus en
détail les relations qui existent entre les systèmes à
explorer et les problèmes à élucider.
Systèmes et problèmes
a) Activités humaines articulées autour
des systèmes
Dans ce cadre, nous citerons quelques exemples
d?activités selon le genre et le lieu d?applicabilité. Une
application scientifique est un modèle concret où se juxtaposent
ces notions.
· Humains : systèmes biologiques
· Environnement : système social, politique,
international
· Activités journalières : bâtir des
briques de systèmes (production de biens et services, maintenance,
surveillance, gestion ...) dans les domaines les plus divers (alimentation,
construction, transport, communication, arts, sport, santé, ...)
|
|
b) Activités humaines articulées autour
des problèmes
Dans cette catégorie, les activités sont
orientées selon le problème dont ils sont les mesures pratiques
de sa résolution. Aussi dans les questions scientifiques, une
application doit en un niveau donné du traitement permettre à son
opérateur humain d?émettre une décision.
· Prises de décision (decision making)
· Solutionner les problèmes (problem solving). Un
problème est l'état de dysfonctionnement d'un système ou
bien un défi, une difficulté à surmonter
· Problème dénote un état et non un
objet
· Problème et système sont liés dans
une échelle de perception. Peu de problème (ajustement)
...beaucoup de problèmes (démolition de système entier)
· Avant de proposer un geste, une action : analyse,
modélisation, représentation, méthodologie d'approche,
choix d'une solution optimisée
|
|
c) Types de problèmes
Le problème dénote particulièrement le
renversement de l?état d?un système en marche, vers des allures
non voulues. Aussi un classement conventionnel des problèmes aide
à bien gérer les décisions. Pour des besoins de
localisation de notre thème par rapport aux modèles qui peuvent
exister nous citons, Les problèmes :
· Logique
· Algorithmique
· Basé sur des règles (Rule-Based)
· Prise de décision (Decision Making)
· Dépannage (Troubleshooting)
· Diagnostique (Diagnosis)
· Analyse de cas (Case Analysis)
· Dilemme (Dilemma)
· Conception (Design). Amener de l'état non
structuré (Ill-Structured) vers l'état structuré
(Well-Structured)
|
d) Méthodes de résolution
Les démarches orientées essais de recherche de
solution varient selon la nature du problème à résoudre
donc de la nature du système en arrière plan. Est-t-il
déterministe? Mesurable? Ou malheureusement très
aléatoires en nature et en événements.
Les approches de résolution de problème et de
conception de systèmes sont identiques:
1. définir le problème
2. le clarifier
3. Discuter avec les autres
4. Obtenir des informations complémentaires
5. Étudier l'historique
6. Regarder les contraintes
7. Établir les buts
8. Générer les idées
9. Évaluer les possibilités
10. Choisir une solution
11. Simuler la solution
12. Essayer la solution sur la cible réelle
13. Faire des ajustements
14. Déterminer si la solution fonctionne
En résolvant un problème, on modifie
l'état du système, changer tout un système ou retoucher
une partie de son fonctionnement pour corriger un problème implique les
mêmes étapes.
e) Phases d'analyse et de conception
Rappelons succinctement les 4 phases principales de
développement d?un produit ou d?un système logiciel à
partir du moment où le développement est décidé.
|
o Détection et Analyse des besoins (Modèle
problématique Sp)
o Modélisation et conception d?une vision (Modèle
solution Sm)
o implémentation et Implantation (Alignement Modèle
solution sur Modèle problématique) o Évaluations et Tests
(Essais de réduction de l?erreur
å=|Sp-Sm|)
|
Ce chapitre traite principalement les deux premières
phases de développement dans un perspectif objet à l?issu de la
phase de conception, avant d?entamer l?implantation. Pratiquement, le seul
problème qui reste au développeur à décider du sort
du choix des technologies existantes et de la réalisation
concrète du projet.
Dans le cas du Logiciel d?édition de texte du style
Notepad avec un correcteur orthographique à construire. L?analyse
consiste à identifier les fonctionnalités de ce logiciel,
spécifier le système de menus, décider quoi mettre dans
les sous-menus. Il faut établir la séquence des opérations
qui compose une fonction quelconque (exemple: changer de police, faire un
couper/coller, sortir du logiciel, etc.).
Dans la phase de conception, il est recommandé d?aller
plus loin dans les spécifications détaillées mises en
place à la phase d?analyse en identifiant les modules les plus
importants à réaliser, par exemple le module d?édition de
texte, le module de sauvegarde, le module de vérification
orthographique, etc.
Par la suite, en descendant dans les niveaux, vous devez
identifier les fonctions élémentaires comme changer la police
d?une partie de texte, une recherche de texte, une recherche/remplacement de
texte, etc.
Chaque module doit être complètement
spécifié (paramètres d?entrée, paramètres de
sortie, fonctionnalités...) de telle sorte que nous puissions voir s?il
n?y a pas de possibilités d?acquérir des composantes logicielles
déjà existantes ou non (le vérificateur orthographique est
par exemple un module que nous pouvons faire venir sans avoir à le
fabriquer).
Il existe une confusion observée dans le degré
d?avancement avec lequel la conception est doit être effectuée.
Dans des situations plus graves, la phase d?analyse est faussement
considérée comme une phase de conception et la
spécification est faussement considérée comme de l?analyse
ou pire de la conception. On peut relever dans la littérature des
exemples, qui sont soit trop simplistes ou qui ne sont pas de la conception
mais seulement une spécification détaillée juste bonne
pour fabriquer des modes d?emploi.
Dans le développement objet étudié plus
tard, l?un des critères applicables pour
Méthodologie de conception des logiciels scientifiques
déterminer si la conception technique est
complète ou non est de comparer le produit fini avec les documents de
conception. Minimalement, toutes les déclarations de classes et
de méthodes doivent figurer dans le document de conception sans
la partie implémentation des méthodes (le corps des programmes ou
le contenu des méthodes).
Bien sûr, lorsque vous concevez, vous n?avez pas le
produit fini en main pour établir cette comparaison mais, il suffit de
mener à termes quelques projets de taille moyenne pour savoir par la
suite jusqu?à quel niveau de détails vous devriez amener votre
conception. Il s?agit d?une question d?expérience.
La présence de toutes les classes ne donne qu?une vue
"structure" du système à développer. Nous avions dit
"minimalement" car il manque des renseignements précis sur la dynamique
du système, c?est-à-dire comment se déroule le programme
ou comment les activités élémentaires sont
coordonnées pour effectuer une tâche donnée. Ce sont les
diagrammes dynamiques qui vont fournir ces informations.
Le dossier de conception doit contenir tous les détails
portant sur les trois aspects: structurel, fonctionnel et dynamique.
Développement classique non objet
Avant l'apparition de la méthodologie objet, on
développe les systèmes selon deux axes principaux :
a. Approche FONCTIONNELLE pour les
systèmes temps réel: Un certain nombre de problèmes
peuvent être traités naturellement en identifiant la fonction
principale qui est affinée progressivement pour aboutir aux fonctions
élémentaires selon une hiérarchie de
décomposition.
Fig. IV : Approche fonctionnelle et organisation
des éléments d?un logiciel
Cette méthode, la plus intuitive, existe
déjà depuis presque une quarantaine d?année. Les plus
représentatives sont SA (Structure Analysis de Yourdon 2 ), SART (SA
RealTime), méthodologie de De Marco 3 , Gane Sarson 4 , Jackson 5 ,
Shlaer & Mellor 6 , etc.
Les avantages portent sur son aspect intuitif. Il faut cependant
bien identifier les données
Méthodologie de conception des logiciels scientifiques
et les contrôles échangées entre les
diverses fonctions dans la hiérarchie. Il est difficile de
définir une collaboration dans une étude fonctionnelle car la
fonction appelante est toujours considérée comme "en haut" dans
la hiérarchie d'appel.
Les inconvénients de la méthode fonctionnelle sont
cependant multiples :
· La vue fonctionnelle est dominante. Il y a un masquage
très accentué de la vue structure. La vue dynamique est cependant
traitée correctement dans le passé
· Certains systèmes ne possèdent pas de
fonction principale ou que l?identification de cette fonction est artificielle
(exemple: logiciel de gestion d?un aéroport)
· Difficultés avec la distinction des données
et des contrôles, ce qui ralentit le rythme de développement
· Maintenance difficile. Le changement vers un
système plus important nécessite le plus souvent une
réingénierie totale du système
· Faible réutilisabilité (les fonctions et
les groupements de fonctions sont dans un format difficile à utiliser
avec les paramètres d'entrée et de sortie)
· Critères de regroupement en modules très
variables selon le point de vue de chaque développeur.
|
|
Bien que cette méthodologie FONCTIONNELLE reste encore
très utilisée par les compagnies non encore converties vers
l?objet, ces inconvénients réunis font que cette méthode
n?est encore utilisée que pour les petits systèmes, que pour les
compagnies qui ne font qu?accidentellement du développement et que leurs
produits ne changent pas souvent avec le temps (peu de maintenance).
b. Approche Modèles de
données, Modèles entités/relations,
modèles sémantiques pour le développement des bases de
données: Dans cette catégorie, citons Chen 7 , Merise 8 , ORM 9 ,
Sylver Run (Laval), EPAS 10] (Moulin, informatique), etc.
Ces méthodes sont encore très utilisées
pour développer des bases de données relationnelles classiques
(non objet). Les concepteurs de BD utilisent dans la phase d?implantation un
moteur de bases de données qui possède deux sous-ensembles :
· DDL (Data Definition Language) qui permet de rentrer les
entités (tables relationnelles), leurs attributs puis ensuite les
relations à établir entre les entités
· DML (Data Manipulation Language) le moteur d?exploitation
de la base de données qui permet d?exécuter des commandes de
l?usager sous forme de requêtes SQL.
Quand la base grossit, l?usager peut ajouter d?autres
entités, d?autres attributs, d?autres relations.
Cette méthodologie de travail n?exige, dès lors du
concepteur de bases de données, qu?une vue synthétique de toutes
les données qui sont transigées dans le système. Comme
Méthodologie de conception des logiciels scientifiques
tout système possède 3 vues indissociables :
structurelle, fonctionnelle et dynamique, le développement classique de
bases de données n?exige de la part des concepteurs seulement qu?une
très bonne vision de la structure, les deux autres vues ont une
importance secondaire dans ce type d?application et sont prises en charge par
le moteur sur lequel repose l?implantation de la base. La réussite d?une
base de données repose principalement sur la qualité du moteur.
Les moteurs que nous connaissons dans les BDs classiques sont par exemple
Oracle de Oracle Corp., SQL Server de Microsoft, MySQL du monde Unix, DB2 de
IBM, etc.
Nécessité d'un développement
OBJET
Les méthodologies classiques ont fait leur temps. Le
choix d?une méthodologie de développement dépend de la
nature de l?application dans l?ancienne école. Très vite, on peut
faire l?association suivante:
Méthodologie FONCTIONNELLE?Applications en contrôle,
applications temps réel, problèmes arithmétiques ou
algorithmiques.
Méthodologie MODÉLISATION DES DONNÉES?Bases
de données.
Les applications modernes sont très grosses et sont en
général mixtes (temps réel avec des BD ou BD
contrôlant des unités temps réel, etc.). Dans ce cas, le
choix d?une méthodologie classique deviendrait évidemment
nettement plus difficile.
a. Problème de la réutilisation (inter
application)
Les entreprises dont la vocation est le développement
logiciel font face avec le problème de la réutilisation. Les
nouvelles applications ont besoin d?un certain nombre de
«procédures» ou de «fonctions»
développées dans d'autres applications. Il faut faire des
couper/coller, modifier les structures de données pour les
intégrer dans les nouvelles applications. C?est faisable mais la
procédure prend du temps et demande du personnel très
qualifié.
b. Réutilisation à l'intérieur d'une
mme application (intra application)
Il arrive très souvent en développement qu?une
nouvelle procédure a besoin d?une grande partie d?une procédure
existante avec simplement de petites retouches. On a alors deux
possibilités: méthode "couper/coller" ou bien encore refaire la
procédure appelée pour qu?elle puisse être
appelée par la nouvelle procédure appelante. En concept objet, il
suffit de dériver une nouvelle classe et ajouter d?autres
caractéristiques (fonctions et attributs).
Méthodologie de conception des logiciels scientifiques
c. Application traversant la frontière de
l'entreprise (interopérabilité)
Pour mettre en oeuvre des applications d?envergure, on a
besoin d?un modèle fiable mettant en jeu plusieurs produits logiciels de
plusieurs compagnies. Ignorant la façon dont les produits sont
développés à l?intérieur de chaque compagnie, on
désire avoir un modèle d?interaction commun qui permet à
une application de «voir" et «obtenir des services" d?autres
applications d?autres entreprises.
d. Interopérabilité en réseau
Il s?agit d?élargir la notion précédente
aux applications réseaux, aux applications Internet. On peut
déclencher par exemple une application au noeud A qui va demander des
services aux noeuds distants B, C, ...qui renvoient des données ou des
résultats de calcul au noeud A. Les modèles COM (Common object
Model) ou (DCOM: Distributed COM) ou Activex développés par
Microsoft sont conçus dans cet objectif.
e. Logiciels à composants
L?un des objectifs du génie logiciel est de
définir une façon fiable, simple, commode permettant aux usagers
de fabriquer eux-mêmes une application en associant tous les autres
«composants" logiciels à la manière des "blocs LEGO". Pour
donner une image, on achètera des objets composants dans un
supermarché informatique, de composants mécaniques,
électriques, biologiques...et on les assemble. Par exemple, pour monter
un robot, on achète le bras (le terminal), les cartes
électroniques qui contrôlent les mouvements et on mettra
simplement un «chip" contenant le logiciel qui permet de rendre ce bras
intelligent et capable de réaliser des mouvements. On achète plus
tard un module de reconnaissance vocale qui remplacera l?interface clavier et
souris, etc.
Ce marché des composants a été
concrétisé chez Microsoft avec les composants ActiveX
basés sur le langage Visual Basic. Les ActiveX abondent dans le
domaine de développement des logiciels sur Internet. La plate-forme
Visual
Studio.Net (en l?occurrence Visual
Studio 2005) représente une évolution normale de la technologie
du logiciel à composants. Dans la terminologie de Microsoft, un
composant logiciel s?appelle désormais "assemblage" (assembly).
Exemple: La plateforme
Visual.Net (Framework ver 1,2,3 ou 4)
résout par exemple le problème d?écrasement des
composantes logicielles lors de la mise à jour. Supposons qu?une
application A fonctionne avec la version C1 d?une composante C. Une autre
application B devrait avoir la version de C pour fonctionner correctement. La
plateforme
Visual.Net permet à A et B de
coexister avec les deux versions C1 et de C
Méthodologie de conception des logiciels scientifiques
(side by side development). Donc, on peut mettre les
versions successives sans détruire ce qui existe.
Si, pour l?instant, le logiciel à composantes est une
réalité chez Microsoft, l?interopérabilité inter
plate-forme (exemple Windows/Linux) est à son balbutiement, ce sera la
prochaine étape. En attendant, quelques efforts sont quand même
mis en place dans le domaine de l?Internet.
Exemple: Les services Web XML (XML Web Services) sont des
bouts de code qui permettent aux programmes écrits dans
différents langages, dans différentes plateformes à
communiquer ensemble et partager les données à travers les
protocoles Internet comme XML, SOAP (Simple Object Access Protocol), WSDL (Web
Services Description Language) et UDDI (Universal Description, Discovery and
Integration).
f. Développement en équipe
Le développement de logiciels de taille importante
requiert souvent une coopération de plusieurs équipes de
programmeurs. La coopération entre ces équipes est
délicate. Le problème est qu'il faut découper un logiciel
en modules, chacun pouvant être développé
indépendamment des autres, et testé séparément. On
doit donc utiliser des méthodes de représentation, des concepts
uniformes aux divers niveaux de développement.
g. Comprendre les applications complexes
Nos activités quotidiennes nous amènent à
manipuler des objets complexes, des outils sophistiqués. Nous le faisons
le plus souvent sans réellement savoir comment ces outils sont
constitués à l?interne. Cependant, en connaissant leurs
aptitudes, leurs capacités et en connaissant le mode d?emploi, nous
pouvons mettre en oeuvre des applications d?envergure avec ces objets complexes
et ces outils sophistiqués (par exemple, nous pouvons réaliser
des photos surprenantes? sans rien connaître à la
chimie du papier photographique ni des films et sans savoir réellement
les micros mécanismes de l?appareil photo).
Donc, pour comprendre et utiliser un objet complexe, il suffit
de savoir quelles sont ses propriétés, ses possibilités et
son mode d?emploi. L?objet complexe est formé en réalité
de la combinaison? d?une multitude d?objets plus
élémentaires. Une tâche complexe se réalise souvent
par une activation dans un ordre déterminé de tâches plus
élémentaires, qui, bout à bouts, donneront le même
résultat.
Le produit fini peut être extrêmement complexe mais
son interface doit rester toujours simple. C?est là le secret d?une
bonne modularité en conception objet.
Méthodologie de conception des logiciels scientifiques
h. Délai de mise en route des applications complexes
et minimisation des coûts
Si la construction d?une application complexe fait appel
à une multitude de composants dont un certain nombre existe
déjà sur les tablettes, il est bien évident que le
délai de mise en route d?une application complexe sera fortement
réduit. Il y va de méme du coût (car un objet
déjà développé et qui peut être
distribué à une petite ou moyenne échelle va coûter
quand même moins cher que de recommencer tout un développement.
Historique de l'objet
C'est en 1965 que deux chercheurs norvégiens, Ole Dahl
et Kristen Nygaard ont posé les premières pierres du concept
"objet". En cherchant à améliorer la
capacité d'expression des langages traditionnels afin d'exprimer des
modèles de simulation avec plus d'efficacité, ils proposaient
d'unifier les notions de procédures et de données grâce
à un mécanisme d'abstraction qu'ils nommaient "classe d'objets".
Ils proposaient alors le principe d'encapsulation, de classe, d'instance et de
factorisation des propriétés des classes en graphes
d'héritage. Tous ces principes ont abouti au langage Simula-67. Le
deuxième promoteur de ce "mode de programmation" fut Alan Kay, qui avait
introduit l'idée de communication par messages qui conduisait au langage
Smalltalk (1976).
En 1992, l'utilisation de l'approche objet n'était
qu'expérimentale dans beaucoup d'entreprises, y compris en
programmation. Le boum de la technologie objet a pris place avec les
applications client/serveur. Tous les outils de développement
d'interfaces graphiques sur les postes client font appel aujourd'hui au concept
objet.
Le langage UML (Unified Modeling Language) ou
"Langage de modélisation objet unifié" repose sur l?effort
conjoint de 3 personnes qui ont développé respectivement leur
propre méthode:
· Booch avec sa méthode Booch
· Rumbaugh avec OMT (Object Modeling
Technique)
· Jacobson avec OOSE (Object Oriented
Software Engineering)
Le développement d'UML a commencé en octobre
1994 quand Grady Booch et Jim Rumbaugh de Rational Software Corporation ont
débuté leur travail sur l'unification des méthodes Booch
et OMT.
Étant donné que les méthodes Booch et
OMT se développaient déjà
indépendamment l'une de l'autre et étaient mondialement reconnues
comme les principales méthodes orientées objet, Booch and
Rumbaugh ont joint leurs forces pour réaliser une unification
complète de leurs méthodes.
UML n'est pas radicalement différente de celle de Booch,
OMT, ou OOSE, mais elle est
Méthodologie de conception des logiciels
scientifiques
plutôt un produit issu de la fusion. UML est plus
expressif, plus propre et plus uniforme que Booch, OMT, OOSE, ce qui signifie
qu'il y a un bénéfice effectif à utiliser UML.
Actuellement, UML est à sa version stable 2.0. UML est
normalisée par OMG (Object Management Group) une association
fondée en avril 1989 par 11 compagnies parmi lesquelles figurent
3Com Corporation, American Airlines, Canon, Inc., Data General,
Hewlett-Packard, Philips Télécommunications N.V., Sun
Microsystems and Unisys Corp. En octobre de la même
année, OMG devenait une organisation sans profit qui regroupe
actuellement des centaines de membres corporatifs. Son rôle est
essentiellement la spécification des standards industriels dans le
domaine de l?analyse et de la conception. Comme son nom l?indique (O comme
object dans OMG), cette organisation s?occupe essentiellement des standards
orientés objet.
UML est le formalisme le plus supporté actuellement
dans l?industrie du logiciel. Il permet de constituer les dossiers
principalement dans les phases d?analyse et de conception. La compagnie
Rational Rose, fondée par Booch, Rumbaugh et Jacobson (actuellement
vendue en décembre 2002 à IBM) développe en plus des
outils de spécification pour compléter le produit Rational Suite
Enterprise.
Depuis 1998, la compagnie Rational Rose (devenant IBM en
2003) distribue des licences gratuites renouvelables à chaque
année pour l?enseignement d'UML. A partir de 2004, SparX Systems prenait
la relève et fait de même en fournissant gratuitement sa
plate-forme aux centres d?enseignement et de recherche en génie
logiciel.
UML évite de se définir comme une
méthodologie. Comme son nom l?indique, c?est un langage
«visuel» qui permet d?exprimer la compréhension d?un
système avec les 13 types de diagramme définis par UML et
répartis dans 3 catégories:
Diagrammes structuraux (Structural Diagrams) : diagrammes de
classes (Class Diagram), diagramme d?objet (Object Diagram), diagramme de
composants (Component Diagram), diagramme de Structure Composite (Composite
Structure) et diagramme de déploiement (Deployment Diagram)
Diagramme de comportement (Behavior Diagrams) : Use Case
Diagram (utilisé essentiellement dans la collecte des
spécifications et dans la phase d?analyse), diagramme de séquence
(Sequence Diagram), Diagramme global d'Interaction (Interaction Overview),
diagramme d?activités (Activity Diagram), diagramme de communication
(Communication Diagram), charte d?états (State machine Diagram),
chronogrammes (Timing Diagrams)
Diagrammes de gestion du modèle (Model Management
Diagrams) : les paquetages (Packages).
En résumé, UML est avant tout un support de
modélisation permettant aux concepteurs
Méthodologie de conception des logiciels
scientifiques
de traduire leurs visions des systèmes avec un outil
riche et évolutif (concept de stéréotype
définissable par l?usager) à base de diagrammes couplés
à une base de données pour stocker les données d?un
développement. Comme tout bon standard en informatique, il est en
constante évolution pour s?adapter aux besoins des concepteurs de
logiciels et s?adapter à l?évolution de l?informatique. UML se
garde de se définir comme méthodologie, il vous appartient de
développer votre propre méthodologie de travail en vous servant
d'UML.
Version UML 2.0
Rappelons que l'objectif d'UML est de fournir un cadre
méthodologique rigoureux de modélisation graphique d'un
système, selon une approche objet, à l'aide d'un certain nombre
de diagrammes, mais de manière indépendante de tout langage de
programmation classique (comme C++, C# ou Java).
Avec les versions 1.x de UML, l'analyste spécifie les
fonctionnalités attendues via un modèle de cas d'utilisation, l'
architecte décrit l'architecture de son logiciel via un modèle de
classe et ébauche une partie du comportement du logiciel grâce
à des machines d'états ou des diagrammes d'activités. Ces
versions ne supportent pas les activités de conception
détaillée. En effet, dès qu'il s'agit de développer
de manière précise les algorithmes des méthodes ou les
traitements associés aux machines d'états, UML 1.x n'offre que du
"texte libre". Quelques possibilités de spécification formelle
dans les machines d'états sont offertes, mais elles sont trop
limitées pour être réellement utiles.
En pratique, une fois les diagrammes dessinés, on code
directement avec un langage traditionnel. Avec UML 1.x, nous sommes donc
toujours au bon vieux paradigme : d'un côté, les activités
d'analyse et de conception (les préliminaires) et, de l'autre, les
activités de codage et de test. C'est ce qu'on appelle un
développement "code centric", c'est-à-dire centré sur le
code.
UML 2.0 préconise une nouvelle approche qui consiste
à passer à un développement de type "model driven",
c'est-à-dire basé sur la modélisation.
Concrètement, il s'agit de confectionner des modèles assez riches
pour intégrer les activités de codage à un niveau
d'abstraction élevé. Le code devient une production, un artefact
dans le vocabulaire UML et de la modélisation, au même titre que
la documentation issue de l'analyse ou de la conception.
L'objectif est de diminuer l'importance de la fonction codage
pour se focaliser sur la finalité du développement, les fonctions
que le système doit fournir en conformité avec les exigences du
client. Encore une fois, l'accent est mis sur la séparation entre
l'aspect technologique et l'aspect conceptuel pour faciliter la
réutilisation.
Méthodologie de conception des logiciels
scientifiques
L'abstraction des modèles permet de cacher les
détails technologiques non inhérents au modèle et
faciliter la compréhension. Une fois le système
modélisé, l'objectif est de vérifier même le
comportement des systèmes même avant l'implantation. Pour ce
faire, le modèle doit être riche et suffisamment expressif. Lors
de l'évolution de la technologie, le modèle reste toujours
valide.
Dans UML 2.0, le langage est mieux défini et plus
ouvert que dans les versions précédentes. C'est important pour
les vendeurs d'outils logiciels et pour les "méthodologistes". Le
méta modèle UML est aligné sur le MOF (Meta Object
Facilities) normalisé par OMG, la sémantique UML est plus
précise, le format d'échange des diagrammes est basé sur
XML, le langage de contrainte OCL (Object Constraint Language) pour
l'expression des contraintes sur les éléments de
modélisation est revu et corrigé.
Du côté de la dynamique, la modélisation
est désormais basée sur des composants logiciels réactifs
communicants. Ceci permet d'ajouter de nouvelles constructions pour la
spécification des diagrammes de séquence (les variantes, les
références à d'autres interactions).
Enfin, la notion de sémantique d'action est introduite
dans la nouvelle version du langage. Cette nouveauté permet de
décrire précisément les algorithmes des traitements
opérés dans le modèle objet du système. Au point de
vue diagramme, le diagramme de collaboration a été renommé
diagramme de communication.
Un diagramme d'interaction global (interaction overview
diagram), variante de diagramme d'activités, a été
introduit pour traduire le flot de traitement d'un processus vu à un
niveau élevé. Le diagramme d'interaction globale permet de
hiérarchiser le diagramme de séquence. Le "diagramme de structure
composite" doit exprimer la dépendance entre les éléments
d'une classe. Un vrai diagramme d'objets issus des instances corrige une grosse
lacune des versions 1.x. Le diagramme de timing complète l'arsenal des
diagrammes dynamiques. Bien que les paquetages existent dans les diagrammes de
classe auparavant, un nouveau package diagram permet de spécifier les
paquetages. Le nombre de diagrammes passent donc de 9 à 13.
Qualités de l'approche objet
Sans le démontrer pour l?instant, nous allons
énumérer les impacts de l?approche objet sur l?ingénierie
du logiciel. Votre conception objet dans ce cours, si elle est bien faite, doit
s?ajuster à ces qualités. Ce sont des critères sur
lesquels nous allons évaluer une conception objet.
Méthodologie de conception des logiciels
scientifiques
Très tôt, la structure du programme est celle
où elle devrait être à la fin. Par la suite, cette
structure persiste au fil des mises à jour ce qui a une profonde
influence sur les étapes du cycle de vie du produit. Quand le produit
évolue, l'objet devient plus riche, les attributs et les méthodes
s'ajoutent. On peut ajouter d'autres objets mais on ne supprime pas ce qui a
été fait.
Les objets sont souvent concrets et font partie du monde
réel. Une approche objet serait plus proche du domaine, plus intuitive,
plus facile à appréhender qu'une approche fonctionnelle. Pour
déterminer les caractéristiques d'un objet, le programmeur sera
guidé par les caractéristiques de l'objet réel que
modélise l'objet informatique. Celles-ci seront donc
indépendantes de l'utilisation qui en est faite dans le cadre d'un
projet informatique donné. On obtiendra ainsi des unités
facilement réutilisables.
L'objet regroupe les différents aspects d'une
abstraction, donc facilite une meilleure localisation et maintenance. Cette
encapsulation permet une meilleure localisation, c'est à dire les
endroits où il est nécessaire d'intervenir en cas
d'évolution ou de maintenance du logiciel.
Les méthodes orientées objets sont
appropriées à la conception de systèmes parallèles
et permettent d'utiliser une méthodologie unique pour les
systèmes séquentiels et parallèles. Le parallélisme
est une caractéristique naturelle dans le développement objet.
La toile de fonds est la réutilisabilité qui
est réalisée de deux façons, par
agrégation/composition ou par héritage. Ces mécanismes
doivent être omniprésents dans votre développement. En
approche par composition on construit fondamentalement des composants logiciels
dans le but d'être utilisés comme briques de base dans le
développement de logiciels complets. C'est au programmeur de s'adapter
aux composants disponibles, au lieu d'adapter le composant à ses
besoins. La qualité du projet final dépend alors directement de
la qualité des composants externes ou internes utilisés.
Dans l'approche par héritage, on dérive de
nouvelles versions comportant des propriétés additionnelles sans
pour autant affecter les utilisateurs de l'ancienne version. La classification
tend à produire des objets de plus en plus spécialisés
(donc de moins en moins réutilisables) au fil de ses
dérivations.
Le développement avec l?approche objet est, selon
l?application, ascendant, descendant, récursif, itératif,
incrémental à la fois. Ces possibilités permettent de
mettre en fonctionnement les premiers bouts de code très vite sans
attendre la fin du développement, voire même valider des
sous-produits. Tout se passe comme si votre maison se construit chambre par
chambre et dès le premier mois, vous pourrez déjà venir
dormir dans la première chambre.
Méthodologie de conception des logiciels
scientifiques
Quelques idées pour publication
· Conception d?une bibliothèque numérique
orientée calcul réseaux
· Conception de composants visuels orientés
réseaux électriques
· Liaison de NMSS au système SCADA
· Interopérabilité sous NMSS
· Echange de données (Import/Export de
bibliothèques numérique).
8 Références bibliographique
1 CNAM Automatismes et IHM, http://coursducnam.free.fr/
2 P. Coad, E. Yourdon, Object-Oriented Analysis?,
Pearson Professional Education, 232 pages, ISBN 0136291228, Published 1989,
3 C. Gane, T. Sarson, Structured Systems Analysis -
Tools and Techniques?, Prentice-Hall, Englewood Cliffs, NJ, 1979.
4 T. De Marco, Structured Analysis and System
Specification?, Yourdon Press, New York, New York, 1978
5 Gane, Chris and Trish Sarson, Structured Systems
Analysis?. Englewood Cliffs, NJ.: Prentice-Hall, 1979.
6 Jackson, M.A.; 'System Development'; Prentice Hall, New
Jersey; 1983
7 Shlaer, S., Mellor, S.; 'Object Lifecycles: Modeling the World
in States'; Prentice Hall; 1992.
8 Y. E. Chen, B. Kirshnammurthy, An Objective Reuse
Metric : Model and methodology?
9 Laura C. Rivero, Jorge H. Doorn, Database Integrity:
Challenges and Solutions?, Idea Group Inc. (IGI), 300pages, 2002
10 T. B. Bollinger, S. L. Pfleeger, Economics of
reuse: issues and alternatives,
Information and Software Technology?, v.32 n.10, p.643-652, Dec.
1990.
11 B. MOULIN, La méthode E.P.A.S. pour la
modélisation et la conception de systemes?, rapports de recherche
DIUL-RR-85-07. 08 et 09, Universite Laval; septembre 1985.
12 S. R. Gallagher &; «Computer Visualization for
Engineering and Scientif
Analysis»; CRC Press; ISBN: 0849390508; 1994.
| 
