Rapport de stage Algérie télécom

Defining Abstract Syntax

Lorsque vous ouvrez pour la première fois le modèle de syntaxe abstraite de votre formalisme ( .model), il est vide, avec une barre d’outils de formalisme chargée: SCDToolbar (/Formalisms/__LanguageSyntax__/SimpleClassDiagram/SimpleClassDiagram.umlIcodal). SimpleClassDiagram est un langage de métamodélisation et peut être utilisé pour définir la syntaxe abstraite d'un nouveau langage. Il définit les concepts suivants: Class permet de modéliser la structure d'un concept dans le langage.

GlobalConstraint permet de modéliser une contrainte à respecter pour chaque modèle conforme à ce diagramme de classes.

GlobalAction permet de modéliser une action déclenchée sur un déclencheur spécifique.

 Classes peut être connecté par deux connecteurs:

Association: permet de lier des instances de la classe source avec des instances de la classe cible

Héritage: la classe source hérite de tous les attributs, actions, contraintes, associations et cardinalités (de manière transitoire) de la classe cible.

Remarque

 De nombreux outils cachent la définition de leur langue de métamodélisation, mais se basent plutôt sur une langue de base codée en dur. AToMPM, autant que possible, suit la philosophie de tout modéliser. Si cela vous intéresse, vous pouvez consulter la définition de la syntaxe abstraite et concrète de n’importe quel langage dans AToMPM, y compris SimpleClassDiagram. Ouvrez /Formalisms/__LanguageSyntax__/SimpleClassDiagram/SimpleClassDiagramMM.model pour définir la syntaxe abstraite de SimpleClassDiagram

Exigences¶

Une langue a des exigences. Dans le cas de TrafficLight, les exigences sont les suivantes:

Un modèle dans le langage TrafficLight comprend un certain nombre d'états. Chaque état a un nom unique (une chaîne). L'un des états est un état de départ. Il n'y a pas d'état final explicite, mais un feu de signalisation restera pour toujours dans un état sans transitions sortantes.

Les états peuvent être connectés par zéro ou plusieurs transitions. Il existe deux types de transitions: les transitions temporisées et les transitions d'interruption. Une transition temporisée est étiquetée avec un délai de nombre entier (millisecondes). Une transition d'interruption est étiquetée avec le nom d'une interruption (une chaîne). Il devrait y avoir au plus une transition temporelle partant d'un état. C’est raisonnable, car nos transitions n’ont pas de gardes (comme le fait Statecharts). Si nous permettions plus d'une transition chronométrée, seule celle ayant le délai le plus court serait utilisée. Tous les noms d'interruption sur les transitions sortant d'un seul état doivent être distincts. Si ce n'était pas le cas, le comportement (décrit dans un exercice ultérieur) serait non déterministe.

Une description de la visualisation du feu quand il se trouve dans cet état est associée à chaque état. La description précise, pour chacun des trois feux colorés (rouge, vert, jaune) d'un feu de signalisation, qu'il soit allumé ou éteint. Un état «rouge», par exemple, peut être associé à la visualisation {Rouge = activé, Vert = désactivé, Jaune = désactivé}.

Plusieurs états peuvent faire référence à la même visualisation.

AToMPM ne permet pas de simulation en temps réel, ni d’entrée externe. Cela signifie que l'environnement de production d'interruptions dans lequel le feu de circulation fonctionnera devra également être modélisé. Cela se fait au moyen d'une liste d'interruptions ordonnée dans le temps. La liste des interruptions comprend un certain nombre d’avis d’interruption connectés. La liste est liée à un seul lien, de sorte que chaque élément est lié uniquement au prochain élément de la liste. Une notification d’interruption (c’est-à-dire chaque élément de la liste) a un horodatage de temps absolu entier non négatif (millisecondes) ainsi que le nom de l’interruption (une chaîne).

...