|
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 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
k Avec ? S |
Eq. II.3 |
En manipulant les deux équations, nous aurons :
Eq. II.4
Eq. II.5
Examinons cette dernière équation (Eq. II.5), nous remarquons que la génération ou la consommation au niveau de chaque noeud ne doit être considéré indépendant de la composition topologique du réseau et de façon dont les producteurs sont connectés aux consommateurs. En fait, le tout est fait de telle sorte qu'un besoin de consommation d'énergie en un noeud est comblé par des surplus de puissance générée parvenant des noeuds restants du réseau.
La même équation peut être vue autrement
Eq. II.6
Le transit de puissance se fait à travers des lignes de transport qualifié par des por i j
?
Z
Y Y
caractéristiques électriques par rapport au matériau utilisé. Cette caractéristique 8 n'est
) ? / 2) pour i j
?
que l'impédance série Zser et l'admittance shunt Ysh.
|
Eq. II.7 |
Dans cette vue de la relation, toutes les puissances injectés actives ou réactives au noeud k contribuent en tant que carence de demande ou de surplus de génération senti chez les autres noeuds auxquels est connecté ce méme noeud k (Fig II.3).
Fig II : Exemple de réseau avec ses composantes actives
Nous remarquons tout de même que le réseau électrique, par ses composantes actives ou passives met en jeux quatre paramètres avec lesquels l'état du système est déterminé.
Fig II : Schéma normalisé d'un réseau électrique 8
Les équations précédentes font apercevoir d'ores et déjà les éléments SG, SD, V et I, respectivement les puissances apparentes générée, la puissance apparente demandée, la tension et courant au noeud. Selon une critique plus poussée, l'énergie réactive ainsi que son influence sur la stabilité et la propreté de la tension nodale des impuretés harmoniques ou tout simplement les chute de tension, exigent une position plus explicite faisant montrer une adéquation claire entre P, Q, |V| et enfin ö [5, 8, 9 , respectivement les puissance active et réactive aux noeud considéré, le module de la tension au noeud et finalement le déphasage du courant par rapport à la tension (ce qui indiquera autrement un Cosp donc la qualité). Nous reconnaissant aussi qu'avec la même écriture la puissance générée et celle consommée seront lu implicitement de la même mise en équation Eq. II.6, 8
Eq. II.8
Par convention, les paramètres Pk, Qk, Vk et ök sont dites variables d'état du système réseau. Une fois déterminées, permettent une identification exacte du problème de la production à l'égard d'une éventuelle demande.
A cette méme base, les noeuds doivent être vus différemment selon qu'ils soient générateur simple, référence ou simplement consommateur.
Tab. II : Type de noeuds et liste des variables d'état connus et inconnues (- : non connue)
Type Pk Qk |Vs| ök
Bilan - - 1.0 0°
Générateur PG - |Vs| -
Consommateur PD QD -
En tant que variables d'état et d'après la relation Eq. II.8, nous observons que pour un réseau électrique à n noeuds le nombre d'inconnues serait 4*n (dont Pk, Qk, , ök au
nombre de n chacun). Alors que selon le tableau Tab. II.1 si nous soustrayant 2*n ce qui ne
laisse que 2*n inconnues comparé à n équations indique que la solution est encore non visible. En séparant la partie réelle et celle imaginaire en deux équations manipulables séparément.
Eq. II.9
Eq. II.10
Sachant que
D'où 2*n équations pour 2*n inconnues.
Les méthodes numériques ne peuvent que profiter de cette remarque afin de nous permettre de résoudre le système d'équations en suivant un algorithme précis susceptible d'être implémenté sous forme d'un code informatique écrit dans un langage adapté.
Une figure du même problème est décrite par la relation Eq. II, 11, 12 :
Eq. II.11
Eq. II.12
Les deux équations dites 'équations du bilan - actif et réactif' sont sources d'une longue discussion. Certes, l'énergie électrique produite ne peut être stockées en grandes quantités ce qui signifie qu'une prédisposition obligée du producteur est exigé afin de s'aligner à toutes les demandes éventuelles.
PL et QL respectivement pertes par transmission actives et réactives quant à elles jugent l'égalité demandée entre la production PGi ou QGi et la demande des consommateurs CT ou DT, dépendant de la génération.
Fig. II : Contribution d'un noeud m par son
apport dans l'adéquation Production/Transport
(Equation du bilan)
De cette constatation, nous remarquons que pour un temps t donné, le consommateur exige une puissance CT fini, Le producteur répond en générant cette quantité, prenant en considération le conditionnement du réseau de transport. Pour ce faire, Les producteurs (Centrales) mettent en jeux leurs propres caractéristiques techniques en matières de la façon avec laquelle la génération d'une quelconque énergie est réaliser; c'est la 'fonction coût'. Cette fonction mathématique montre la relation entre la puissance générée Pgi et le coût apposant à payer équivalent à l'énergie primaire dépensée (même discussion faite pour la parie Qgi).
La forme mathématique en question d'une fonction coût peut être écrite selon la relation suivante :
Eq. II.13
Pour et ai, bi, ci sont des coefficients dépendant du type de centrale utilisé.
Si nous regroupant toutes ces informations sous une même équation, nous obtenant :
|
g N N N L ? ? C m=l h= |
Eq. II.14 |
D'où fonction écrite par rapport à la contrainte inégalité = sur Pgj et
fonction écrite par rapport à la contrainte inégalité = sur Pgj mais chacune multipliée par un paramètres ?. dit multiplicateur de Lagrange ou Khun-Tuker dans le sens le plus large 3, 4, 9 où l'équation est prise dans son sens non-linéaire. Cette même relation peut intégrer les quantités équivalentes pour la partie réactive.
Bien entendu, selon une vision plus approfondie, nous prenons PL comme fonction des ? puissances générées Pgi (seule partie contrôlable dans le système) donc :
( .
P Q Q Q P Q Q P
? ? ?
k kl l
? k kl l
? k kl l
? k kl l
? )
Eq. II.15
Comme aussi prises constantes, le cas de la forme Eq. II.14.
Les pertes par transmission une fois fonction des puissances générées 8 doiventt être écrites sous la forme suivante :
Eq. II.16
Avec
Eq. II.17
PGk et PDk étant tout simplement les puissances actives et réactives au noeud k, RN la résistance de la ligne considérée.
Les relations Eq. II.9 et Eq. II.10 ont d'autres formes selon que l'éventualité le permet ainsi que les besoins et moyen de calcul offrent. Les algorithmes à leur tour peuvent eux
R N KL
? cos ?
aussi représenter une source d'idées formalisant les deux équations mentionnées plus haut.
k l
Les méthodes de calculs les plus utilisées sont
N KL sin ? k
· Transit de charges : Gauss-Seidel, Newton-Raphson & variantes, Relaxation ...
V
P P
· Lissage de courbes : Polynômes de Lagrange, Moindres carrés, Polynômes de Newton ...
· Répartition des charges : Simplexe, Fletcher-Powell, Bellman, Algorithmes génétiques ...
G Dk
· Topologie des graphes : Ford, Dijkstra, Moore, Recuit-Simulé ...
· Inférence, Systèmes expert : Algorithmes génétiques, Colonies de fourmis, Chainage Avant/Arrière, Réseau de neurones, Knn....
La caractéristique la plus essentielle pour mener à bien le calcul et émettre une décision concernant un problème posé, c'est l'algorithme avec ses paramètres mathématiques, complexité algorithmique et temporelle. Aussi la potabilité d'un algorithme fait en sorte que ce dernier peut être utilisé sur n'importe quel type de machine à calculer.
L'importance du modèle est grande dès lors où toute autre projection finira par un résultat qu'il faut juger par sa justesse et exactitude. Les chemins mathématiques entrepris pour arriver à destination d'un éventuel résultat qualité par une côte positive ou le contraire l'algorithme en dépendant.
La projection de ces modèle mathématiques se traduira par la naissance d'un modèle vivant et équivalent sur, en méme temps, l'écran et la mémoire d'un ordinateur.
6 Références
1 A.Feliachi, A.P.Meliopoulos, "Modeling and Simulation of Large Scale Interconnected Systems", Advances in Modeling & Simulation, AMSE Press, Vol. 1, No. 1, pp. 33-49, 1984.
2 Sheble G.B.; Real-time economic dispatch and reserve allocation using merit order loading and linear programming rules; IEEE Transactions on Power Systems, Vol. 4, No. 4, October 1989.
3 Liu D., Cai Y.; Taguchi Method for Solving the Economic Dispatch Problem with Nonsmooth Cost Functions; IEEE transaction on power system, VOL. 20, NO. 4, November 2005.
4 Liu D., Cai Y.; Taguchi Method for Solving the Economic Dispatch Problem with Nonsmooth Cost Functions; IEEE transaction on power system, VOL. 20, NO. 4, November 2005.
5 L.L. Grigsby, A.P. Hanson R.A. Schlueter and N. Alemadi; «Power Systems»; The Electrical Engineering handbook 063, CRC Press LLC, 2000.
6 Tamali M.; Conception d'un logiciel de modélisation et simulation des réseaux électriques NMSS; Master thesis equivalent diploma; presented in 1995.
7 A.J. Pansini; «Guide to Electrical Power Distribution Systems»; Sixth Edition; THE FAIRMONT PRESS, INC; ISBN: 0-88173-505-1; [TK3001.P284 2005].
8 G.W Stagg & A.H. El Abiadh: "Computer Methods in Power System Analysis" Edition McGraw Hill, 1968.
9 M. Rahli: " La commande optimale des puissances actives par la programmation linéaire " Thèse de Magister soutenue le 3 juillet 1985, USTO.
L'histoire de la théorie des graphes débute avec les travaux d'Euler au XVIIIème siècle et trouve son origine dans l'étude de certains problèmes, tels que celui des ponts de Königsberg (Fig. III ), la marche du cavalier sur l'échiquier ou le problème de coloriage de cartes.
Fig.III Les sept ponts de Königsberg
La théorie des graphes s'est alors développée et intégrée dans diverses disciplines telles que la chimie, la biologie, les sciences sociales et sans oublier les réseaux d'ordinateurs et de télécommunication. Depuis le début du XXe siècle, elle constitue une branche à part entière des mathématiques, grace aux travaux de König, Menger, Cayley puis de Berge et d'Erdös .
De manière générale, un graphe permet de représenter la structure, les connexions d'un ensemble complexe dit `système' (S) en exprimant les relations entre ses éléments tel que les réseaux de communication, les réseaux routiers, interaction de diverses espèces animales, circuits électriques, en programmation et le plus intéressant son application aux sciences de l'Internet.
Les graphes constituent donc une méthode de pensée qui permet de modéliser une grande variété de problèmes en se ramenant à l'étude de sommets et d'arcs Les derniers travaux en théorie des graphes sont souvent effectués par des informaticiens, du fait de l'importance que revét l'aspect algorithmique
Définitions relatives à la théorie des graphes
a. Définition du graphe simple Un graphe simple noté G est un couple formé de deux ensembles liés par une application
mathématique. L'un d'eux est l'ensemble X={x ,x ,...,xn} dont les éléments sont appelés `sommets', l'autre est l'ensemble A={a ,a ,...,am}, partie de l'ensemble P (X) des parties à deux éléments (couple de sommets) de X, dont les éléments sont appelé `les arêtes'. On notera cette relation G=(X,A).
Lorsque a={x,y}EA, on dit que a est l'arête de G d'extrémités x et y, ou que a joint x et y, ou que a passe par x et y. Les sommets x et y sont dits adjacents dans G.
Fig III : Graphe G(X,A)
b. Définition du multi-graphe Un multi-graphe G = (X,A,f) est déterminé par:
· L'ensemble X des sommets
· L'ensemble A, cette fois abstrait
· L'application f : A [P (X)]
Fig III. : Exemple de multi-graphe
Dans cet exemple, x, y, z, t sont les sommets du multi-graphe et :
f(a )=f(a )=f(a )=f(x,t); f(a )=f(x,y}; f(a )=f(x,z}; f(a6)=f(z,t).
Un multi-graphe avec boucles est un triplet (X, A, f) où f est une application de A dans P (X)uP (X), en d'autres termes, un multi-graphe avec boucles peut comprendre des arêtes multiples entre deux sommets donnés ainsi que des boucles multiples en un sommet.
Exemples :
i. Le graphe d'un tournoi, T=(X,A) où :
X est l'ensemble des participants au tournoi
A est l'ensemble des paires de joueurs se rencontrant dans le tournoi.
ii. Le graphe discret d'ordre n, Dn,=(X, 0).
iii. Le graphe complet d'ordre n, Knn où X , ,...,n} et A = P2(X)
Fig. III. : Types de graphes
iv. Le graphe biparti-complet Kpq où X={x ,x ,...,xp,yl,y ,...,yq} et A=f(xi,yj}/ =i=p et =j=q}
Fig. III. : Exemple de graphe biparti 4, 2
v. d. Le cycle Cnn où X={ ,2....,n} et A={{ ,2},{2,3},...,{n- ,n},{n, }}
Fig. III. : Exemple de graphe cycle
c. Définition du degré des sommets Soit G=(X,A) un graphe simple, et x un sommet de ce graphe. Le degré de x, noté d(x), est
le nombre d'arêtes incidentes à x, c'est-á-dire contenant x. Lorsque d(x)=0, on dit que le sommet x est isolé, lorsque x = , il est dit pendant.
Exemples :
si x est un sommet de Cnn d(x)
si x est un sommet de Kpq, d(x)=n-
d. Définition du graphe régulier Un graphe simple est dit régulier de degré r, lorsque tous ses sommets sont de degré r.
e. Définition du graphes orientés
Un graphe orienté Gn est formé de deux ensembles: un ensemble X={x ,x ,...,xn} dont les
éléments sont appelés sommets, et un ensemble A={al,a ....,a.n), partie du produit cartésien X×X, dont les éléments sont appelés arcs. On notera
Gn=(X,A)
Fig. III. : Graphe orienté
Si a=(x,y) est un arc du graphe G, x est l'extrémité initiale de a et y l'extrémité finale de a. Remarque
? 1 ( )
s i x
À tout graphe orienté Gn(X,A), on associe le graphe simple G(X,B) où: {x,y}EB?((x,y)EA ? 0 ( )
i x x A
?
ou (y,x)EA))
f. Définition du degré de sommet d'un noeud de Gn Soit x un sommet d'un graphe orienté On note d+(x) le nombre d'arcs ayant x comme
extrémité initiale, et d-(x)le nombre d'arcs ayant x comme extrémité finale. Ainsi, on a:
d(x)=d+(x)+ d-(x) Eq. III.g. Définition de la matrice d'adjacence Soit G=(X,A) un graphe orienté, avec X={x ,x ,...,xn}. La matrice XJLXjLIfnIf du graphe G
est la matrice N1(G) dont les coefficients mi,j sont définis par:
Eq. III.
h. Définition de la distance Soit G=(X,A) un graphe orienté. Pour tout (x,y)EX , la distance entre le sommet x et le
sommet y est le nombre d(x,y) défini par:
s'il n'existe pas de chemin de x à y d(x,y)=min{l(c)/c est un chemin de x à y}
l(c) désigne la longueur du chemin c. La matrice des distances du graphe G est la matrice D={d(i,j)=(d(xi,xj)}.
Fig. III 8 : Graphe Gn et calcul de la matrice D
Eq. III.
La matrice des distances de G est :
i. 2. Algorithme de Moore
Soit x et y deux sommets d'un graphe G (X,A) L'algorithme suivant calcule la distance
d(x,y) :
On étiquette les sommets de G en observant les règles suivantes :
· le sommet x reçoit l'étiquette
· si (u, v) E A et a est étiqueté k :
i. si v n'est pas étiqueté, alors v reçoit l'étiquette k
ii. si v est étiqueté l, alors l'étiquette de v est remplacée par min(l, k+ ) Si, à la fin, y à une étiquette k, alors d(x,y)=k, sinon d(x,y)=oo
Fig. III.9 : Graphe Gn et calcul de distance On a dans cet exemple: d(x,y) ~
j. Définition des graphes valués et problème du plus court chemin
Beaucoup de problèmes peuvent être modélisés en utilisant des graphes valués. Les
problèmes de cheminement dans les graphes, en
particulier la recherche du plus court chemin,
comptent parmi les
problèmes les plus anciens de la théorie des graphes et les plus
importants
par leurs applications: coût de transport, temps de
parcours, problème de trafic. Les
algorithmes de recherche de plus court chemin seront différents selon les caractéristiques du graphe. Un graphe valué est un graphe orienté Gn (X,A), muni d'une fonction C appelée fonction de coût.
Fig. III.10 : Graphe valué de modélisation d'un réseau aérien
k. Definitions du coût d'un chemin
si i j
Le cofit d'un chemin est la somme des coûts des arcs de ce chemin On peut définir la j matrice des cotits du graphe, c'est la matrice C ={ci,j} où : c est le coût de arête (i
Eq. III.
i
·DEFINITION La matrice de coût minimum, M = (mij), est définie par :tr m n
Eq. III.
l. Definition de l'arbre Un arbre est un graphe simple connexe ne possédant pas de cycle simple.
Fig. III.11 : Graphe ARBRE.
Fig. III.12 : Exemple d'obtention d'un arbre à partir du graphe G(X,A)
|
m. Définition de l'arbre partiel de coût minimum |
|
Fig. III.13 : Graphe simple Fig. III.14 : Arbre du graphe simple
Le problème consiste à construire un graphe partiel, connexe, comprenant un nombre minimal d'arêtes Le graphe (Fig. VI.13) contient 6 sommets, le sous-graphe cherché doit donc contenir 5 arêtes (Fig. VI. ) Il s'agit donc de construire un arbre de recouvrement du graphe (On peut montrer que la relation I A=X- caractérise les arbres parmi les graphes simples connexes).
n. Algorithme de SOLLIN-CALESTAGNE G=(X,A,v) est un graphe simple connexe valué.
Tab. III.1 : Algorithme de SOLLIN
|
) a ={x ,y } est une arête de coût minimum. On pose S={x ,y } et T={a1}. Passer à (2) ) Si S X, alors l'arbre (S,T) est l'arbre cherché, sinon, passer en ) ) On choisit une arête a={x,y} de coût minimum ayant un sommet dans S et l'autre dans le complémentaire de S dans X. On remplace S par Su{x, y} et T par Tu{a}; Passer en ) |
o. C Terminologie
Tab. III.2 : Terminologie de la théorie des graphes
|
Sous-graphe : H = (Y, B) est un sous-graphe de G = (X, A) si Y C_ X et CA . Graphe partiel :H = (Y, B) est un graphe partiel de G = (X, A) si Y = X et CA . Ordre d'un graphe l'ordre d'un graphe est le nombre de sommets de ce graphe Chaîne : suite finie de sommets reliés entre eux par une arête. Chaîne simple : chaîne qui n'utilise pas deux fois la même arête. Chaîne eulérienne : chaîne simple passant par toutes les aretes d'un graphe Chaîne hamiltonienne : chaîne simple passant par tous les sommets d'un graphe une et une seule fois. Chemin : suite de sommets reliés par des arcs dans un graphe orienté. Cycle : chaîne qui revient à son point de départ. Cycle eulérien : cycle simple passant par toutes les aretes d'un graphe une et une seule fois. Cycle hamiltonien : cycle simple passant par tous les sommets d'un graphe une et une seule fois. Graphe connexe : un graphe G est dit connexe si pour toute paire de sommets f X I Y} de G, il existe une chaîne de premier terme x et de dernier terme y. Arbre : graphe connexe sans cycle simple et sans boucle. Graphe eulérien : graphe qui possède un cycle eulérien. Graphe semi-eulérien : graphe qui possède une chaîne eulérienne. Graphe hamiltonien : graphe qui possède un cycle hamiltonien. Graphe semi-hamiltonien: graphe qui possède une chaîne hamiltonienne. Graphe valué : graphe oil des réels sont associés aux arêtes. Dans cet exposé, on ne considérera que des valuations positives. Longueur d'une chaîne nombre des arêtes qui composent la chaîne. Valeur d'une chaîne somme des valeurs des aretes (arcs) d'une chaîne d'un graphe valué. Distance entre deux sommets : longueur de la plus courte chaîne joignant ces deux sommets. Diamitre d'un graphe maximum des distances entre les sommets d'un graphe Indice chromatique : nombre minimal de couleurs permettant de colorier les sommet |
Quelques idées pour publication
· Modélisation des réseaux par la topologie des graphes
· Application du théorème de recherche du plus court chemin au problème de planification des sessions de maintenance dans les réseaux de transport de l'énergie électriques
· Algorithme de Dijkstra et recherche du plus court chemin.
· Simulation visuelle des réseaux électrique dans NMSS par la topologie des graphes
Références bibliographiques
. E.SIGWARD; `Introduction à la théorie des graphes', e.sigward@ac-nancy-metz.fr J LABELLE; `Théorie des graphes'; Edition MODULO; ISBN - 9 ; 9 '
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 :
|
||
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.
|
||
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.
|
||
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 :
|
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 :
|
||
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.
La plate-forme NMSS 4 est basée sur un concept orienté objet, ce qui fait qu'à chaque composant on retient une définition de classe et des instances d'objets, respectant les règles d'hérédité et de polymorphisme.
Dans ce chapitre, il est question d'un positionnement des faits pour un détail qui ne concerne que l'entité centrale dont est axée cette thèse, en l'occurrence, l'objet composant RESEAU avec toute son arborescence.
Nous ne manquerons aux mentions des autres entités représentant les autres objets graphiques conçus pour la gestion visuelle du modèle virtuel sur écran d'un réseau électrique.
La librairie mathématique quant à elle dérive, par ses composantes, d'une classe racine "METHODE". Ces modules dépendent en partie de la célèbre bibliothèque mathématique BLAS (Basic Linear Algebra Subprograms) développée par une équipe de l'Université du Tennessee USA, du MIT et la Stanford University et vite reconnue par la NSF (National Science Foundation) et utilisée par IBM, Intel.
Fig.V : Modèle préliminaire servant de base de conception
L'idée de base sur laquelle est fondé NMSS est le modèle suivant donné par la figure suivante Fig.V.
Méthodologie
La démarche utilisée en tant que méthodologie de conception est connue sous le label OMT (Object Modeling Techniques). Cette dernière repose sur trois grands axes, axe statique, l'axe dynamique et finalement l'axe fonctionnel.
Tout logiciel est caractérisé par un cycle de vie, le diagramme illustré par la figure Fig V.2 ci-après le dévoile clairement:
Fig V : Cycle de vie d'un logiciel
En notation UML (Unified Modeling Language), Langage servant d'outil d'écriture et de représentation d'un système réel ou logiciel basé sur des concepts orienté objets. C'est un Langage de modélisation visuelle qui permet de:
Définir le problème et la solution relative
Visualiser le problème et la solution sous différents angles
Construire la solution
Documenter la solution et le code implémenté
La méthodologie OMT a été développé par James Raumbaugh en 1990 et a fait l'objet de son livre parut en 1991 aux états unis. Elle utilise la notation UML pour modéliser spécialement des systèmes d'information. Elle repose, dans sa gestion, sur trois niveaux ou axes, le niveau ANALYSE, le niveau CONCEPTION et le niveau IMPLEMENTATION.
Partant des écritures du cahier des charges, l'étude de conception prendra comme démarche trois voies comme
Fig V .3 : Démarche à trois axes de la méthodologie OMT
Le langage UML utilise un ensemble de diagramme modèle ou vue pour concevoir le système équivalent à l'application
Ces diagramme et vues sont nécessaires pour une vision claire et exhaustive afin de venir au but qui est l'élaboration de l'environnement logiciel tout complet. Les applications de simulation scientifiques font recours à une architecture spéciale par rapport à d'autres orientée gestion de données.
Les diagrammes dont on parle sont montrés par la figure suivante :
Fig V.4 : Symboles de modélisation en UML
3. Cahier des charges
Le cahier des charges est un document avec lequel le client demandeur présente sa requête afin qu'il puisse être exhaussé par une réponse et dont il définit le problème posé et
les conditions et contraintes pouvant surgir ou limitant le nombre de degré de liberté. Il définit clairement et d'une façon objective Les acteurs, Les administrateurs, les rôles et les services. Il y est aussi une mention des délais de réalisation et les coûts en pratique.
4. Le `Use Case Diagram' ou UCD
Décrit la fonctionnalité que le système délivre à ses utilisateurs (humains ou système), et les liens entre eux. Pour cela, on définit :
Use Case: séquence d?actions que le logiciel garantit. Il définit les besoins du client. Actor: rôle qu?un utilisateur joue dans le système
Arc: use/include, extends (options)
Fig V .5: Exemple du Use Case Diagram
Use Case Diagram de NMSS UCD Général:
Fig. V.6 : Le diagramme Use-Case décrivant l'architecture de NMSS
Ce diagramme demande à être expliciter niveau par niveau, en commençant du niveau premier représentant le module IHM (Interface Homme-Machine) par ses trois constituants;
Interface graphique VIEWPORT
Interface macro COMMANDE-EN-LIGNE Interface dialogue FROM-FILE
En deuxième lieu, vient le modèle réseau NETCHILD qui peut être transcrit en trois formes équivalentes et selon la nécessité (INSTANCE OBJET en mémoire, FICHIER XML sur disque ou MODELE GDI+ sur l'écran d'un ordinateur).
En parallèle, le modèle Méthode de calcul avec sa bibliothèque mathématique source des algorithmes à utiliser pour procéder aux différents calculs auxquels seront exposé les réseaux électriques. De leur organisation dérive l'aptitude extensibilité de la NAL (NAL : Numerical Application Library).
Un module expert s'ajoute à l'ensemble en tant qu'entité responsable de la gestion orientée IA de NMSS. L'intégration dans l'ensemble du module AIM sera détaillée dans les sections qui suivent.
L'USD du module IHM
Fonction : L'interface IHM est en mesure de procurer à NMSS une faisabilité qui permet à son utilisateur trois façons d'introduire son modèle réseau avec ses données. Les trois procédures sont totalement indépendantes mais ont à chacune la même finalité le modèle réseau NETCHILD, qui reçoit en tant qu'une instance, dérivant de la classe NETCHILD, en mémoire les définitions effectives de ses attributs sans aucun besoin de savoir de quelle partie du module IHM provient la donnée. Cette aptitude rend NMSS d'une grande aisance dans la manipulation des saisies des modèles réseaux.
La figure suivante (Fig.V montre clairement cette notion de navigabilité dans les données et représentation des réseaux en mémoire sous forme graphique, écriture XML ou une transcription résultat d'une séquence de macro-commandes issues du mode commande EN-LIGNE ou le mode SCRIPT PROGRAMME.
Fig. V : Le diagramme Use-Case du module IHM L'USD du module de gestion de la NAL
Fonction : Ce module est spécialisé dans la collecte de toutes les requêtes émanant des instances NETCHILD (instance réseau) pour but d'un lancement de calcul spécifique. Sa réponse, à l'égard de ces demandes serait un résultat sous forme d'un scalaire ou d'une matrice, qui sera exploité pour en tirer la donnée résultat en attente.
Une bibliothèque de routines mathématiques basées sur le BLAS (Basic Linear Algebra Routines) de l'Université du Tennessee, USA. Cette partie étant une partie intégrante du projet LAPACK/Netlib de l'"Institut of computer science du UTK", projet regroupant en une bibliothèque une foule de routines pour l'analyse et le calcul des systèmes linéaires contraints ou non, à variable complexe ou réelle.
Fig. V : Le diagramme Use-Case de la NAL
A cette bibliothèque s'ajoute un module de liaison et de gestion responsable de la réception des requêtes et l'envoi des réponses équivalents.
L'USD du module réseau NETCHILD
Fonction : C'est le module responsable de la gestion des instances objets NETCHILD de la classe de base. Le noyau instancie un objet pour être utilisé par la suite selon les trois formes; graphique, variable objet mémoire ou document XML sur disque.
Fig. V 9 : Le diagramme Use-Case du module MODELE RESEAU
L'équivalent mémoire "Instance Mémoire" une instance dynamique se trouvant en mémoire et héritant de la classe NETCHILD toutes les capacités de calculs et les aptitudes de manipulation et les possibilités d'échange et d'interaction avec les autres types d'objets tel que VIEWPORT, METHOD ou GRAPH (respectivement pour les objets canevas graphique, représentant d'un algorithme numérique de calcul ou le représentant en topologie des graphe du réseau).
Le "Document XML", est une forme écrite ans le langage XML (eXtented Markup Language) représentant une réplique exactement similaire à "l'instance Mémoire" et d'une grande souplesse permettant ainsi une facilité accrue pour le stockage du réseau sur le disque dur. XML est un langage bien connu par sa fiabilité de représentation des données, extensible, robuste et sans limitations. Une version encore plus poussée pourrait être utilisée en substituant à XML, c'est le langage XAML (eXtended Application Markup Language) introduit par Microsoft.
Le "Modèle Graphique", quant à lui identifie la possibilité qu'a la topologie des graphes à être utiliser en tant qu'outil de projection graphique dont les bases formeront un moyen pour dessiner un réseau électrique sur l'écran d'un ordinateur.
L'USD du module expert IA.
Fonction : Sur ce module qu'incombe la responsabilité de l'organisation des tâches émises par les différents autres modules et ainsi leurs réponses éventuelles. Le noyau de ce module est un moteur d'inférence auquel sont liées deux bases l'une dite de connaissances l'autre des faits.
Le module expert gère trois niveaux d'appel:
· Interaction avec le module IHM· Interaction avec le module Réseau
· Interaction avec le module NAL
Ce module représente réellement le noyau SIAD, système expert d'aide à la décision. D'après la théorie, un tel système doit regrouper trois parties essentielles, la base de connaissances, le moteur d'inférence et l'interface utilisateur (matérialisée par cette interaction avec le module IHM décrit plus haut).
Pour la base de connaissances, elle est formée de deux vecteurs de données, Une pour la base de règles l'autre pour la base de faits (règles non validées)
Fig
. Fig. V : Le diagramme Use-Case du module SIAD.
Dans ce cas, l'expert mentionné dans la figure Fig.V.10, représente l'échange d'informations entre un connaisseur du domaine en question et le système.
Le Class Diagram ou CD
Décrive la structure statique du système à l?aide de classes, paquetages, et relations. Les noeuds dans ce cas-ci révèlent les éléments suivants:
Tab. V : Symbolisme utilisé dans les CLASS DIAGRAM
Package Interface
|
|||
Alors que les arcs relatent les relations et leurs types entre éléments:
dépendance
· référence à des classes ou objets passés en paramètres
·
ou statiques («use»)
· relations entre paquetage
association
· navigabilité entre objets, message entre objets
· flèche est optionnelle
agrégation
· «has-a»
composition
· «has-a» avec responsabilité sur durée de vie généralisation
· héritage
|
||
Ainsi, les liens contiennent la multiplicité des objets associés
UC exemple: Cas d'un distributeur de boisson
Fig.V : Modèle exemple d'un Class Diagram Class Diagram du module IHM
La pierre maitresse et centrale dans ce module est la classe VIEWPORT, dérivant du
composant standard PICTUREBOX. En réalité, cette classe est utilisée pour son canevas graphique qui va recevoir les projections des modèles réseaux. Autour de cette entité, nous retrouvons les classes:
BARTOOLS : Bar d'outils instanciant un nombre de boutons utilitaires pour la manipulation des modèles graphiques des réseaux. Cette manipulation tient des appels de reformatage sur le canevas VIEWPORT aux différents appels de calcul.
CMDEDITOR: De cette classe, dérive un composant MEMOCMD, composant mémo standard auquel sont surchargé des méthodes objets de gestion spécifiques au réseau. Cette classe est responsable, en tant qu'interface HM, de la réception des commandes utilisateur afin de les remettre au module débogueur IHM pour que le résultat soit apparent sur le canevas VIEWPORT graphiquement.
MEMOCMD, est une classe fils de CMDEDITOR contenant les commandes émises par les utilisateurs d'une session
XMLEDITOR: Cette classe gère la translation du modèle graphique du réseau électrique vers une écriture script en XML et vice-versa. Ce contenu est adopter à une sauvegarde rapide et simple de l'équivalent du réseau sur le disque et par la suite à sa lecture et conversion en contenu graphique manipulable.
La structure XML bien connue pour sa souplesse et sa force de telle sorte que beaucoup d'environnement logiciel adopte XML comme langage de transcription de leurs fichiers de données. Dans le même contexte, Microsoft a introduit XAML, une nouvelle vision des choses, encore plus performante et avec plus d'envies pour des horizons meilleures qui revaloriseront les applications scientifiques à l'avenir. XAML, en tant que script de programmation, peut intégrer les données de tout type comme XML et en plus les traitements graphiques que peut subir l'entité manipulée. Cette dernière faculté ouvre la voie devant les gourmandises les développeurs dans le domaine des applications d'optimisation et spécialement en simulation.
XMLDOC est une classe fils de XMLEDITOR dont les attributs contiennent les données du réseau en étude.
CANEVASEDITOR: Cette classe, quant à elle, représente une hiérarchie qui prendra en charge le modèle réseau graphique. Dans ce cadre, la topologie des graphes est au centre de la méthodologie entreprise par ce composant pour permettre aux utilisateurs invités (NMSS est manipuler par deux types d'utilisateurs les uns dits ADMINISTRATEURS les autres INVITES.).
Le document, au sens de la méthodologie OMT est inscrit dans une structure classe appelé TOPOINFO, Topo pour Topologie et Info pour Information du réseau en étude.
Fig.V : Class Diagram du modèle IHM Class Diagram du module réseau
L'élément central pour ce diagramme est la classe NETCHILD d'où dérive des sous classes, à chacune une fonction bien précise. En plus des attributs de base d'une telle entité, un groupe de collection d'objets. Ces collections sont :
· BUSCONTAINER : ensemble de tous les noeuds introduits (modèle objet BUSCU) par interaction graphique, via un document XML ou par Macro-commande saisie dans l'interface appropriée.
· GENERATORCONTAINER : ensemble de tous les générateurs (Représentant centrale réellement ou GENCU en représentation objet) saisis jusqu'à lors.
· LOADCONTAINER : suite de toutes les charges, objet modèle LOADCU, introduites
· MESURECONTAINER : C'est tous les appareils de mesure, entité objet représentative MESURECU, introduits.
· BRANCHCONTAINER : Collection stockant les entités objets BRANCH matérialisant les lignes de transport pour un réseau réel.
Pour chaque collection, nous retrouvons le constituant relatif.
BUSCU: Classe de base pour simuler un noeud, jeux de barres sur un réseau électrique. Ses attributs pensés d'une manière flexible lui donne l'aptitude de l'extensibilité sans limite.
L'idée de base de laquelle, l'environnement a été développé selon un critère fondamental faisant abstraction à toutes les contraintes de programmation pour une extension éventuelle. Pour ce faire, sur l'objet CANEVAS du VIEWPORT les éléments qui peuvent pendre place se divisent en trois catégories. Cette différence est prise en considération dans le développement. Ces trois catégories sont :
· Composant infrastructure acceptant des appels de connexion de tout objet voisin.
· Composant élément pouvant émettre des appels de connexion à un composant infrastructure.
· Composant de connexion, responsable de la matérialisation de l'appel de connexion émis par un composant élément et accepté par un composant infrastructure.Par cette définition, il est clair que la classe BUSCU est de catégorie infrastructure, que la classe GENCU en est de la catégorie élément alors que la classe BRANCH est du type connexion.
Fig.V : Class-Diagram du module NETCHILD Class-Diagram du module NAL
Ce module intègre l'élément le plus important du point de vue de ce regroupement logiciel orienté objet et dont le cahier de charges prédéfinit comme composant de base. Pour répondre aux exigences interopérabilité entre ce module central avec les autres composantes logicielles de projection graphique, de représentation dans la mémoire d'une station de calcul ou de gestion de décisions SIAD, Ce composant fait appel à une hiérarchie à cinq niveaux objets.
La classe METHOD est au coeur de cette structure d'où s'associent une classe spéciale EXTMETHOD intégrée pour gérer la manipulation et l'exploitation des méthodes numériques externes, un ensemble de classes qualifiant la catégorie dite EMBEDDED METHODS CLASS DEFINITION (Méthodes intégrées au noyau) dont on cite la classe LFPMETHOD, la classe EDPMETHOD, la classe FITTINGMETHOD et la classe ANNEXEMETHOD et finalement à un classe modélisant le moteur d'inférence SE
Fig.V : Class-Diagram du module METHOD Class-Diagram du module SIAD
C'est un module principalement orienté SIAD, de ce fait, nous maintenant la hiérarchie qui stipule un montage fait autour d'un système expert dont le moteur d'inférence est relié à une base de raisonnement pour permettre une prise de décision automatiquement avec une précision adaptée. A cette base de raisonnement s'ajoute une autre base de connaissances collectant des connaissances caractérisées par catégories, par thème ou par profil selon les différents besoins de l'utilisation.
Ce module s'interfère avec trois autres modules composants, à travers leurs classes respectives, le système NMSS en l'occurrence les classes VIEWPORT, METHOD, NETCHILD.
Ladite interaction est apparente à travers les appels formater de requêtes de traitement de la part des trois classes pour un besoin d'inférence (dans les sens optimalité de recherche, courte distance, choix de méthodes numérique de calcul, gestion de conflits).
Le module SIAD, reçoit de la part des autres entités un message requête formaté incluant:
· Identification du demandeur
· Identification de la demande
· Données relatives à la demande
· Paramètres de la requêteLa réponse du module, bien sûr après traitement, comportera la réponse Formaté du module à la requête du demandeur.
Fig.V.15: Class-Diagram du SE
6. L'Object Diagram ou OD
Représente un exemple de class diagram avec des instances d?objets. Si un CD est une classe, un OD serait un objet. Dans ce cas les noeuds sont les objets et les arcs sont les relations qui existent entre les types d'objets.
Fig.V.15 : Object Diagram Type faisant réfóence de modèle descriptif des objets GenCU, BusCU, Branch
7. Sequence Diagram ou SD
Ce type de diagramme établissent le lien entre Use-Case et Class-Diagram et décrivent l?échange de messages entre classes Les éléments de gestion dans ce type de diagramme sont :
· Classe rôle : représentant les classes en interaction en définissant clairement les rôles relatifs.
· Ligne de temps : simulant les activités passer en revue par rapport au temps.
· Message : définit l'échange de messages en objets en interaction
Exemple d'un SD, cas de la saisie d'un réseau (séquences simplifiées)
Fig.V .16 : Le Sequence-Diagram du cas de la saisie du modèle graphique d'un réseau
8. Le Collaboration Diagrams
Ce type de diagramme décrivent les échanges de messages entre classes, et définissent les associations
·
· sémantiquement équivalents aux sequence-diagrams, mais ...· les sequence-diagrams illustrent l?ordre des événements alors que les collaboration-diagrams représentent les interconnections entre objets et sont visuellement différents, ils mettent en intéraction les composantes suivantes:
o Class-roles: objets participant à l?interaction
o Liens: instances d?associations
o Messages: envoyés le long des liens
9 . Implémentation
L'implémentation des ressources objets dans une seule entité logicielle nécessite un effort supplémentaire. L'environnement de développement utilisé dans ce cas est le Visual Basic 2005 Express version standard de Microsoft.
L'outil de Microsoft VS2005 est centré essentiellement et conçu autour de la
bibliothèque FRAMWORK 2 (WinFX2), ensemble d'APIs (Application Programming Interface) intégrant un moteur graphique puissant le "GDI+".
Les milliers de lignes de code de l'application ont été répartis sur un ensemble de bibliothèque de liens dynamiques afin d'alléger la capacité du programme principal et de donner une souplesse durant le chargement/déchargement dans ou de la mémoire.
La flexibilité escomptée de la composition des objets est validée de telle sorte que l'instance doit jouer des rôles différents. De cette manière l'application demandera une attention additive pendant le développement mais une compacité élevée en mode exécution (runtime).
Quelques figures prise en capture des services implémentés
Fig. V : Fenêtre principale avec légende
L'objet "NetChild" est une instanciation de la classe NetChild qui hérite de la classe de base Network, celle-ci identifie le modèle réseau. Graphiquement, une image visuelle de l'instance NetChild (Fig V apparaitra dans une fenêtre fille cliente dans la zone cliente de l'interface principale (Fig V
Fig.V.18 : Fenêtre enfant --document réseau
L'application NMSS présente une accessibilité répondant aux critères des biens connus des interfaces homme-machine. L'accès à chaque fonction peut se faire de plusieurs façons (menu, barre d'outils, commandes en ligne, script)
Fig.V .19 : Accessibilité dans NMSS (Menus, barres d'outils, Aide)
La fenêtre cliente (contenu dans la zone cliente) présente quant à lui des possibilités de manipulations
Fig.V .20 : Fenêtre avec réseau noeuds saisi
Remarquer la fenêtre de capture à gauche servant de zone Snapshot (capture) montrant l'allure générale du réseau saisi.
Fig.V .21 : La même que précédemment mais vue selon la topologie des graphes.
Elle présente le graphe Gn(p,l) correspondant.
Fig.V.22 : Fenêtre réseau en mode tableur, Affichage de la matrice V
Les résultats sont affichés dans des composants grilles rattachées à la même fenêtre donc une dépendance totale des données des réseaux traités en parallèle pendant la même session
Fig.V .23 : Fenêtre réseau en mode tableur, Affichage du vecteur V nodal
Les caractéristiques et paramètres de n?importe quel composant pris en considération dans cette version peuvent être mises à jour à travers des boites de dialogues rapidement reconnaissables par leur barre de titre et les messages d?aide qui s?affichent automatiquement.
Fig V.24 : Boite de dialogue Paramètres du réseau
Fig. V.25 : Boite de dialogue de Paramétrage Noeud
B0Fig. V.25 : Boite de dialogue de Paramétrage Ligne
L0
Fig. V.25 : Boite de dialogue de Paramétrage Fig. V.25 : Boite de dialogue de Paramétrage
Charge C0 Générateur G0
Des assistants de suivi du calcul s?affiche automatiquement une fois le calcul est réglé sur mode ASSISTANT. Ce dernier composant est polyvalent dans le sens où il est utilisé pour différentes situations de calcul.
Au cas où le mode choisi est différent de ASSISTANT' d?autre scénarios peuvent avoir lieu permettant ainsi à l?utilisateur de NMSS d?initier un calcul donné par:
· COMMANDE EN LIGNE : à travers la console
· SCRIPT : utilisant le langage script NMSL (Network Modeling and Simulating Langage) de NMSS
· AUTO : Re-Calul automatique selon une périodicité fixée par l?utilisateur
· A LA DEMANDE : Le calcul fixé est demandé par un choix dans le composant comboBox?
Fig. V : Boite de dialogue de Paramétrage Assistant calcul (Dans ce cas par la méthode de Gauss-Seidel)
Les essais faits sur NMSS appelle à intégrer des modifications suivies de modifications. Afin d?augmenter la maniabilité et la manipulabilité des modèles réseaux visuels, nous étions contraints d?adjoindre à chaque fenétre NETCHILD, d?autres composants de contrôle tel que le ZOOM, le MODE D? AFFICHAGE, l?ACCESSIBLITE ou la représentation des résultats.
Fig. V.26 : Panneau de contrôle de la fenêtre NETCHILD (réseau)
Fig. V.27 : Boite de dialogue de réglage des paramètres du moteur d?inférence et de le
personnaliséDifficultés et problèmes rencontrés dans NMSS
Comme tout autre environnement logiciel, NMSS présente un certain nombre de carences Passibles d?être résolues dans les versions à venir, Elles touchent dans la plupart le moteur graphique (Graphics Engine), entité bien connu dans la littérature que les efforts en temps et en lignes de code nécessitent de gros investissement.
Ces carences sont classées selon la liste suivante:
- Rafraichissement lent si le nombre de noeuds dépasse ; une
solution existe déjà sous NMSS, c?est la subdivision du réseau en région et l?allocation des composants du réseau de base de la caractéristique CHILD en position TRUE, se qui donnera faculté de rendre ce même composant père pouvant imbriquer toute une structure NETCHILD (Fig V.27)
- Limites des hypothèses sur lesquelles sont basés les composants modèle réseau.
- Inexistence de bibliothèque des normes standards
- Gestion globale et propre des exceptions
Fig. V.27 : Réseau IEEE de noeuds
Référence bibliographique
[ . Rod Stephens; Visual Basic® Programmer?s Reference?; ISBN-13: 978-0-7645-
7198-5; Copyright (c) 2005 by Wiley Publishing, Inc; 2005- -
[ . P Bembey, K Kaur ; ? Visual Basic NET Professional Projects?; Premier Press (c) 2002 (1007 pages); ISBN: 1931841292; 2002
[ . P.H. Sherrod; NLREG Nonlinear Regression Analysis Program; www.nlreg.com, Copyright (c) 1991 --
[ . M Dorigo; The Ant Colony Optimization Metaheuristic : Algorithms, Applications, and Advances? ; Technical Report IRIDIA- - ;
[ . S. Clark, ; VBScript Programmer's Reference? ; Wiley Publishing, Inc; ISBN: 9,
[ . J. Gregory Rollins & Peter Bendix; Computer Software for Circuit Analysis and Design?; «Computer Software for Circuit Analysis and Design»; The Electrical Engineering Handbook; CRC Press LLC, 2000.
Conception et Intégration du Module Expert
Un système expert est une application logicielle composé de deux entités :
- Une base de connaissances qui a été enrichie par un cognitien (spécialiste humain dans le domaine de compétence concerné)
- un moteur d'inférence constitué d'un algorithme logiciel qui analyse les faits d'un problème à l'aide de la base de connaissances. Cet ensemble est nommé système expert ; il est capable d'établir des diagnostics à partir des faits que l'on peut détecter dans la description d'un problème.
Un système-expert est un outil informatique d'intelligence artificielle, conçu pour simuler le savoir-faire d'un spécialiste, dans un domaine précis (Les réseaux électriques par exemple) et bien délimité, grace à l'exploitation d'un certain nombre de connaissances fournies explicitement par des experts du domaine.
Il permet de modéliser le raisonnement d'un expert, de manipuler des connaissances sous une forme déclarative, d'en faciliter l'acquisition, la modification et la mise à jour et de produire des explications sur la façon dont sont obtenus les résultats d'une expertise.
Dans des domaines d'utilisation comme la géographie ou la gestion de l'espace, un système-expert peut être un outil d'aide à la décision puisqu'il permet:
de tenir compte de variables, à la fois quantitatives et qualitatives pour établir la base de connaissances, de structurer le savoir de façon logique et de l'organiser pour construire un modèle de simulation, et de proposer des réponses de type prospectif.
Son utilisation est indépendante de la connaissance qu'il renferme de manière à être utilisable par des non-experts dans le domaine de la connaissance ou la technique de modélisation. En revanche, la spatialisation des phénomènes n'est pas explicitement prise en compte.
L'architecture est caractérisée par :
- Une base de connaissances représentant à la fois du savoir-faire et l'expertise nécessaires pour résoudre un problème. Les unités de raisonnement s'écrivent sous la forme de règles libellées de la façon suivante : si "situation" alors "action" situation correspond à l'hypothèse de la règle et action à la conclusion
- une base de faits, mémoire renfermant à tout instant les informations connues sur le problème en cours, qui s'enrichit au fur et à mesure par les réponses de l'utilisateur, un moteur d'inférences constitué par les algorithmes chargé d'exploiter les connaissances et les faits pour mener un raisonnement. Il exploite les connaissances en effectuant des déductions logiques et, à partir des mêmes hypothèses que les experts, propose des résultats identiques, deux interfaces indispensables à la bonne communication homme-machine (l'une facilite le dialogue avec l'utilisateur en
cours de session, l'autre permet à l'expert du domaine de consulter ou d'enrichir la base de connaissances du système).
Le fonctionnement dépend du moteur d'inférences qui choisit, en fonction de la situation courante décrite par la base de faits, les connaissances de la base à utiliser et leur enchaînement; il construit lui-même le raisonnement adapté au cas particulier qu'il doit traiter en répétant un cycle détection de règles pertinentes/choix parmi ces règles de celle à utiliser/déclenchement de cette règle.
La définition des règles pertinentes dépend des algorithmes de résolution inclus dans le moteur ; les plus couramment utilisés sont le chaînage avant (partant des faits pour en rechercher les conséquences) et le chaînage arrière (partant des conclusions envisagées pour vérifier si les conditions sont réunies).
Fig. VI.1 : Place du système expert dans le système décisionnel
Et cheminement de l'information ( ) Expert -> (2) Système expert et (3) utilisateur.
Fig. V.2 : Architecture d'un système expert
Classe NMSS.SE (système expert)
Comme il a été décrit dans le chapitre architecture, NMSS, intègre une classe NMSS.SE responsable de la communication entre les différentes entités du logiciel (IHM, calcul ou décision).
Fig. VI. : Place du module expert dans NMSS.
Fig. VI. : Object Diagram OD de la classe NMSS.SE et son interaction avec les autres
classes.
Conception et Intégration du Module Expert
Toutes les autres classes faisant référence à NMSS.SE ont fait objet de re-modélisation afin qu'elles permettent le passage d'information en mode exécution (runtime).
Algorithme du moteur d'inférence
NMSS.SE marche selon une algorithmique d'adaptation selon le cas. En faisant abstraction à la nature de toute autre entité logicielle. Le formalisme en vigueur dans ce cas est que tout est sujet de règles d'adaptation selon des scénarios prescrits.
En sachant la règle, ses conditions d'applicabilité et les manoeuvres inculquées par l'expert dans de telle situation, le moteur d'inférence implémenté prend cette stratégie en action pour inférer et présenter la décision possible demandée.
Beaucoup d'algorithme peuvent être implémentés en tant que règles d'inférence : - La logique floue
- Les réseaux de neurones
- Le recuit simulé
- Les algorithmes génétiques et évolutionnistes
- Les algorithmes de fourmis (Fig. V.5 - sujet d'une publication à LJS)
Fig. V.5: Choix dynamique de méthodes de calcul du LFP/EDP
Fig. V.6 : Base d'inférence utilisant les fourmis virtuelles pour décider
Fig. V.7 : Clase NMSS.METHOD qui fait référence à NMSS.SE
Fig. V 8 Modèle d'un système expert sous NMSS
Afin de surmonter des problèmes de dimension de la zone graphique susceptible de recevoir le modèle graphique, une solution est venue faisant des composants BUSCU, GENCU, LOADCU ou MESURECU, à la demande, des objets pères pouvant incruster eux même des réseaux complets donc un imbrication d'objets NETWORK (Donnée de NETCHILD) alors qu'ils sont fils d'un objet NETCHILD (Fig. V.9).
Fig. V.9 : Réseau IEEE standard de 300 noeuds
Intégration à NMSS
La figure Fig. V.10 montre un exemple d'intégration du module expert dans NMSS par rapport à l'objet NMSS.METHOD (moteur de calcul)
Fig. V.10 : Moteur de calcul de NMSS et sa relation avec NMSS.SE
L'insertion d'un module expert dans NMSS était faite au moment de l'étape conception qui nécessite une réflexion et préoccupation, à vue globale, de toutes les entités logicielles qui vont intervenir et s'interférer au niveau du formalisme global du logiciel.
Le module devait être à formalisme abstrait sans aucune liaison à une classe du logiciel, puisqu'il est utilisé par l'ensemble.
L'adaptabilité du module ou celle des autres objets du logiciel étaient au centre des difficultés rencontrées.
Quelques idées pour publication
· Accessibilité de NMSS.SE par scripts programme
· Compilation indépendante de NMSS.SE en format serveur Références bibliographiques
. C.Dang, M.Li, `A floating-point genetic algorithm for solving the unit commitment problem', European Journal of Operational Research- ,
. K.S. Swarup *, P. Rohit Kumar; `A new evolutionary computation technique for economic dispatch with security constraints'; Electrical Power and Energy Systems (2006) 273- .
. D.N. Jeyakumar b, T. Jayabarathi a & T. Raghunathan; `Particle swarm optimization for various types of economic dispatch problems', Electrical Power and Energy Systems 28 (2006) 36- .
. Yung-Chung Chang; `Genetic algorithm based optimal chiller loading for energy conservation'; Applied Thermal Engineering ( ) - .
. Du Zhengchun *, Niu Zhenyong, Fang Wanliang; `Block QR decomposition based power system state estimation algorithm'; Electric Power Systems Research 76 (2005) 86-9 .
. N.Zouros a, G.C. Contaxisa & J.Kabouris; `Decision support tool to evaluate alternative policies regulating wind integration into autonomous energy systems'; Energy Policy 33 (2005) 1541- .
. S.Yu, X.Qing & K.Chongqing; `Dispatch Liquidity Theory in a Deregulated Environment'; TSINGHUA SCIENCE AND TECHNOLOGY; ISSN -0214 18/23 pp 240-246; Volume 10, Number 2, April 2005.
. M. Basu; `A simulated annealing-based goal-attainment method for economic emission load dispatch of fixed head hydrothermal power systems'; Electrical Power and Energy Systems 27 (2005) 147- .
9 . G.Soo Janga, D.Hura, J.Parka, S. Ho Leeb; `A modified power flow analysis to remove a slack bus with a sense of economic load dispatch'; Electric Power Systems Research 73 (2005) 137- .
. S.Cook; `Domain-Specific Modeling'; Journal 9
· www.architecturejournal.net. Page 10- , 9 - 9, .. M.F.Nettles `USE OF COMPUTER SIMULATION IN SCHOOL FOODSERVICE'; Publication No. NFSMI-R21-95; December, 1995;
. C. Gershenson G., `Artificial Societies of Intelligent Agent'; Thesis in Computing Engineering; Mexico, 2001
Selon le cahier de charges il est postulé que le logiciel NMSS traite des réseaux électriques de dimensions variables, en permettant à travers une interface graphique conviviale et extensible, de procéder à des calculs relatifs au transit de charges et à la répartition économiques des puissances.
L'environnement logiciel devra répondre à une série de tâches dont on citera :
· Ergonomie du logiciel (Apparence, Mode de saisie multiple, calcul modélisable, Rapport et archivage)
· Possibilités de traitement de données à partir de sources
" http://www.ee.washington.edu/research/pstca/formats/cdf.txt" IEEE Common data format· Planification de traitements selon des scénarios préétablis
· Accessibilité par modes commandes, script NMSL et visuel
· Assistants visuels intelligents pour la programmation des tâches
· Extensibilité des bibliothèques de calcul par scripts externes.
Ergonomie du logiciel
Fig VII.1 : Fenêtre principale de NMSS
NMSS est une application travaillant en mode MDI (Modal Dialog Interface), La fenêtre principale (Fig. VII.1) représente un objet père au moment où les fenêtres qui s'installeront dans la zone cliente forment des objets fils (Objet NETCHILD, Fig.
VII.4). Ces fenêtre peuvent être soumises à des manipulations diverses.
Fig. VII. : Barres d'outils de principales, relatives à toutes les fenetres MDI
clientes
Un symbolisme graphique utilisé prend en compte, dans le cadre de cette thèse cinq composants essentiels, le noeud, Le générateur, la charge, le transformateur et la branche. Chacun de ces composants sont modélisé dans leur forme la plus ordinaire selon les hypothèses préalablement discutées dans les chapitres premiers.
D'autres composants peuvent prendre place dans le canevas d'un projet instancié, mais ne représentent que des outils utilitaires (Doc Microsoft Word, Adobe PDF ou l'objet BULLE d'information)
|
|||
Fig. VII.3 : Modèles graphiques des composants
(c)
Les objets autres la branche se définissent par une instanciation OBJET alors que l'entité ligne (branche) est dessinée utilisant les APIs Windows. Cette démarche nécessite une synchronisation continuelle par le moteur graphique (ce rafraichissement peut causer des ralentissements des dessins sur le canevas VIEWPORT et surtout si le réseau est grand). Le recouvrement d'une telle action ralentissante est le dessin en couche (Layer) ou l'écriture de module graphique en assembleur.
Fig. VII.4 : Fenêtre cliente
Chaque fenêtre NETCHILD, dispose d'un panneau de contrôle (Fig. VII.5) regroupant des composants de commandes telles que la zone de capture, les contrôles d'agrandissement/rétrécissement sans oublier les boutons de conversion spéciale nombre complexe
· algébrique
· Euler ou algébrique
· trigonométrique)
(a) (b) (d) (e)
(f)
Fig. VII.5 : Séquence de déplacement de composants sur le canevas de dessin
En cas de déplacement d'un composant Générateur ou d'une charge le module expert se charge de la détermination automatique du noeud de connexion (Fig. VII.7). La probabilité haute du rapprochement de l'élément en déplacement par rapport à un noeud est la condition donnant décision de liaison à un noeud au passage.
Dans le même contexte un fichier est lu et dessiné automatiquement, NMSS propose des points d'ancrage pour chaque noeud rendant ainsi possible le dessin d'un réseau à partir de fichier ICF (IEEE Common Format).
Fig. VII.6 : Dessin par NMSS du fichier ieee30buscdf.icf
Une mise en surbrillance est utilisé afin d'accroitre l'accessibilité à un composant donné (Fig. VII.7-a).
Fig. VII.7 : Panneau de contrôle d'une fenêtre cliente
Outre le panneau de contrôle, chaque fenêtre NETCHILD, est surplombée d'une barre d'outils composée de boutons dont l'utilité est directe pour les traitements éventuels des données numériques et graphiques du réseau simulé.
Fig. VII.8 : Barre d'outils spéciale client
Un réseau est dessiné dans le canevas VIEWPORT (fenêtre de dessin) avec toute l'aisance demandée. En s'appuyant visuellement sur les deux barres d'outils, de la fenetre principale et celle d'une fenetre cliente (Fig. VII.4)
Fig. VII.9 : Fenêtre cliente -- Cas du réseau IEEE 5 noeuds
(a) (b) (c)
Fig. VII. 10 : Fenétres propriétés du générateur G0 (a) d'un noeud B0 et d'une ligne
L0
3. Possibilités de traitement de données à partir de sources IEEE Common data format
Sous NMSS, les fichiers de données en format CDF peuvent être traités avec la seule condition que le nombre de noeuds ne dépasse la valeur 60. Avec NMSS, ces fichiers ont l'extension ICF (*.icf) et sont explicitement la conformité totale par rapport au standard `IEEE Common data format'.
Fig : VII. 11 : Dessin du réseau IEEE 57 noeuds
Réseau IEEE57cdf.txt (Téléchargeable à partir du site du département de génie électrique de l'université de Washington
" http://www.ee.washington.edu/research/pstca/pf57/ieee57cdf.txt"
Le dessin est généré automatiquement par NMSS sans aucune intervention externe, le module expert intervient pour repartir les noeuds selon des conditions et règles de proximité existant dans sa base de connaissance. L'utilisateur n'aura qu'à ajouter son emprunte en fin de dessin afin décider le cas le moteur expert est dépassé.
Selon un coefficient de foisonnement la fenêtre graphique actuelle illustre mal des nombre de noeuds dépassant la soixantaine.
Tab. VII.1 : Tables décrivant le contenu du fichier texte équivalant au réseau 57
noeuds (Ligne internes arbitrairement supprimées)
|
|
|
||||
|
|
|
||||
|
|
|
|
|||
|
|
|
||||
|
|
|
|
|||
|
|
|
||||
|
|
|
||||
|
|
|||||
|
|
|
||||
|
|
|||||
-999
BRANCH DATA FOLLOWS 80 ITEMS
9
9
9
9 9
9
9 9
-999
LOSS ZONES FOLLOWS 1 ITEMS
1 IEEE 57 BUS
-99
INTERCHANGE DATA FOLLOWS 1 ITEMS
-9
1 8 Clinch Rv V1 0.0 999.99 IEEE57 IEEE 57 Bus Test Case TIE LINES FOLLOWS 0 ITEMS
-999
END OF DATA
Planification de traitements selon des scénarios préétablis
NMSS préconise le fait que l'accès aux fonctionnalités multiples de manipulation de calcul ou d'édition à partir de fichier script. Cette dernière méthodologie permet d'imaginer des scénarios diverses.
Plusieurs scénarios peuvent être envisagés selon le besoin. Le choix d'un mode est accessible directement à partir de la barre d'outils principale (Fig. VII.2) et plus spécialement la barre CALCUL. Cette méme barre d'outil fait montrer les quatre boutons l'assistant EXPERT, suivi par celui du mode CONSOLE, le mode SCRIPT et finalement le mode A LA DEMADE (mode par défaut)
Sous le mode `A LA DEMANDE', la barre d'outils CALCUL (Fig. VII.12) représente, pratiquement le moyen d'accès le plus adopté (d'autre alternatives se présentent comme par exemple les raccourcis de clavier). Les calculs de base sont choisis arbitrairement de la liste. Par suite, les boutons EXECUTE, STOPPER, PAUSE sont utiliser pour respectivement lancer, arrêter ou interrompre le thread de calcul.
Deux boutons de navigation trouvent leur utilité dans le recouvrement des états ultérieurs ou passé du projet. Un bouton d'enregistrement est disponible pour stocker en mémoire (sur disque si nécessaire) les états du projet en cours.
Fig. VII.1 : Barre d'outils CALCUL
Exemple macros regroupées en fichier script batch :
Tab. VII.2 : Contenu d'un fichier script exemple
|
||
Ce contenu pourrait être donné ligne par ligne sous le mode console. Pratiquement toutes les tâches ont été conçue sous forme d'un module utilisable séparément se qui laisse le choix large dans la manipulation du réseau.
Le listing suivant évoque les actions suivantes :
|
||
La multiplication des modes dans NMSS lui procure une grande accessibilité. Le mode AUTO, une fois déclenché permet visuellement de suivre l'évolution sur les
changements survenant sur un composant du réseau cette aptitude est appelée TRACE. Pour assurer cette fonction, le composant MESURECU, une fois connecter à un noeud et configurer en conséquence donne continuellement les informations demandées.
Accessibilité par modes commandeä script NMSL et visuel
Une fois le mode CONSOLE activé, l'accessibilité de NMSS s'accroit de manière considérable. Ce mode ajoute une aide au développement de réseau en permettant d'interroger l'environnement par macro-commandes claires et faciles à apprendre.
L'élaboration du design d'un projet, avec toute la complexité qu'il peut faire apparaître, sur l'outil informatique nécessite un maximum de puissance et que le développement de la plate-forme soit axé sur l'accessibilité en tant qu'élément clé. La facilité d'interaction de l'interface graphique est d'autant plus/moins développée que les méthodes d'interaction sont multiples et variées.
Recevoir une macro-commande de la part de l'utilisateur incite le gestionnaire de traitement des chaines de caractères (String Parser) lié au moteur d'inférence à intervenir pour valider le passage de la commande à la procédure d'exécution. Les conditions à vérifier sont, par exemple, `Est-ce-que le nouveau projet existe et est bien ouvert?' si on envoi la requête ADDNODE ou CONNECT.
Le NMSL est langage de balises, les scripts écrits en NMSL, rependent aux critères algorithmiques base telle que l'affectation, les boucles ou les évaluations.
Fig. VII.1 : Activation de la fenêtre CONSOLE.
Fig. VII.14 : Menu déroulant de NMSS
Fig. VII.15 : Barres d'outils principales de NMSS
Fig. VII.16 : Barre d'outils attachée au projet instancié
Fig. VII.17 : Barre d'état de la fenétre fils NETCHILD
NMSS dispose de beaucoup d'outils rendant l'accès à une fonction quelconque du logiciel possible à travail les menus déroulants, les barres d'outils ou tout simplement l'intervention du logiciel sur le canevas de dessin.
Fig. VII.18 : Panneau de contrôle et de manipulation des composants.
Fig. VII.19 : Exemple de dessin normalisé d'un réseau 5 noeuds.
Assistants visuels intelligents pour la programmation des tâches
Des assistants de suivi du calcul s'affiche automatiquement une fois le calcul est réglé sur mode ASSISTANT. Ce dernier composant est polyvalent dans le sens où il est utilisé pour différentes situations de calcul.
Au cas où le mode choisi est différent de `ASSISTANT' d'autre scénarios peuvent avoir lieu permettant ainsi à l'utilisateur de NMSS d'initier un calcul donné par :
· COMMANDES EN LIGNE : à travers la console
· SCRIPT : utilisant le langage script NMSL (Network Modeling and Simulating Langage) de NMSS
· AUTO : Recalcule
automatique selon une périodicité fixée par l'utilisateur.· EXPERT : Le moteur expert
intervient en choisissant les méthodes à utiliser pour un calcul complet.· A LA DEMANDE : Le calcul fixé est demandé par un choix dans le composant `comboBox' relatif (automatiquement ou arbitrairement)
Fig. VII. : Boite de dialogue de Paramétrage Assistant calcul (Dans ce cas par la
méthode de Gauss-Seidel pour le calcul du transit de puissances)Les essais faits sur NMSS appelle à intégrer des modifications suivies de modifications. Afin d'augmenter la maniabilité et la manipulabilité des modèles réseaux visuels, nous étions contraints d'adjoindre à chaque fenétre NETCHILD,
Noeud
PG
QG
PD
QD
|V|
Type
d'autres composants de contrôle tel que le ZOOM, le MODE D' AFFICHAGE, l'ACCESSIBLITE ou la représentation des résultats (Fig. VII.21).
Fig. VII. : Panneau de contrôle de la fenêtre NETCHILD (réseau)
(b) (a)
Fig. VII.22 : Assistant de calcul dans deux situations (a) cas de la méthode GS, (b)
cas de la méthode Relaxation
Extensibilité des bibliothèques de calcul par scripts externes.
Le traitement des données selon le mode est un choix qui fait profiter NMSS d'une capacité d'extension énorme, vu que les entités objets dont NMSS se compose, prévoient tout redimensionnement ultérieur en mode exécution par un utilisateur final en ajoutant des scripts de calcul faisant extension de la classe NMSS.METHODE
En mode édition et développement, où l'architecture présentée accepte facilement sans aucune réécriture les mise à jours.
Etude de cas (cas du réseau noeuds standard IEEE)
Dans cette section, nous présenterons les résultats obtenus sous NMSS comparés si besoin est, avec d'autres résultats issus d'une application autre.
Cas 1
Procédure de calcul complet
Soit le réseau cinq noeuds/six lignes donné les tableaux suivants:
Tab. VII.3 : Tableau des planifications
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|||
Tab. VII.4 : Caractéristiques des lignes
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
||
|
|
|
|
||
|
|
|
|
||
|
|
|
|
||
|
|
|
|||
Résultats:
Etude comparative du transit de charge entre NMSS et trois autres logiciels industriels (comme PowerWorld), académiques (NFLUX3) ou de laboratoire (comme ANAREDE).
Tab. VII.5 : Tableau comparatif de valeurs issues du calcul des tensions Vn sous
différents logiciel confronté à ceux obtenu par NMSS
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|||
Image du réseau
Fig. VII.23 : Capture d'écran de NMSS traitant le réseau 5 noeuds/6 lignes. Avec NMSS, les tensions nodales sont obtenus par la méthode GS alors que pour les autres logiciels, c'est celle NR qui est utilisée.
Matrice admittance
Tab. VII.6 : Matrice admittance (pu)
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
||
|
|
|
|
|
||
|
|
|
|
|||
Vecteur Vn (Méthode utilisée de Gauss-Seidel)
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
Les puissances de transit Spq
Tab. VII. : Vecteur puissances transmises (pu)
|
|
|
|
|
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|||
Le vecteur des puissances nodales Sn
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|||
Les pertes SL
Tab. VII.9 : Pertes par transmission (pu)
|
||
Cas 2
Cas du réseau standard 300 noeuds (IEEECDF300BUS.txt). Ce réseau, par sa dimension, représente un défit pour NMSS en ce qui concerne la taille. Pour des raisons d'importation, NMSS doit, afin de donner une apparence graphique à ce document chose qui s'avère difficilement saisissable. Le moteur d'inférence retient parmi ces règles, une qui lui indique que :
Si le dimensionnement au cours du design s'avère impossible (le générateur de position des noeuds étant pas parfait et l'espace graphique limité ce qui rend difficile le placement des 300 noeuds sur un espace réduit). NMSS est conçu pour être portable donc utilisable sur n'importe quel ordinateur susceptible de répondre à un minimum de condition.
NMSS, intègre une procédure de discrétisation de grands réseaux en régions interconnectées. Pour se faire, NMSS, accepte l'implantation de chaque région sur un réseau fils (CHILD) Fig. VII.24
De cette manière, un grand réseau peut être dessiné au fur et à mesure avec NMSS. Pa défaut, pour le cas des fichiers *.icf de dimension dépassant les soixante noeuds verront leur canevas graphique désactivé avec toujours la possibilité de procéder à tous les calculs possibles. L'interaction avec les données se fait à travers la console des commandes en lignes alors les résultats des calculs seront affichés dans une grille.
Fig. VII.24 : Fenêtre NETCHILD avec un réseau à noeud imbriqué (COMPOUND)
Cas 3
Prise de décision en ce qui concerne le choix de méthode à utiliser 3, 7, 8, 9, 10
Fig. VII.25 : Organigramme indiquant le déroulement du calcul complet
Le problème est de type combinatoire [2] de ce fait si nous indiquons par:
· O(x): complexité algorithmique
· Nups: Nombre des sessions ultérieures l'algorithme a été utilisé.
· Nmiterpu: Le nombre maximum d'itérations obtenus selon l'algorithme.
· Kmax: la limite maximale des itérations.
· (mi): Filtre indiquons le fait que l'algorithme choisi est utilisé OUI ou non NON:
· Nalgo dimension limite du problème Pi que peut résoudre l'algorithme
· Algoj cet algorithme peut s'adapté au calcul de Pi
Pour une dimension Np de problème, la table suivante énumère la dépendance de l'algorithme par rapport aux paramètres du problème.
Tab.VII.10 : Dépendances des paramètres
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
||
|
|
|
|
||
|
|
|
|
||
|
|
|
|||
L'allure de la fonction empirique propose afin d'être utilise par le moteur d'inférence pour des besoins de décision:
Eq. VII.1
La fonction F(mi) définies le cofit de l'algorithme de la méthode utilisé selon un choix donné avec d'autre selon un niveau différent. Ce cas de problème, est un
exemple typique ou l'application de méthodes intelligentes telles que Le recuit simulé, les algorithmes génétiques 8 ou l'optimisation par colonies de fourmis [1]
Fig. VII.26 : Couple de figures montrant le problème de choix invoqué
Fig. VII.27 : Schéma unifilaire du réseau IEEE 5 noeuds exécuté sous NMSS
Tab. VII.11: Données expérimentales du générateur 2 en vue d'un fitting
|
|
|
|
|
|
||
|
|
||
|
|||
Tab. VII.12 : Données des lignes de transport
|
|
|
|
|
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|||
Tab. VII.13 : Tableau de planification
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
||
|
|
|
|
|
|
||
|
|
|
|
|
|
||
|
|
|
|
|
|||
Tab. VII.14 : Tableau des contraintes
|
|
|
|
||
|
||
|
||
|
||
Après résolution nous obtenons les résultats suivants
Tab. VII.15 Résultats calcul des tensions
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
||
|
|||
Tab. VII.16 : Lissage de courbes
|
|
|
|
|
|
|
|
||
|
|
|
||
|
|
|||
Tab. VII.17 : Niveau du calcul de la répartition économique des puissances
|
|
|
|
|
|
|
|
||
|
|
|
||
|
|
|||
La recherche par algorithme des colonies de fourmis 1, 2, 4, 5, 6, 11 donne Pour chaque niveau nous avons:
Tab. VII.18 : Méthodes utilisées
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|||
La combinaison de tous ces paramètres donne les résultats:
(GS)/(LSQ)/(SMP); (GS)/(PLA)/(SMP),...
Cette dernière suite représente les combinaisons possibles. Le coût du choix est onéreux en temps d'ingénieurs ou non adapté ce qui mène à utiliser une méthode selon un algorithme précis sans se demander une justification.
Travaux d'extension éventuels
Etant donné des hypothèses de simulation, à titre d'exemple afin d'expliciter l'idée de base.
Tab. VII.19 : Valeurs des paramètres pour les algorithmes données
|
|
|
||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
||||
Les résultats sont reportés dans le tableau Tab. VII.20.
Tab. VII.20 : Résultats donné par le moteur d'inférence
|
||
Ce qui signifie que le moteur d'inférence décidera pour emprunter le chemin (la méthodologie) suivant:
· -Méthode de relaxation pour le calcul de transit de puissance.
· -Méthode des polynômes de Lagrange pour le lissage des courbes des fonctions coût
· -Méthode de Lagrange matricielle pour le calcul de l'optimisation et la détermination des puissances générées économiques.
9 Conclusion
Les cas étudiés sont été reportés sans intervention ni correction afin de permettre de critiquer et valider NMSS et les résultats qui y sont issus.
Pour le CAS 1, les calculs sont faits la méthode de Gauss-Seidel à 10-9 d'écart comme valeur d'epsilon sous NMSS et avec celle de Newton-Raphson sous NFLUX3, PowerWorld ou ANARED, d'où les petites différences qui existent sont algorithmiques.
NMSS est le fruit de beaucoup d'années de réflexion, du fait qu'il représente en lui-même une amélioration de taille des projets menés en 1986 (PFE ingéniorat d'état) et en (1996 Thèse de Magister 12 ) sous la même direction du Pr. M. RAHLI.
Seulement, il faut dire que cette expérience (de plus de 20 ans) ne devra en aucun cas être sujette de rupture.
NMSS présente toutes les facilités escomptés d'un logiciel de son genre, une interface graphique, une console pour les commandes en ligne une palette d'outils contrôle permettant d'exécuter les scénarios intégrés ou possiblement implémentés.
Quelques idées pour publication
· Augmentation du taux demodularité en explosant le logiciel en module indépendant afin d'augmenter les capacités.
S Repenser le langage NMSL
? Traitement de cas de réseaux
de grande dimension
Références Bibliographiques
1 M.Dorigo, Optimization, learning and natural algorithms, Ph.D. Thesis, Dip Elettronica e Informazione, Politecnico di Milano, Italy, 1992.
2 S.Kazarlis, V.Petridis, P.Fragkou, Solving University Timetabling Problems Using Advanced Genetic Algorithms, 5th International Conference on Technology and Automation, October 15-16, 2005, Thessaloniki, Greece, Proceedings of the ICTA'05, p. 131-136, http://icta05.teithe.gr/.
3 T.Sum-im, W.Ongsakul, Ant colony search algorithm for unit commitment, IEEE International Conference on Industrial Technology, 2003, Vol. 1, 10-12 Dec. 2003 p. 72 - 77.
4 M.Dorigo, G.Di Caro, Gambardella L. M., Ant Algorithms for Discrete Optimization, Artificial Life, 5, 1999, p. 137-172.
5 M.Birattari, G.Di Caro, M.Dorigo, Toward the formal foundation of Ant Programming, Proceedings of Ant Algorithms: Third International Workshop, ANTS 2002, Brussels, Belgium, September 12-14, 2002, in Lecture Notes in Computer Science, Vol. 2463, 2002, p. 188-201.
6 Y.Semet, Y.Jamont, R.Biojout, E.Lutton, P.Collet, Artificial Ant Colonies and E-Learning: An Optimisation of Pedagogical Paths, HCII'03: 10th International Conference on Human-Computer Interaction, June 22-27, 2003, Crete, Greece, then Human-Computer Interaction: Theory and Practice (part 2), Vol. 2, Lawrence Erlbaum Associates, 2003.
7 T.Sum-im; "Economic Dispatch by Ant Colony Search Algorithm"; Proceedings of the 2004 lEEE Conference on Cybernetics and intelligent Systems Singapore, 1-3 December, 2004.
8 A.Bakirtzis, V.Petridis, S.Kazarlis; Genetic algorithm solution to the economic dispatch Problem; IEE Proc.-Gener. Transm. Distrib., Vol. 141, No. 4, July 1994.
9 T.YaICinoz, M.J.Short; Large-scale economic dispatch using an improved Hopfield neural network; IEE Proc.-Gener. Transm. Distrib., Vol. 144, No. 2, March 1997.
10 T.Yalcinoz, H.Altun, & U.Hasan; Constrained Economic Dispatch With
Prohibited Operating Zones: A Hop field Neural Network Approach; 1 0, Mediterranean Electrotechnical Conference, MEleCon 2000, Vol. I1 0-7803-6290- X/02000 IEEE.
11 Y.Li and Z.Xu; An Ant Colony Optimization Heuristic for Solving Maximum
Independent Set Problems; Proceedings of the Fifth International Conference on Computational Intelligence and Multimedia Applications (ICCIMA'03) 0-7695- 1957-1, 2003 IEEE.
12 M.TAMALI, `Conception d'un logiciel de modélisation et de simulation des
réseaux électriques', Thèse de Magister, Directeur de projet M.Rahli; soutenue en 1996.
TRAVAUX
D
E
'EXTENSIONS
VENTUELLES
Comme idées d'extension vers une nouvelle version de NMSS, nous estimons régler les problèmes reliés aux modèles du moteur graphique intégré à NMSS.
Selon le cahier de charges il est postulé que le logiciel NMSS traite des réseaux électriques de dimensions variables, en permettant à travers une interface graphique conviviale et extensible, de procéder à des calculs relatifs au transit de charges et à la répartition économiques des puissances.
L'environnement logiciel devra répondre à une série de tâches dont on citera :
· Ergonomie du logiciel (Apparence, Mode de saisie multiple, calcul modélisable, Rapport et archivage), le moteur graphique sera sujet d'une redéfinition afin de faciliter l'accés et d'augmenter l'accessibilité aux usagers.
· Possibilités de traitement de données à partir de sources IEEE Common data format et autres formats connus IEEE standard. La fonction `import', définira une fonction à part, permettant ainsi l'étude et l'interopérabilité de NMSS par rapport à d'autres logiciels, ESAP, DigSILENT, ESACAP, PSCAD ou même MATLAB.
· Planification de traitements selon des scénarios préétablis. L'élaboration de NMSS a pris en compte la conception modulaire ce qui permettra la réutilisabilité des modules. Ce concept permet d'appeler la fonction de calcul LFP une fois que le réseau a été saisi (CALCLFP) ou introduit ainsi, un ensemble de commandes écrites dans un fichier script batch feront le nécessaire en s'exécutant à tour de rôle. Le gestionnaire de chaines de caractères évoluera afin pouvoir traiter une gamme très large de commande/combinaison de commandes.
· Accessibilité par modes commandes, script NMSL et visuel; selon le chapitre `Méthodologie de conception des logiciels scientifique', l'accessibilité est une exigence. Travailler l'ergonomie de telle sorte que celle-ci permettra à l'utilisateur technicien une grande vitesse d'exécution de réseau de taille importante. Le design, peut, à priori être fait par le concours de toutes les méthodes sans restriction ni conditionnement ou préparation au préalable.
· Assistants visuels intelligents pour la programmation des tâches. Ces boites de dialogues utilitaires résument de la manière fonctionnelle une tâche en la
|
||
Ces évolutions seront, certes, introduites au fur et à mesure afin de bénéficier d'une garantie vis-à-vis de l'utilisation.
Entre autres NMSS, recevra une amélioration de l'interface graphique afin d'améliorer l'accessibilité. Dans ce cadre, le moteur graphique devra être redessiné en intégrant une nouvelle stratégie de programmation faisant profiter NMSS de la rapidité escomptée d'un logiciel de traitement des systèmes électriques.
Elargissement aux autres modes de données, cette aptitude fera gagner à NMSS le déploiement par rapport aux autres environnements de son genre.
Un site Internet sera réservé à NMSS permettant une grande portabilité par la disponibilité des mises à jour ou faisant objet d'aide en ligne.
L'adoption de la stratégie modulaire sera renforcée par l'intégration de moteur d'extraction de chaine de caractères (String Parser Engine) capable d'augmenter l'indépendance de NMSS vis-à-vis de toute bibliothèque compilée, mais seulement des scripts clairs et légers facilement modifiables.
Comme conclusion générale nous nous réservons le fait de dire que le développement d'une telle plate-forme a été pour nous une expérience très grande en matière de côtoiement même virtuel d'équipes mêlée dans le même cadre.
Etant Electrotechnicien de formation de base et informaticien par expérience, Ce projet était pour moi un défi à surmonter, à noter que les autres plateformes telles que DigSILENT de PowerFactory firme allemande ou ETAP d'Operation Technology Inc. firme Américaine, sont conçu par des équipes multidisciplinaire sous rayonnement de budget de développement énorme, chose qui n'existe pas pour l'instant en Algérie.
Dans toutes les conditions précitées directement ou indirectement, NMSS a émergé et en traitant les parties les plus pointues d'un logiciel de sa catégorie. Néanmoins, des bugs (erreur de développement) peuvent surgir incitant vers un blocage de l'application, tout de même une gestionnaire d'exception (erreur) est intégrer et une grande partie des erreurs a été corrigé.
Le développement dans le cadre des projets de recherches que nous menons en collaboration avec le LORE (Laboratoire d' Optimisation des réseaux électriques) suscitera une sensibilisation totale derrière la prise en considération dans des études diagnostique dans le cadre de projet de fin d'étude ou même de Magister. Une collaboration et échange données est aussi bénéfique, chose qui unifiera les idées et les horizons de tous travaux en communs entrepris.
Les parties les plus rudes dans un tel développement sont:
|
Par notre développement de la plate-forme NMSS, nous avons touché plus ou moins à chacune des tâches précitées.
Finalement, un support d'appui a été présenté, discutable certes, mais un apport modeste en son genre qui présentera une proposition parmi d'autre.
Logiciel ESACAP
Recommandations
Le projet NMSS (Network Modeling and Simulating System) est en Algérie un maillon parmi d'autres. Certes, beaucoup d'autres laboratoires de recherche à l'est (Les grande universités, Constantine, Annaba, Ouargla) ou l'ouest (les grande universités de l'ouest, USTO, Sidi bel Abbes), le nord (laboratoire d'énergie, CDER, Alger) ou le sud (laboratoire des énergies renouvelables, ADRAR), développent dans le même sens des environnements logicielles plus ou moins complets mais sans aucune information publiée.
Nous recommandons que l'unification des efforts en se mettons favorables pour une zone d'interférence commune (un consensus) de développement collaboratif qui fera de nos travaux et résultats une référence pourquoi internationale (comme le cas d'ESACAP développé par P. Stangerup et S. Skelboe pour le profit d'un projet européen pour l'espace - European Space Agency ESA en 1979 , ) en matière de logiciel de modélisation et de simulation des réseaux électriques.
Références bibliographiques
[ ]. A. Laursen, U. Fabricus, P. Stangerup, S. Skelboe, `Prediction of the thermal behavior of metal hydrogen battery cells', Final Report Danish Research Center for Applied Electronics, Hoersholm, 4 9 9
[ ., `Parallel Algorithm for a Direct Circuit Simulator', Proceedings of the th European Conference on Circuit Theory and Design, Sept 1991, Copenhagen, (Erik Lindderg Edt.), pp 314- .
Format du fichier de données selon spécifications
IEEE
(CDF - Common Data Format de IEEE)
|
Partial Description of the IEEE Common Data Format for the Exchange of Solved Load Flow Data The complete description can be found in the paper "Common Data Format for the Exchange of Solved Load Flow Data", Working Group on a Common Format for the Exchange of Solved Load Flow Data, _IEEE Transactions on Power Apparatus and Systems_, Vol. PAS-92, No. 6,November/December 1973, pp. 1916- 5 The data file has lines of up to 128 characters. The lines are grouped into sections with section headers. Data items are entered in specific columns. No blank items are allowed, enter zeros instead. Floating point items should have explicit decimal point. No implicit decimal points are used. Data type codes: A - Alphanumeric (no special characters> I - Integer F - Floating point Title Data First card in file. Columns 2- 9 Date, in format DD/MM/YY with leading zeros. If no date provided, use 0b/0b/0b where b is blank. Columns 11-30 Originator's name (A> Columns 32-37 MVA Base (F*> Columns 39-42 Year (I> Column 44 Season (S - Summer, W - Winter> Column 46-73 Case identification (A> Bus Data * ========== Section start card *: Columns 1-16 BUS DATA FOLLOWS (not clear that any more than BUS in 1-3 is significant> * Columns ?- ? NNNNN ITEMS (column not clear, I would not count on this> Bus data cards *: *Columns 1- 4 Bus number (I> *Columns 7-17 Name (A> (left justify> *Columns 19-20 Load flow area number (I> Don't use zero! *Columns 21-23 Loss zone number (I> *Columns 25-26 Type (I> * 0 - Unregulated (load, PQ> 1 - Hold MVAR generation within voltage limits, (PQ> 2 - Hold voltage within VAR limits (gen, PV> 3 - Hold voltage and angle (swing, V-Theta> (must always have one> *Columns 28-33 Final voltage, p.u. (F> *Columns 34-40 Final angle, degrees (F> *Columns 41-49 Load MW (F> *Columns 50-59 Load MVAR (F> *Columns 60-67 Generation MW (F> *Columns 68-75 Generation MVAR (F> *Columns 77-83 Base KV (F> *Columns 85-90 Desired volts (pu> (F> (This is desired remote voltage if this bus is controlling another bus. *Columns 91-98 Maximum MVAR or voltage limit (F> *Columns 99-106 Minimum MVAR or voltage limit (F> *Columns 107-114 Shunt conductance G (per unit> (F> *Columns 115-122 Shunt susceptance B (per unit> (F> * *Columns 124-127 Remote controlled bus number Section end card: Columns 1- - Branch Data *============= Section start card *: Columns 1-16 BRANCH DATA FOLLOWS (not clear that any more than BRANCH is significant> * Columns 40?- ? NNNNN ITEMS (column not clear, I would not count on this> Branch data cards *: Columns 1- 4 Tap bus number (I> * For transformers or phase shifters, the side of the model the non-unity tap is on Columns 6- 9 Z bus number (I> * For transformers and phase shifters, the side of the model the device impedance is on. Columns 11- Load flow area (I> Columns 13-14 Loss zone (I> Column 17 Circuit (I> * (Use 1 for single lines> |
|
|
Column 19 Type (I> * 0 - Transmission line 1 - Fixed tap 2 - Variable tap for voltage control (TCUL, LTC> 3 - Variable tap (turns ratio> for MVAR control 4 - Variable phase angle for MW control (phase shifter> Columns 20-29 Branch resistance R, per unit (F> * Columns 30-40 Branch reactance X, per unit (F> * No zero impedance lines Columns 41-50 Line charging B, per unit (F> * (total line charging, +B> Columns 51-55 Line MVA rating No 1 (I> Left justify! Columns 57-61 Line MVA rating No 2 (I> Left justify! Columns 63-67 Line MVA rating No 3 (I> Left justify! Columns 69-72 Control bus number Column 74 Side (I> 0 - Controlled bus is one of the terminals 1 - Controlled bus is near the tap side 2 - Controlled bus is near the impedance side (Z bus> Columns 77-82 Transformer final turns ratio (F> Columns 84-90 Transformer (phase shifter> final angle (F> Columns 91-97 Minimum tap or phase shift (F> Columns 98-104 Maximum tap or phase shift (F> Columns 106-111 Step size (F> Columns 113-119 Minimum voltage, MVAR or MW limit
(F> Section end card: Loss Zone Data ============== Section start card Columns 1-16 LOSS ZONES FOLLOWS (not clear that any more than LOSS is significant> Columns 40 ?- ? NNNNN ITEMS (column not clear, I would not count on this> Loss Zone Cards: Columns 1- 3 Loss zone number (I> Columns 5-16 Loss zone name (A> Section end card: Interchange Data * Columns 1-16 INTERCHANGE DATA FOLLOWS (not clear that any more than first word is significant>. Columns 40 ?- ? NNNNN ITEMS (column not clear, I would not count on this> Interchange Data Cards *: Columns 1- 2 Area number (I> no zeros! * Columns 4- 7 Interchange slack bus number (I> * Columns 9-20 Alternate swing bus name (A> Columns 21-28 Area interchange export, MW (F> (+ = out> * Columns 30-35 Area interchange tolerance, MW (F> * Columns 38-43 Area code (abbreviated name> (A> * Columns 46-75 Area name (A> Section end card: Columns 1- - Tie Line Data Section start card Columns 1-16 TIE LINES FOLLOW (not clear that any more than TIE is significant> Columns 40?- ? NNNNN ITEMS (column not clear, I would not count on this> Tie Line Cards: Columns 1- 4 Metered bus number (I> Columns 7-8 Metered area number (I> Columns 11-14 Non-metered bus number (I> Columns 17-18 Non-metered area number (I> Column 21 Circuit number Section end card: |
