Introduction 2 I. Présentation de l’Institut Pasteur 3

III.Réalisation, implémentation et test d’un modèle de processus biologique dans RoseRT

A.Objectif du stage

L’objectif du stage est d’évaluer la pertinence des concepts et des méthodes des systèmes temps-réel, pour la description et la représentation des processus biologiques, en particulier, la prise en compte de la création dynamique d’objets, la modification du comportement d’un objet en fonction des messages émis par son environnement externe ou interne, le traitement d’évènements concurrents, synchrones ou asynchrones, etc.

A ce stade, il ne s’agit donc pas de comparer différents langages de modélisation temps-réel, mais de sélectionner, sur des critères explicitables, un outil parmi les quelques outils disponibles [notamment, Esterel (Esterel Technologies) et Rapsody (Ilogix)] qui permettent de conduire ce test.

Pour ce faire, nous avons sélectionné l’atelier de génie logiciel, Rose-RT (Rational Software), sur la base des critères ci-après :

1. 
   Utilise le langage UML qui fait l’objet d’un standard (UML :Unified Modeling language), élaboré par l’OMG (Object Modeling Group) ;
   
2. 
   Les spécifications du langage UML-RT (UML for Real-Time) sont détaillées dans de nombreux documents ;
   
3. 
   Les outils développés autour de Rose-RT sont dotés d’autant de fonctionnalités utiles et qui ne seront pas à développer (par exemple, le RunTimeSystem).
   
4. 
   Rose-RT s’appuie sur la modélisation graphique développée dans UML ; ces outils graphiques permettent de produire des descriptions qui pourront être « partagées » par des biologistes et des informaticiens. C’est d’ailleurs dans l’objectif d’assurer une meilleure adéquation entre la conception (modèle conceptuel) et le logiciel effectivement réalisé que ces outils graphiques ont été conçus.
   

Déroulement du stage
La première partie du stage a consisté à appréhender le modèle biologique. Pour cela nous nous sommes appuyé sur les recherches de Kurt W. Kohn (Annexe 5) qui à établit une carte moléculaire des interactions dans le cycle cellulaire des mammifères et le système de réparation de l’ADN ainsi que sur de nombreuses publications sur le sujet.
Notre unité étant en collaboration avec des informaticiens et des logiciens dans le cadre de l’ARC-INRIA sur les calculs de processus et la biologie des réseaux moléculaires, nous avons participé à plusieurs réunions et groupes de travail durant lesquelles nous avons présenté le cycle cellulaire, notamment ses régulations et les interactions protéiques.

Les principaux axes de recherche de l’ARC sont :

• 
  Axe 1: Définir une base d'exemples de processus biomoléculaires, ainsi qu'une taxinomie des problèmes ouverts en représentation formelle qui se posent dans la modélisation de ces processus.
  
• 
  Axe 2: Comparer différentes modélisations des mécanismes de la base d'exemples dans différents calculs de processus, à l'aide de critères correspondants aux points délicats du cahier des charges identifiés par l'axe 1
  
• 
  Axe 3: Proposer de nouveaux calculs de processus adaptés au domaine bio-moléculaire, et réaliser des implémentations prototypes.
  

Nous avons, parallèlement, contribué à la réflexion sur le modèle informatique et sa réalisation, à l’aide du logiciel Rational Rose RealTime, en compagnie de Nasser Kettani (directeur marketing de Rational Software) et de Camille Rosenthal Sabroux (Lamsade, Paris Dauphine). Ceci nous a permis d’avoir à une première approche du modèle, en essayant de trouver les solutions les plus en adéquation avec la réalité biologique. Cela nous a permis également de nous familiariser avec les concepts objets temps réel utilisés par Rational.
Un stage de formation chez Rational Software sur le sujet « Développement des logiciels temps réel avec UML et Rational Rose RealTime » nous à permis de maîtriser le logiciel et d’acquérir quelques bases en modélisation temps réel. A partir de ces connaissances, nous avons réussi à réaliser le modèle que nous avions conçu dans un premier temps en prenant en compte les contraintes liées à la biologie et à l’informatique.

B.Concepts et Méthodes des systèmes temps-réels

Un système temps-réel est un système qui traite des informations en répondant à des stimuli internes et externes pendant une période de temps bien définie.

