WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Réalisation d'un système expert d'aide à  la répartition économique des puissances dans un réseau électrique

( Télécharger le fichier original )
par Mohammed TAMALI
Université des sciences et de la technologie d'Oran Mohamed Boudiaf - Doctorat d'état en électrotechnique 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Aux âmes bien nées, la valeur n'attend point le nombre des années"   Corneille