Python : Les classes et méta-classes

Un article, court celui ci pour explorer le concept de class dans python. ici rien de compliqué, l’approche est classique comme dans tout autre langage. On déclare un mot clef spécifique un nom, et on par sur une surcharge éventuelle des méthodes de base de la classe Object dont on dérive par défaut.

La classe

Ainsi sera par  exemple amener à surcharger une où plusieurs méthodes __init__ dont le rôle est l’initialisation de votre instance. A noter que cette instance est créée par la méthode __new__ qui elle n’est pas à surcharger (enfin on peut mais c’est pas bien) et qui est en fait le vrai constructeur de notre classe.

On notera au passage que l’on pourra distinguer deux types de méthodes, celles de classe comme __new__ au quelle la classe elle même est passé en paramètre et celle d’instance auxquelles c’est le nouvel objet fraîchement qui est créé qui va etre passé en paramètre.

La Veille Technologique

S’il fallait des raisons d’apprendre

La veille technologique est un processus incontournable aujourd'hui dans n'importe quel domaine et métier mais cette vérité est d'autant plus forte dans le monde de l'IT tant cet eco-système change vite et se transforme rapidement.

Les concepts changent, les processus changent, les technologies changent et tout cela en même temps et ne pas les suivre c'est s'exposer à devenir rapidement inadapté face, pour d'une part, à des besoins clients  en perpétuels évolutions mais aussi d'autre part à des exigences de performances qui doivent faire face a des enjeux de dimensionnement de plus en plus présent (comme avec l’essor du BigData et par extension du Machine Learning cette dernière décennie [1])

Ainsi ne pas faire de veille technologie, par extension, c'est s'exposer individuellement a l'inadaptation face à un marché de l'emploi qui lui aussi évolue vite. J'ai, moi même, comme j'en ai parlé dans mon article un peu auto-biographique [2], pu perdre a certains moment le fil de l'actualité du monde technologique et théorique. Ainsi selon mon évaluation (ça ne vaut que mon avis), aujourd'hui, si un individu s'endort pour quelques 2 a 4 années, alors le gap qu'il aura a combler sera pour lui équivalent a repasser une bonne année des études qu'il avait pu suivre lorsqu'il était étudiant!

Je n'imagine pas la masse de travail a faire si il s'endort plus longtemps car cela ne prend pas en compte bien d'autres phénomènes qui intervienne au delà de ne rien faire.

Un des premiers phénomènes est celui de l'oubli, après combien de temps parvenez vous encore a exploiter des connaissances que vous avez acquises quelques temps plus tôt? honnêtement? 1 mois? 3 mois ? 6 mois? 1 an? 3 ans? 5 ans? Bien sur ce qui est appris est globalement acquis, mais le temps est délétère et selon la manière que cette connaissance a été acquise, il en restera plus ou moins les bases au mieux et nécessitera des révisions.