On parle de temps réel non seulement quand le traitement des données suit très rapidement leur acquisition mais aussi lorsque il faut traiter le comportement d’objets en nombre très élevé et variable.

Pour un système temp-réel, l’exactitude des réponses dépend à la fois de la logique mise en œuvre mais aussi de la rapidité des réponses, l’absence de réponse pouvant être aussi dommageable qu’une réponse erronée.

Les systèmes temps-réel sont généralement des systèmes complexes composés de très nombreux éléments en interactions et qui doivent s’exécuter, en temps réel, avec une sécurité et une fiabilité dans leur fonctionnement. Une autre propriété essentielle des systèmes temps-réel, est leur prédictibilité ; c’est pourquoi ils sont associés à des outils de simulation qui permettent de les tester et les valider.
Les contraintes de fiabilité des systèmes temps-réel ont orienté l’évolution des méthodes de notation de ces systèmes, de la spécification informelle en langage naturel vers des approches formelles ; citons notamment :

• 
  Les diagrammes Etat-transition (machine à états-finis, automates à états-finis) dont le concept a été développé par Stephen Klein dans les années 60 pour la modélisation de tous systèmes informatiques, y compris les systèmes concurrents et les systèmes temps-réel (Stavecharts, D. Harel , 1987).
  
• 
  Les réseaux de Pétri développés il y a plus de 30 ans par C. A. Petri pour la modélisation des systèmes concurrents et les systèmes temps-réel.
  
• 
  Le calcul de systèmes communicants (CCS : Calculus of Communicating Systems) développé par Robin Milner (EdCam) dans les années 80.
  

Dans cette étude, nous avons appliqué le formalisme des diagrammes d’états-transition pour décrire, représenter et simuler un processus biologique : le contrôle de l’entrée en mitose par le complexe MPF.

1.Présentation du langage de modélisation unifié : UML pour RT

Je vais rappeler quelques notions de base essentielles sur les systèmes orientés objet, tous ces concepts sont évidemment présents dans notre modèle. (tiré de : C. Rosenthal-Sabroux, N. Kettani et al., .De Merise à UML, Ed. Eyrolles, Paris 1998)

UML est un langage de modélisation fondé sur les concepts orientés objet qui sont nés il y a plus de trente ans ; UML n’est donc pas à l’origine des objets ; néanmoins, il en constitue une étape majeure, dans le sens où il unifie les différentes approches et en donne une définition plus formelle.
Pour bien comprendre le langage, il est donc nécessaire de commencer par un rappel général de ces concepts. Cette présentation est très brève et ne prétend pas couvrir tous les concepts. Seuls les quatre concepts fondateurs sont introduits : Objet, Classe, Abstraction, Encapsulation et Composant.

a)Système orienté objet

L’approche orientée objet est fondée d’abord sur le principe suivant : tout système orienté objet est en fait une société d’objets qui coopèrent. Pour coopérer, les objets utilisent des messages qu’ils s’envoient entre eux par divers mécanismes qui dépendent de l’environnement de mise en œuvre.

Tout système au sens large avec un contour bien défini peut faire l’objet d’une modélisation orientée objet. Il peut s’agir d’une entreprise, d’une société quelconque (humaine, animale...), d’un logiciel, d’un système informatique ou dans notre cas d’un système biologique.

b)Objet

Un objet est un membre d’un système orienté objet. Un objet possède une identité, un état et un comportement. Les objets sont donc des éléments d’un système défini par son périmètre dans un domaine particulier et non pas des entités qui existent en dehors de tout domaine.

Un objet est donc défini dans son domaine par :

• 
  Une identité qui constitue le moyen d’identifier l’objet par rapport aux autres objets du système. Chaque objet dans un système doit avoir une identité (Pour nous : RTActorId correspond à la référence de l’objet).
  
• 
  Un comportement qui définit la manière dont l’objet agit et réagit aux divers messages qui lui parviennent de son environnement (Dans notre modèle les changements d’état).
  
• 
  Un état qui définit l’une des possibilités dans laquelle un objet peut se trouver à un instant donné de sa vie (Exemple figure 11 : diagramme d’état de la Cdk1).
  

c)Classe

Dans la description d’un problème réel, il est impossible de décrire tous les objets de ce domaine. Les classes sont un moyen pour grouper des objets qui présentent une structure commune et un comportement commun, en un mot des objets qui se ressemblent. Ce regroupement relève de la problématique de la classification qui est particulièrement bien décrite par G. Booch dans [Booch 94]. Une classe est donc une abstraction qui décrit plusieurs objets. La relation qui existe entre une classe et ses objets est appelée « instanciation ».

