Platform Independent Model (PIM)

Le PIM est par définition (Joaquin Miller et Jishnu Mukerji, 2003) un modèle indépendant de toute plateforme. Cette notion d’indépendance de plateforme est liée à la capacité du modèle à abstraire les caractéristiques d’une plateforme technologique particulière. Une définition assez générale de ce qu’est une plateforme est mentionnée dans (Joaquin Miller et Jishnu Mukerji, 2003): ‘’a platform is a set of subsystems and technologies that provide a coherent set of functionality through interfaces and specified usage patterns”.

MDA recommande l’utilisation d’UML dans la conception des modèles CIM, PIM et PSM. Le PIM, selon MDA, décrit la structure d’information du système. Dans ce cas-ci, le diagramme de classe UML est le plus adapté à construire le PIM (Aditya Agrawal et al., 2002; Krzysztof Czarnecki et Simon Helsen, 2006; Oksana Nikiforova et Natalya Pavlova, 2008).

Il existe dans la littérature quelques techniques permettant de guider la construction des diagrammes de classe, en l’occurrence, le GRASP (General Responsibility Assignment Software Patterns) (Larman, 2004). En effet, une des pistes intéressantes que nous avons explorées et qui permet de faciliter la création du diagramme de classe est l’utilisation du concept d’archétypes et des patrons archétype.

Sur ce dernier point, Jim Arlow et al., (Jim Arlow et Ila Neustadt, 2004) recommandent la génération du PIM en adaptant les patrons archétype tout en proposant quelques uns comme Party, Product, Inventory, Order, etc. Cette manière de faire est relativement facile et rapide en comparaison avec les méthodes traditionnelles de conception du diagramme de classe. Le processus d’adaptation des patrons archétypes à un domaine d’affaires particulier consiste, comme le montre la Figure 1.7 soit à ajouter de nouvelles entités au patron archétype soit d’en supprimer des entités, considérées comme optionnelles. De plus, si nous disposions du CIM, il pourrait guider le choix des patrons archétype les plus appropriés à la conception du PIM.

Figure 1.7 Adaptation du PIM au domaine d’affaires à l’aide des patrons archétype Avant de préconiser l’utilisation du concept d’archétype dans la conception du PIM, il est important de donner une définition du concept d’archétype.

Le mot archétype vient du Grec archetypo et signifie « original pattern ». Dans (Jim Arlow et Ila Neustadt, 2004), un archétype est défini comme « a primordial thing or circumstance that recurs consistently and is thought to be universal concept or situation ». En effet, c’est au psychologue Carl Gustav que revient le concept de l’archétype (Carl Gustav, 1981). Il le définit comme une structure de représentation qui provient d’expériences humaines communes (the collective unconscious) délimitant un thème universel, mais figurée sous diverses formes symboliques.

Un des aspects intrigants dans la définition de Gustav est celui de la variabilité : les archétypes changent leurs formes afin de s’adapter à un contexte culturel spécifique tout en préservant leur sémantique. À titre d’exemple, l’archétype du méchant diffère d’une bande dessinée à l’autre et pourtant, le concept du méchant reste toujours le même, quelqu’un qui fait du mal et qui cause des ennuis à autrui.

Comme les archétypes sont des mécanismes structurant l’ensemble des processus psychiques de l’être humain et que celui-ci a été impliqué depuis des milliers d’années dans le domaine des affaires, il est tout à fait raisonnable d’observer l’apparition d’archétypes provenant de ce domaine. Par conséquent, il est possible d’en trouver des applications dans le domaine du développement de logiciels (Jim Arlow et Ila Neustadt, 2004). Par exemple, prenons l’activité de vente, une des plus vielles inventions humaines, qui en général, implique toujours le concept de produit, de prix, de vendeur et d’acheteur. Ceux-ci sont considérés comme des concepts fondamentaux (archétypes) et les relations entre eux mettent en évidence le concept du patron archétype. Par exemple, le prix et toujours associé à un produit.

Les systèmes logiciels reflètent le domaine d’affaires dans lequel ils opèrent. Il est ainsi possible d’en identifier des archétypes. Ces derniers sont appelés des archétypes d’affaires (business archetypes) et se définissent comme ‘’A business archetype is a primordial thing that occurs consistently and universally in business domain and business software systems’’. Un bon exemple d’archétype d’affaires est le Party qui peut prendre la forme d’une personne

ou d’une organisation et que nous pouvons identifier pratiquement dans tous les domaines d’affaires.

Le concept de patron d’archétype d’affaires (business archetype pattern) (Jim Arlow et Ila Neustadt, 2004) réfère au collaboration entre les archétypes comme dans le cas de la collaboration de Party, Product et Order.

1.11.1 Caractéristiques d’un archétype

Dans la modélisation objet, il existe une différence fondamentale entre les classes d’analyse et les classes de conception. Les premières représentent une abstraction du domaine de problème et les secondes ont des spécifications complètes à un degré tel qu’elles peuvent être implémentées. De ce fait, il est important de mentionner que les archétypes sont toujours situés à un niveau supérieur de celui des classes d’analyse. D’un point de vue conceptuel, les archétypes sont consciemment reconnus pour capturer des concepts universels, tandis que les classes ne s’intéressent pas nécessairement aux concepts universels. D’autre part, d’un point de vue technique, un archétype génère une ou plusieurs classes d’analyse (Jim Arlow et Ila Neustadt, 2004).

Par analogie, cette différence entre les archétypes et les classes d’analyse s’applique aussi bien à la différence entre les patrons archétype et les patrons d’analyse.

Arlow et al., (Jim Arlow et Ila Neustadt, 2004) ont présenté quatre caractéristiques spécifiant le concept d’archétype dans le contexte du domaine logiciel :

• Universal doit se produire continuellement dans le domaine d’affaires;

• Pervasive se produit à la fois dans le domaine d’affaires et dans le domaine logiciel. Celui-ci, est le principe de la convergence décrit dans (David A. Taylor, 1995) et repris dans (Richard Hubert, 2001);

• Self-evident to domain expert qui n’est pas toujours le cas, mais demande parfois, de s’assurer que c’est vraiment un archétype.

Le terme archétype a été utilisé par Peter Coad (Peter Coad, Eric Lefebvre et Jeff De Luca, 1999) qui le définit comme ‘’a form from which all things of the same kind more or less follow’’. L’utilisation des archétypes de Coad reste similaire aux archétypes de Arlow.

Coad et al., (Peter Coad, Eric Lefebvre et Jeff De Luca, 1999), en se basant sur leur expériences de développement de logiciels, ont défini quatre archétypes : Moment-Interval, Party-Place-Thing, Role et Description. Chaque archétype est doté de responsabilités typiques. Les archétypes collaborent ensemble afin de proposer un modèle de classe d’analyse. Nous détaillerons dans le chapitre 4 les archétypes de Coad.