Personnellement je pense que au delà 3 mois sans utilisation, une technologie nouvelle devra être révisé, et que pour une connaissance couramment utilisé, il faudra probablement 3 années d'inutilisations pour impliquer la nécessite d'une révision (si a ce moment la cette technologie ou connaissance est encore d'actualité!)

De plus, il existe des freins et des limites propres a l'hommes qui font qu'il est nécessaire de faire de la veille technologique régulièrement. Par exemple:

• les biais cognitifs (bais de confirmations, préjugé, culture, etc...) qui auront altérer notre lecture initiale des faits et qui dans le temps ne feront que renforcer un point de vue sur un sujet qui sera peut être complètement erroné [3]. La veille technologique permet d'apprendre a réviser son jugement et ainsi passer outre nos préjugés (nous évitant alors de passer a coté de sujet intéressant voir même important 
• le vieillissement est malheureusement un fait et comme on dit, parmi les génies, seuls ceux de moins de 40 ans ont réalisé des grandes choses et des bouleversements justifiant des changement de paradigme : il ne faut donc pas compter sur l'age pour nous aider a être plus performant. Pourtant, la veille technologique a l’intérêt, au delà du travail d'apprentissage de connaissances, d’entraîner le cerveau a réfléchir, a construire sa pensée, a imaginer, a se restructurer. 
• la confiance en soit, peut être un frein a la connaissance, et la veille technologique peut permettre de gagner en confiance et être plus capable de se mettre en avant sur des sujets.

Au delà de l'acquisition de connaissance brut, la veille est donc un indispensable, elle permet de se maintenir a jour de l'actualité mais aussi de maintenir ses sens en éveil, se maintenir prêt a relever de nouveau défi quitte a même aller sur des sujet non connus!  C'est même la peut être la partie la plus utile de la veille technologique, garder l'esprit aguerri a la réflexion et a la résolution de problématiques sans avoir peur de sortir de son cadre.

WWWWH

Maintenant que l'on s'est donné (de bonnes) raisons de faire de la veille technologique, regardons un peu du coté du WWWWWH [4] pour creuser les axes de cette démarche.

Why ?

Evidemment nous n'allons pas refaire la partir introductive de cet article mais restons pragmatique, pourquoi faire de la veille technologique? Plusieurs points de vue peuvent être aborder:

• Court terme : le besoin projet, c'est peut être ce qui est le plus pragmatique, pouvoir mettre directement en pratique ce que l'on apprend!
• A moyen terme : Assouvir de la curiosité mais aussi se maintenir a jour techniquement et aussi parce qu’il ne faut pas attendre qui que ce soit pour préparer l'avenir, sachant que ce sont probablement ces connaissances qui permettront d’accéder a certains autres types de projets
• A long terme : entretenir les connaissances, mais aussi alimenter la curiosité personnelle de façon a continuer a faire un métier qui nous passionne, un métier ayant du sens.

When ? Where ?

Inutile de dire que ce chapitre sera court! Tous le temps, Partout! Comme le disait Einstein (citation du livre d'Etienne Klein, le pays qu'habitait Albert Einstein [5]):

"L'essentiel dans l’existence d'un homme de mon espèce, réside dans ce qu'il pense et comment il pense, non dans ce qu'il fait ou souffre"

En substance, signifiant pour moi que peu importe le lieu et le temps pour quoique ce soit, l'essentiel est l'utilisation de sa pensée et la manière de la construire. Et autant cela n'engage que moi mais la veille technologique (tout apprentissage en fait) a un rôle structurant pour la pensée qui est important de développer.

What ?

La question du sujet de la veille technologique est compliqué. Il s'agit ici d'un élastique tendu au bout de lequel on trouvera d'un coté, les sujets d’intérêts et de l'autre les sujets utiles!

Toute la difficulté dans une carrière sera de réussir a reboucler cet élastique! On peut distinguer différents types de sujet:

• les sujets généraux ou transverses
• les sujets spécifiques ou ciblés

Les premiers auront généralement pour but de donner du sens a une activité de veille technologique. Ce seront donc des sujets plutôt de méthodologie, conceptuel, historiques, et ou posant un contexte. Nous sommes alors plus dans un contexte de vulgarisation.

Les second seront des ramifications des premiers en s'attachant a entrer dans l'intimité d'un aspect du domaine considérer. Il s'agira donc plutôt de sujets abordant certaines technologies, frameworks ou encore de sujets décortiquant une problématique données. Pour aborder ces points, il faudra généralement un certain bagage.

How 

La partie la plus intéressante! Comment réaliser sa veille technologique? Probablement en ne faisant pas faire n'importe quoi non plus! Il importe que ce travail d'apprentissage soit pertinent et efficace! 

Tout d'abord, passons en revu les basiques:

Il est évident qu'il faut avant toute chose identifier un sujet intéressant. On sait pertinemment que la capacité d'apprentissage sera directement conditionné par le taux d’intérêt qui sera alloué au sujet. Bien sur on nous dira:

"Parfois, certains sujets, même indispensable, ne sont pas intéressant! "

C'est vrai, parfois il faut effectuer des veilles technologiques sur des sujets peu ou pas intéressant parce que ce sont des choses déjà vu et qu'il faut alors réviser ou parce que simplement ce sont des pre-requis qui sont juste pas intéressant. Dans ce genre de situation, l’idéal est de coupler le sujet avec un autre pour lequel l’intérêt sera plus grand. Ainsi, l'utilisation du second sera un prétexte pour le premier. L’idéal est même que le second soit une technologie déjà un peu maîtrisée de façon a limiter la marche a gravir.

Une fois le sujet cerné, il importe d'identifier les bagages nécessaires pour l’appréhender. Autant commencer par le commencement! Cela mène à construire un programme pour sa veille technologique. Sans cela, le risque est de sortir du cadre du sujet que l'on souhaitait traiter, attiré par l'ensemble des sujets amont à celui ci, sans cela, le risque est de se retrouver, un mois plus tard, a finalement encore préparer la veille du sujet initial!

Apres il ne faut pas non plus être trop exigent avec soit même car parfois en vagabondant, on se découvre de nouveaux centres d'intérêts et de nouvelles choses a apprendre, c'est ca aussi la veille technologique, s'ouvrir a d'autres choses. 

Ainsi, il est bien de se planifier sa veille technologique mais pas trop afin d’être raisonnable et réaliste avec des objectifs atteignables! Cela évitera de se décourager et de perdre le rythme et finalement abandonné en pensant "je suis trop vieux pour ces conneries". 

Dans le cas ou il faut tout apprendre d'un sujet alors il sera préférable de se tourner vers des supports autres que internet de façon a avoir des sources plus englobante (on sera alors plus sur des sujet généraux comme ceux dont nous avons parlé précédemment)

Maintenant que l'on a cerner le sujet, et identifier les pré-requis, il va falloir trouver les moyens de s'informer. Bien sur la première approche est de se tourner vers internet. Effectivement, on y trouve beaucoup d'informations (peut être parfois trop) sous de nombreux formats:

• l'article les articles sont souvent un peu plus généraux et donne une vision d'ensemble de sujet spécifique
• la vidéo est un support un peu spécial, souvent pratique pour les sujets généraux car permettant de comprendre les tenant et aboutissant d'un sujet, par contre lorsqu'il s'agit d'entrer techniquement dans les sujets, cela devient plus compliqué a suivre et nécessite de jouer beaucoup avec le curseur d'avancement. Pas fan personnellement, je peux comprendre que d'autre y adhère plus facilement (que moi), question d'affinité.
• le tutorial est un article exclusivement dédie a la démonstration, très pratique pour acquérir une expérience, elle ne permet pas forcement par contre de comprendre les concepts sous-jacent contrairement aux article
• la présentation est un exercice délicat, elle doit marié un contenu intéressant et une bonne pédagogie. Elle apporte la possibilité de connaitre un point de vue spécifique peut être différent de sa propre compréhension et d’étayer le sujet avec l'interlocuteur. 
• le blog souvent très pratique car regroupant des articles ou des tutoriaux, il permettent d’acquérir une connaissance très précise sur un sujet ou d'une problématique
• la doc technique est exclusivement a réservé pour ceux qui ont déjà le bagage mais qui cherchent des détails ou qui sont dans une phase de POC
• le mooc est une formation en ligne mixant articles, tutoriaux et vidéos. Souvent a réserver a des vielles technologiques conséquente, quand on part de loin sur un sujet.

Enfin, dans les cas difficile ou trop conséquent, il faudra préférer probablement s'appuyer sur un livre de façon a avoir un support couvrant l'ensemble des problématiques dans un formalisme homogène et cohérent.

Nous n'avons encore pas vraiment parler d'outils ou de méthode (enfin si avec cette article) cependant, il me semble que la phase de construction de la connaissance est une étape intime et que si vous en êtes la c'est que vous avez déjà depuis longtemps appris a apprendre et que vous vous connaissez et savez comment optimiser cette phase d'assimilation et de compréhension.

Pour ma part, elle se réalise assez simplement:

• Identifications des sources intéressantes par une lecture rapide filtrante
• Relecture approfondi par une prise de note
• Synthèse général par quelques schéma (UML, Mindmap, ERA selon votre domaine de compétence et vos connaissances, nous verrons que cela sera utile par la suite)

Enfin suite a cela a priori, et c'est ce qui viendra en tête de tout le monde, il faut mettre en oeuvre ce qui est appris. C'est effectivement très important car au delà de nous permettre de comprendre les avantages et inconvénient d'une technologie, la mise en oeuvre permet aussi de consolider l'apprentissage en se confrontant aux lacunes de la compréhension que l'on a du sujet (prejugé, biais cognitif, etc...). 

La mise en oeuvre se réalise par un POC (Prove Of Concept).  Il va permettre de vérifier que la technologie offre bien les services qu elle annonce mais et surtout va permettre de savoir que l'on est capable de l'utiliser!

A ce stade alors on pourrait s'attendre à ce que le processus de veille soit a ce stade terminé... il n'en est rien, réaliser un POC est une chose mais le terme de la veille n'est pas cette phase. Finir correctement une veille technologique nécessite de transmettre ce qui a été appris.

Teach

Pour débuter ce paragraphe, je citerai Robert Heinlein :

"When one teaches, two learn" 

Oui, enseigner a d'autres ses connaissances c'est faire aussi de la veille technologique! 

Même si cela est fait très rarement par même ceux faisant de la veille technologique regulierement, la dernière phase d'un apprentissage quel qu'il soit est de démontrer sa capacité à restituer ce que l'on connait. Cela augmente significativement la maîtrise du sujet étudié pour les raisons suivantes:

• Mon directeur de thése citait souvent Nicolas Boileau (que je paraphraserai pas): 

"Ce que l'on conçoit bien s'énonce clairement"

• Faire une restitution des connaissances acquise impose de se confronter a la réalité de notre compréhension car en transmettant son savoir, on doit être en mesure de garantir celui-ci! Il faudra donc se pencher plus sur les détails de faire une préparation donnant du sens a l'ensemble, de la cohérence. 

• Impose, contrairement au POC ou la mise en oeuvre ne permet que de démontrer notre capacité utiliser une technologie, d'en avoir compris les tenant et aboutissant, les éléments pivots, etc...

Donc enseigner va permettre de consolider sa propre connaissance mais aussi d’être face aux choses que l'on aura oublié, a coté duquel il est possible de passer, les subtilités car heureusement, les gens auquel la restitutions s'adressent ne sont probablement pas complètement vierge de connaissances sur le sujet! C'est même du coup la l'occasion de confronter des idées et des points de vue.

Comment transmettre? A qui?

Alors du coup finalement vient la question de comment transmettre? et a qui? Il s'agit d'une question a laquelle chacun doit donner une réponse selon le contexte dans lequel il évolue et les sujets qu'il traite!

Tout d'abord le comment. De la même manière que certaines sources d'informations ont permis d’acquérir des connaissances, rien n’empêche de produire le même genre de support. Ça peut être un blog (comme moi) ou des vidéos (dans la mouvance youtube) mais il faut garder en tête l'objectif de ce travail, le support ne doit pas devenir non plus plus complexe a mettre en oeuvre que le sujet lui même! 

Apres c'est selon l'envies mais il faut garder une chose importante en tête, la veille technologique, c'est pour vous. Le succès de transmettre ses connaissances est un plus si des gens y ont appris quelque chose, ce qui compte c'est le travail de formalisation, consolidation qui a été nécessaire.

Se poser la question de à qui enseigner ses connaissances acquises lors de la veille technologique, c'est avant tout et surtout une question cherchant a positionner le profil de l'interlocuteur cible.

On peut en définir plusieurs types:

• le novice sur le sujet. Dans ce cas, la restitution de la veille technologique doit être très progressive, il s'agit de ne pas noyer l'interlocuteur. Cette approche progressive aura alors pour intérêt dans la veille technologique de démontrer la maîtrise globale et cohérente du sujet. On sera ici plutôt dans un exercice de vulgarisation.
• l'expert du sujet. Il faudra pour un public aguerri être très prudent. Bien poser les concepts du sujets et être précis dans les démonstrations. L’intérêt de ce public est d'imposer a votre discourt un certain degré de justesse dans ce qui sera présenté car la critique pourrait être cinglante en cas de grosse bévue. Par contre les échanges seront plus pertinent et enrichissant.
• l'inconnu. Ce sera l'interlocuteur le plus difficile, car faute de savoir se positionner, il faudra considérer un support de communication adapté au deux types d'interlocuteurs présentés précédemment.

Conclusion

Certains diront que la veille technologique est surement un indispensable mais qu'ils n'ont pas le temps. Effectivement, on a tous une vie en dehors du travail, cependant dans le monde de l'IT ou tout change très vite, on ne peut se satisfaire des formations d'entreprise pour se tenir a jour. De plus, la veille technologique est une activité complexe qui pour être efficace doit être mené régulièrement mais aussi avec de la méthode.

Dans cet article, a été présenté une approche (celle que je suis personnellement) permettant de mener cette veille tout en tachant de la rendre efficace au mieux. Elle consiste globalement a bien sur hiérarchiser les sujets mais aussi après en avoir pris connaissance et avoir fait une mise en oeuvre, a réaliser un travail de restitution.

Pour aller un peu plus loin, voici quelques articles et blog permettant de compléter et confronter mon point de vue [6], [7], [8]

Références

[1] Big data et Machine Learning, 2016, de Pirmin Lemberger (Auteur), Marc Batty (Auteur), Médéric Morel (Auteur), Jean-Luc Raffaëlli (Auteur)

[2] https://un-est-tout-et-tout-est-un.blogspot.com/2018/09/100-un-peu-dautobio.html

[3] http://www.psychomedia.qc.ca/memoire/2014-05-29/transformation-des-souvenirs
[4] https://un-est-tout-et-tout-est-un.blogspot.com/2017/12/qqoqccp.html
[5] Le pays qu'habitait Albert Einstein Broché – 19 octobre 2016, Etienne Klein

[6] https://www.camilleroux.com/2009/09/20/conseil-realiser-bonne-veille-technologique/

[7] https://linuxfr.org/news/methode-et-outils-pour-la-veille-technologique

[8] https://toiledefond.net/5-outils-pour-commencer-une-veille-sur-internet/

Bonne année 2018

Un article pas trop long pour vous souhaiter une bonne, belle et heureuse année 2018 et aussi pour faire une petite road map des articles en préparation.

Comme vous avez pu le voir; ces dernières semaines ont été un peu chargé et cela a ralenti le nombre d'articles, surtout que j'ai l'impression de plus me documenter que de produire (en terme de code ou de doc) du coup je ne publie qu'à la volée des choses sur lesquelles je tombe comme l'article des QQOQCCP ou sur les processus de dev ou quand je suis amener a faire des modifications dans ma prod perso (la je parle des deux sujets sur les dépôts et paquets Debian)

J'avais promis quelques articles comme Maven, la modélisation et l'IDM  (complété avec un article général sur UML) et c'est chose faite mais je ne suis pas parvenu a sortir ceux sur Drools ou Gradle. alors le second est passé complétement a la trappe car je voulais le faire a la suite de celui sur Maven pour lequel je prévois une suite... et pour le premier, et bien, bien que connaissant déjà Drools pour l'avoir utilisé régulièrement, j'ai voulu élargir le sujet au systèmes expert dans le but de nous amener a de futur article très intéressant portant sur l'Intelligence Artificiel. Cependant, la tache est conséquente et non seulement va nécessiter plusieurs articles mais demande aussi de réorganiser le plan.

Donc voila en résumé de ce début d'année je vous prépare les sujets suivant:

• un peu d'IA en commençant par le système expert suivi par Drools
• une suite pour Maven
• Gradle comme alternative a Maven
• et n'oublions pas les sujets JEE

Au passage j’espère que le petit écart en passant pas la theorie du control par supervision vous aura plus, j'ai pour projet de le compléter par un article sur les processus communicant et la vérification de modèle.

Voila une beau début d'année en perspective!

Ingénierie Dirigée par les Modèles

L'ingénierie dirigée par les modèles (IDM) [13], [16] et [17]  est un cadre méthodologique permettant d'unifier différents domaines. Elle permet cette unification grâce à l'utilisation importante de modèles (potentiellement exprimables suivant différents domaines) et des transformations automatiques entre ces modèles. L’IDM permet le développement plus souple et plus simple de programmes informatiques dans des contextes comme les IHM  ou les systèmes temps réels distribués.

Système d’étude

L’IDM définit la notion de système [13] comme étant l’entité étudiée dans le cadre d’un processus de modélisation. Un système est vu comme étant un ensemble d’entités en interactions décomposable en sous-systèmes. Cette décomposition amène à une relation de composition entre systèmes et sous-systèmes. Dans [13], comme illustré par la figure 48, trois types principaux de systèmes sont distingués permettant une première classification : les systèmes physiques, les systèmes numériques et les systèmes abstraits. Un système physique représente une entité physique concrète et observable sur lequel l’homme peut d’agir matériellement. Un système abstrait est une entité purement conceptuelle comme un objet mathématique (fonction, ensemble, etc.). Un système numérique est un système appartenant à la classe des objets informatiques. Cette liste n'est pas exhaustive mais elle a le mérite de mettre en avant les limites de la modélisation: le monde physique et le monde conceptuel.

Modèle

Un modèle est l’abstraction d'un système réalisé dans une intention et un contexte particulier. Un modèle doit pouvoir être utilisé pour répondre à des questions sur le système. Un modèle peut décrire ou spécifier un système. Dans le premier cas, le modèle doit respecter le système, dans le second cas, c'est le système qui doit respecter le modèle. La relation existante entre le modèle et le système est définie dans les termes de "est le modèle de" ou "est représenté par" comme illustré par la figure 49. Comme le système, le modèle est composé d'éléments qui sont les abstractions des sous-systèmes donc également des modèles.

Méta-modèle

L'IDM définit le contexte de réalisation de modèles par un meta-modèle. Le meta-modèle est le modèle d'un langage de modélisation qui est l'ensemble des modèles réalisables comportant des caractéristiques communes. Le meta-modèle a un rôle important dans la modélisation car il définit les règles de construction de modèles pour le domaine qu'il définit. Un modèle est alors dit conforme à un meta-modèle s'il appartient à l'ensemble des modèles modélisé par le meta-modèle. Cette relation de conformité est illustrée par la figure 50.

Le système, le modèle, le langage de modélisation et le méta-modèle peuvent être réunis au sein d'un même diagramme en faisant apparaître les relations de conformité, de modélisation ainsi que d'appartenance à un langage de modélisation (figure 51). Ce diagramme porte le nom de pattern "Step" dans [13].

Langage spécifique de domaine

Apres les notions de bases de système, de modèle et de meta-modèle, l'IDM offre une définition de la notion de Langage Spécifique de Domaine (DSL). Un DSL est un langage qui capture les aspects spécifiques à un domaine comme le ferait un meta-modèle. Un DSL intègre cependant plus que cela car il intègre la notion de sémantique.

Transformation de modèles

Une transformation de modèles définie par IDM est la modification d'un modèle suivant des règles définies au niveau de son méta-modèle. Les transformations de modèles sont de deux types, les transformations de modèles endogènes et les transformations de modèles exogènes.

 Les transformations de modèles endogènes sont des transformations sans modification du meta-modèle donc au sein d'un même langage de modélisation. Ces transformations sont généralement dues à l'évolution du modèle dans une exécution.

 Les transformations exogènes permettent le changement de meta-modèle auquel le modèle est conforme afin de passer d'un langage de modélisation à un autre. Ce changement de langage de modélisation permet de bénéficier des avantages de chaque langage ou d'automatiser un processus de développement, ce processus se décomposant en diverses étapes qui peuvent être: une étape de modélisation, une étape de vérification puis une étape de ciblage vers une plateforme spécifique. Le passage d'une étape à une autre se réalisant par transformation de modèles.

 Pour la réalisation des transformations de modèles, l'IDM propose un modèle de transformations, illustré par la figure 52, liant les différents éléments du méta-modèles de façon à établir des règles de correspondances. Ces règles, appliquées au modèle à transformer, vont permettre la réalisation d'un nouveau modèle conforme au meta-modèle ciblé.



Exemple:
Avec l'illustration de la figure 53, considérons un fichier XML de base de données contenant l'identité de Thomas ainsi que des informations confidentielles telles que son adresse. Pour l'affichage des informations non confidentielles en HTML, vient tout de suite à l'esprit XSLT afin de générer de l'HTML automatiquement. Dans le cadre IDM ceci est purement une transformation de modèle par filtrage des informations et par la réalisation d'une mise en page.

Conclusions

L'IDM offre un cadre unifié pour la réalisation et la manipulation de modèles grâce aux notions de meta-modèle, de langage de modélisation, et de relations de :
•    Modélisation entre le système et son modèle ainsi qu'entre le langage de modélisation et le meta-modèle.
•    Conformité entre le modèle et son meta-modèle.

 La notion de transformation de modèles donne la possibilité d'intégrer diverses technologies possédant leur propre langage de modélisation dans le but de réaliser des systèmes complexes et fiables par génération automatique de code, par vérification dans des domaines adaptés à cette tâche etc. L'IDM offre le cadre nécessaire pour la mise en place d'un processus visant le développement d'un système logiciel par transformations de modèles. La dernière phase de ce processus est le ciblage vers une plateforme d'exécution permettant de finaliser la réalisation du système logiciel. La définition d'une plateforme d'exécution doit donc être définie.

 References:

[13] J-M. Favre. J. Estublier, M. Blay-Fornarino; L'ingénierie dirigée par les modèles, 2006, Edition Hermes, Lavoisier, Paris.
[16] A. Rasse, J-M. Perronne, B. Thirion. Ingénierie dirigée par les modèles pour une conception fiable des logiciels de commande, 2005 IDM05, p 231-244
[17] A. Rasse, Approche orientée modèles pour la spécification, la vérification, l'implantation des systèmes logiciels critiques, à paraître (2006), Mémoire de thèse, Université de Haute alsace, Laboratoire MIPS.

UML (Unified Modeling Language) : Introduction

UML (Unified Modeling Language) est un langage de modélisation graphique destiné à visualiser, analyser, spécifier, construire des logiciels orientés objets [OMG10a, OMG10b]. UML est aujourd’hui considéré comme un standard autant dans le milieu industriel qu’académique. Il propose un ensemble de diagrammes afin de couvrir l’ensemble des besoins de modélisation potentiellement nécessaires à la conception des logiciels, ce qui le rend relativement complet et générique. Ainsi, au travers des 14 types de diagrammes (figure 2.4), UML permet de modéliser les aspects statiques et dynamiques des systèmes complexes et de couvrir la plupart des phases du développement logiciel (analyse, conception, implantation, déploiement, etc.).

• Les diagrammes des classes : permettent de visualiser l’agencement des concepts d’un système en représentant les classes, leurs rôles, leurs caractéristiques, les services qu’elles proposent, leurs relations (association, composition, etc.) et enfin leur organisation au sein de l’architecture du système logiciel. Ils permettant aussi de représenter des méta-modèles.
• Les diagrammes de communication : décrivent des configurations types en termes d’objets collaborant. Pour cela, ils permettent de représenter d’une part la configuration d’un ensemble d’objets et d’autre part les relations dynamiques entre ces objets.
• Les diagrammes d’états transitions : capturent le comportement des objets sous la forme d’un graphe d’états reliés par des transitions. Le franchissement des transitions se réalise à la suite de la réception d’un signal (appel de méthode, exception, etc.).
• Les diagrammes de cas d’utilisations : permettent pour leur part d’identifier les fonctionnalités d’un système et les conditions nécessaires à leur bon fonctionnement.

Ils font apparaître les éléments fonctionnels, les acteurs et les objets en interaction. UML s’est rapidement imposé pour la conception des systèmes logiciels, pourtant ce langage comporte un certain nombre de lacunes. En effet, il est souvent reproché aux diagrammes UML de posséder une sémantique ambiguë et/ou incomplète. Dans l’évolution qu’a connu UML, cet aspect du langage est devenu un concept : le point de variation. Ainsi, ce coté semi-formel permet au concepteur d’utiliser un langage offrant plus de flexibilité afin d’être étendu vers des contextes de modélisation plus spécifiques.

UML peut être étendu par de nouveaux concepts (à l’aide de stéréotypes ou de contraintes OCL). Une extension de la notation à un domaine spécifique est appelée aussi profil. Par exemple le profil TURTLE [AD05] et le profil ACCORD/UML [GMT04] proposent des extensions des diagrammes UML dédiés à la modélisation des systèmes temps-réels.

Voila un petit aperçu d'UML dans ses grandes lignes sans forcement rentrer dans les détails des diagrammes, nous y reviendrons.

Références:

[AD05] L. Apvrille and P. De Saqui-Sannes. Turtle : a uml-based environment for the codesign of embedded systems. In Proceedings of the 8th Sophia-Antipolis MicroElectronics Forum (SAME 2005), October 2005.
[GMT04] S. Gérard, C. Mraidha, F. Terrier, and B. Baudry. A UML-based concept for high concurrency : The real-time object. Object-Oriented Real-Time Distributed Computing, IEEE International Symposium on, 0 :64–67, 2004.
[OMG10a] OMG. OMG Unified Modeling LanguageTM (OMG UML), Infrastructure Version 2.3, http ://www.omg.org/spec/UML/2.3/ , Mai 2010.
[OMG10b] OMG. OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3, http ://www.omg.org/spec/UML/2.3/ , Mai 2010.