Une classe active est une classe dont les instances sont des objets actifs. Une classe active représente un flot de contrôle indépendant alors qu’une classe normale (passive) ne met pas de flot en application.

d)Abstraction

L’abstraction constitue un des piliers de l’approche orientée objet. On peut en donner deux définitions qui se complètent :

• 
  processus consistant à identifier une entité en mettant en évidence ses caractéristiques pertinentes du point de vue de son utilisation.
  
• 
  caractéristiques essentielles d’une entité qui la distinguent de tous les autres types d’entités. Une abstraction définit une frontière relative à la perspective de l’observateur.
  

Le travail essentiel du concepteur consiste donc à appliquer un bon processus d’abstraction pour construire de bonnes abstractions. Cette démarche d’abstraction aboutit à construire des systèmes robustes face aux évolutions ; ce qui en constitue le point fondamental. La molécule de cycline pour un biologiste structural est considérée comme un assemblage d’atomes dans l’espace, alors que le biologiste moléculaire le considère du point de vue de son rôle dans le cycle cellulaire.

• 
  Encapsulation
  

L’encapsulation accompagne l’abstraction. L’encapsulation permet de présenter une abstraction à son observateur (son client, son utilisateur) de manière à ne voir justement que les caractéristiques essentielles et surtout à ignorer les détails de sa réalisation. L’encapsulation permet donc de décrire une abstraction sous forme d’une partie visible appelée « interface » et d’une partie cachée appelée « implémentation ».

• 
  Composants
  

Développer un système en assemblant des composants existants (comme construire un bâtiment avec du préfabriqué) au lieu de fabriquer chaque brique de base est une idée qui a fait son chemin. Les concepts sous-jacents ne sont pas nouveaux ; il est possible de dire maintenant qu’ils sont opérationnels ; ce qui révolutionne définitivement la manière dont on développe les systèmes logiciels. Cette révolution est équivalente à l’introduction des microprocesseurs dans l’industrie des ordinateurs.

Un composant est un élément binaire qui expose aux autres composants du système (ses clients) une interface qui leur permet de dialoguer avec le composant en question. Cette interface est un contrat qui définit la manière d’utiliser le composant.

Le concept de composant est encore plus riche et plus intéressant que celui de classe car la classe est de plus faible granularité que le composant. Le composant implémente plusieurs classes.

2.L’atelier de génie Logiciel Rose RT

L’atelier de génie Logiciel Rose RT a été créé exclusivement pour le marché des systèmes embarqués et permet d’élaborer, concevoir, exécuter, tester, observer et débuguer des applications sans jamais quitter l’environnement de développement temps réel. Son utilisation en biologie est une nouveauté et une initiative de l’unité de Biosystémique.

Les concepts mis en œuvre dans rose RT sont ceux de UML pour RealTime avec les solutions suivantes :

a)Capsule

Les systèmes en temps réel sont basés sur la notion d’objets actifs. Dans Rose Real Time, ces objets sont décrit par leur structure et par leurs états (Figure 2).

Le diagramme de structure définit la notion de capsule. Il indique les éléments d’interface (ports), et éventuellement d’autres capsules dites englobées, ainsi que leurs connections au reste de la capsule.

Figure 2 : Représentation de la capsule d’une classe active

b)Port

L’existence de ports permet « d’isoler » la capsule et de traiter de façon asynchrone les messages qui arrivent. Un port est toujours typé par un protocole.

Il existe différents types de ports (Figure 3) :

• 
  Les ports publics sont placés sur la limite de la capsule à laquelle ils appartiennent et permettent de communiquer avec l’extérieur et de transmettre des messages.
  

1. 
   Les ports terminaux sont des ports publics qui servent à communiquer directement avec la capsule par l’intermédiaire de sa machine à état.
   

2. 
   Les ports relais sont des ports publics, ils servent à communiquer avec les capsules internes. Ce port n’est pas relié à la machine à états de la capsule englobante.
   

• 
  Les ports privés sont internes à la capsule et assurent toutes les communications internes.
  

• 
  Les ports " wired " (avec connecteur) sont reliés à la machine à état de la capsule à laquelle ils appartiennent.
  

