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
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ête
La 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
B0
Fig. 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.
