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.

Design pattern : Visiteur

Le pattern visiteur est, a mon sens, l'un des patterns les plus importants. Il est classé parmi les patterns comportementaux mais de par son utilisation, il est aussi un pattern structurel.

Le premier intérêt du pattern visiteur est de permettre de découpler les comportements des structures des objets surtout si les comportements ne sont pas tous définis et doivent être extensible. La logique métier est définie a coté de la structure objet stockant les données. A noter qu'en règle générale, cette démarche est a proscrire en POO... sauf, sauf, sauf dans ce cas. Oui le pattern visiteur est fait pour ça, il sépare les préoccupations.



Deuxième intérêt, s'il ne s'agissait que de découpler les aspects comportements et structures, certains avanceront que l'on peut s'en passer....  Sauf .. qu'en fait le visiteur ne vient pas qu'avec cette capacité. En effet, le visiteur a aussi pour but (du fait de son besoin de visiter son objet visitable) de permettre l'appel a d'autres visiteur en faisant le parcours de ses dépendances. Avec cette capacité, le pattern visiteur acquiert le status d'iterateur (Actif) sur un parcourt de graphe, a choisir, le visiteur offrira bien plus de souplesse que l'iterateur.

Ainsi, dans son fonctionnement, le visiteur vient avec une interface Visitable qu’implémentera son client. Cette interface définit la méthode accept prenant en paramètre nos visiteurs. Cette méthode une fois implémentée appellera la méthode visit du visiteur en se passant en paramètre afin de donner a celui-ci toutes ses capacités publiques accessibles ou privées via un peu de reflexivité.

A noter que le pattern visiteur implique cependant une contrainte que la structure a visiter soit suffisamment stable de façon a ne pas avoir une double ration de maintenance a faire dans le cas de modification sur le modèle objet.

Petit accident de moto et articles futurs

Vous l'avez peut être remarqué, ces derniers temps mes publications ont été moins nombreuses. J'ai eu quelques soucis, en fait un accident de moto en allant au travail la semaine dernière. Bon rien de graves, quelques hématomes, inflammations, douleurs et entorses. Je survivrai mais entre les visites aux urgences, le médecin, les cabinets de radiologies, ça n'en fini pas.... et la fatigue n'aide pas a se concentrer.

Bref en tout cas, au delà que tout cela est pas forcement intéressant, je voulais revenir vite fait pour donner un petit avant gout sur les prochaines publications en cours de rédaction.

Alors prochainement je publierais dans le prolongement des publications précédentes sur un autre pattern qui lui est vraiment important: le pattern Visiteur.

Suite a cela, sachez que je prépare un article sur Maven qui est un pre-requis de base, en terme d'outil, au build Java mais aussi à d'autres langages. Nous en explorerons l'écosystème et le fonctionnement afin de nous permettre de poursuivre après sur un autre plus efficace Gradle.

Plus technique, je prépare un article sur Drools, le moteur de règles et système expert dont on ne refait plus la réputation (parfois considéré comme une peu trop complexe justement)

De façon plus théorique, enfin je vise prochainement un article générale sur la Modélisation comme j'ai pu le faire sur la comparaison des aspects fonctionnelles et des aspects techniques en me rapprochant de l'IDM.

Enfin en trame de fond, je prépare un ensemble d'articles traitant des technologies JEE : (JSP, JPA, Servlets, EJB, servers, etc...)

Aspects fonctionnels VS aspects techniques

Bien voici un article très terre a terre que j’écris sur les différences entre les aspects fonctionnels et les aspects techniques d'un sujet que se soit en informatique ou non.

Quelques définitions:

Aspects fonctionnels (le a quoi):

• Selon le larousse :  Qui est bien adapté à sa fonction, qui convient parfaitement à sa destination : Un mobilier fonctionnels.
• Selon Wikitionnaire: Relatif à la fonction : Le modèle fonctionnels décrit les actions du système.

Donc lorsque l'on parle d'un système quelconque, les aspects fonctionnels traitent des fonctions du système, c'est a dire ses capacités, les opérations auxquelles qu'il est capable de réaliser.

Aspects techniques (le comment):

• Selon le larousse : Ensemble de procédés et de moyens pratiques propres à une activité : La technique de l'aquarelle.
• Selon Wikitionnaire: Ensemble des procédés qu’on doit méthodiquement employer pour un art, pour une recherche, dans un métier. La technique d’un métier, d’un art, d’une recherche scientifique ou érudite.

De la même façon, lorsque l'on parle d'un système, les aspects techniques sont a rapprocher des moyens technologiques et procédures mises en œuvre dans le cadre du fonctionnement du système.

ATTENTION : nous parlons des aspects techniques intrinsèques au système et non aux aspects techniques permettant de donner vie au système. Ces dernières sont des techniques traitant d'un système de production du système faisant l’opération (fonctionnelle ici) de choisir les moyens techniques a mettre en œuvre pour faire vivre le système.

Différences et complémentarités

Donc lorsque l'on parle d'aspects fonctionnels et d'aspects techniques pour un système, en fait nous parlons des moyens mis en œuvre pour répondre a la problématique de fonctionnement du système, c'est a dire comment le système va-t-il faire pour répondre aux opérations souhaitées.

La dissociation des deux aspects est fondamentale pour plusieurs raisons car:

• le a quoi peut avoir plusieurs comment. (je veux me déplacer -> j'utilise une voiture ou un velo ou des chaussures)
• le comment peut répondre a plusieurs a quoi. (j'ai des chaussures -> je peux marcher ou courir )
• le comment peut être multiple pour le a quoi voir modulaire. (je veux traverser une rivière -> je peux utiliser un pont avec une voiture (ou a pied) ou un bateau et des rames)

Ainsi les aspects fonctionnels expriment le besoin mais les aspects techniques expriment la réponse a ce besoin (selon ce que l'on peut appeler contrainte fonctionnelles, par exemple de cout, de temps, de sureté, etc... mais c'est un autre sujet)

Ce qui est intéressant donc, c'est que les aspects fonctionnels et les aspects techniques peuvent être vu selon deux axes orthogonaux. Une liste de besoin, une liste de réponse technique et des périmètres de couvertures de l'un par rapport a l'autre. Ainsi, on peut juger de la qualité d'une solution technique. Selon l’interdépendance des aspects fonctionnels, il est possible d’identifier le nombre de solutions "indépendantes" mise en œuvre, leur duplicité, leur capacité a répondre a plusieurs besoins, etc... et donc d'identifier si un problème fonctionnel complexe va trouver une solution simple ou si un problème simple va trouver une solution technique complexe.

A noter qu'ici nous ne parlons pas d'abstraction, de framework, de généricité ou de tous autres méthodes/approches qui sont des façons d'aborder la conception d'une solution technique et non la caractérisation des solutions techniques possibles pour un ensemble d'aspects fonctionnels.