• 
  Les ports " unwired " (sans connecteur) non reliés à une machine à état, sont utilisés pour se connecter à une librairie de service offerte par Rose RT (Run Time System).
  

Figure 3 : Les differents types de ports dans un diagramme de structure
Le Run Time System de Rose Real Time offre cinq types de services (Figure 4) :

• 
  un service de temps (génération d’événements temporels),
  
• 
  un service d’exception,
  
• 
  un service de log pour imprimer dans la console DOS à l’exécution,
  
• 
  un service de frame qui permet de créer et de détruire dynamiquement des capsules.
  
• 
  un service de communication utilisé pour l’envoi des messages entre les capsules.
  

Pour utiliser les quatre premiers services, il suffit de les déclarer à l’intérieur d’une capsule ( ports privés) et sans connecteur (port unwired).

Figure 4 : Les services offerts par le Run Time System de Rose Real Time.

c)Cardinalité

On peut répliquer une capsule ou un port en leur attribuant une cardinalité (Figure 5). Si un port est répliqué, on peut envoyer un message sur toutes ses instances (broadcast) ou sur une seule qui sera spécifiée.

Figure 5 : Capsules et ports répliqués.

d)Protocole

Un protocole est une classe particulière, c’est une sorte de " contrat " établi entre les capsules et spécifiant les messages qui peuvent être échangés entre elles (Figure 6). Pour communiquer, deux ports doivent être typés par le même protocole, mais être conjugués, c'est-à-dire que les messages entrant de l’un sont les messages sortant de l’autre et inversement.

Figure 6 : Représentation d’un protocole dans le diagramme de classe.

e)Capsule englobante

Une capsule peut contenir une ou plusieurs capsules (Figure 7). Celles-ci peuvent être présentes dès la création de la capsule englobante ou bien, apparaître plus tard, à un moment donné de la simulation. Dans ce cas, elles sont créées dynamiquement, on dit qu’elles sont incarnées. Elles peuvent être importées, dans ce cas elles ont déjà été créées et on importe simplement leur référence. Dans les diagrammes de structure, ces différences sont symbolisées pour les capsules incarnées par des rectangles hachurés, pour les capsules importées par des rectangles gris foncé ; un rectangle gris clair représente une capsule englobée sans référence à son mode de création.

Figure 7 : Les différentes capsules internes

1. Composition

Si plusieurs capsules sont présentes à l’intérieur d’une autre capsule, il y a une relation de composition entre la capsule englobante et ses capsules internes (Figure 8). A la destruction de la capsule englobante, les capsules englobées seront détruites.

Figure 8 : Relation de composition entre les capsules internes et la capsule englobante, dans le diagramme de structure (gauche) et dans le diagramme de classe (droite)

2. Agrégation

Si les deux capsules sont importées, il n’y a alors qu’une relation d’agrégation (plugin) entre les capsules internes et la capsule englobante. La destruction de la capsule englobante ne détruit pas ses capsules englobées (Figure 9).

Figure 9 : Relation d’agrégation entre les capsules internes et la capsule englobante, dans le diagramme de structure (gauche) et dans le diagramme de classe (droite).

f)Machine à état d’une classe active

Le comportement d’une classe active est défini par une machine à états. Dès la création de l’objet, représenté par son diagramme de structure (capsule), une transition place l’objet dans son état initial (Figure 10).

(a)


(b)

(c)




Figure 10. Représentation de la capsule (b) d’une classe active (a) et de son diagramme d’états (c).
Pour pouvoir changer d’état, un objet devra recevoir un message approprié lui permettant d’effectuer une transition ; un état pourra comporter des sous états (symbole en bas à droite de l’état englobant, figure 11, flèche rouge). Si le déclencheur n’est pas spécifié, ce qui ne devrait jamais être le cas, la flèche de la transition est interrompue par deux traits verticaux. Une transition peut être soumise à une condition de garde qui l’emmènera vers un état différent selon le résultat de l’évaluation (état différent si condition est vraie ou fausse).
Des actions peuvent être effectuées à différents moments (Figure 11, flèches bleues) :

• 
  en entrée d’état
  
• 
  en sortie d’état
  
• 
  lors d’une transition entre deux états
  
• 
  en entrée et en sortie d’état
  

Figure 11 : Diagramme d’état avec vue sur les sous-états de l’état englobant.