Correction de l'examen de CAR du 20 novembre 2008

Questions de cours:

Q1:
Réponse attendue: Un méta-modèle décrit la structure que doit respecter un ensemble de modèles (modèles dit conformes).
On peut comparer un méta-modèle à une grammaire de graphe (les modèles sont alors considérés comme des graphes).
Plus formellement, un méta-modèle est composé de méta-classe qui ont des propriétés et des références.
Un modèle conform à un méta-modèl est quant à lui composé d'éléments. Chaque élément de modèle a une classe qui lui correspond dans le méta-modèle et peut alors porter des valeurs pour les propriétés et les références de cette classe (plus celle des super classes)

Notation:
O si il est fait la moindre mention de relation d'abstraction
100% si il est fait mention de spécification de structure que doit respecter les modèles
100% si il est fait mention des règles formelle définissant la conformité (règles présentées en cours)

Q2: 
Réponse attendue: Les PIM sont des modèles de système informatique mais qui sont indépendant vis à vis des plates-formes d'exécution.
Les PIM sont dont relativement abstrait par rapport à la réalisation du système. On considère souvent que les PIM correspondent aux modèles d'analyse et de conception des méthodes de génie logiciel. 
En ce sens, les PIM sont utilisé pour pérenniser une architecture en espérant qu'elle dure plus longtemps que les réalisations sur des plates-formes succéssives (exemple du PIM correspondant à l'architecture client / serveur).

Notation:
50% si il est fait mention de l'indépendance de la plate-forme d'exécution.
50% si il est fait mention de l'intérêt (pérennité) des PIM dans une méthode de génie logiciel

Q3:
Réponse attendue: En AGG, les éléments de modélisation qui sont matché par le membre gauche et qui n'apparaissent pas dans le membre droit sont automatiquement supprimé du modèle. En EMF, il n'est pas possible de supprimé un élémnent du modèle, il faut supprimer toutes les références qui pointent vers lui et attendre le Garbage Collector de Java.

Notation:
50% si explication du mode AGG
50% si explication du mode EMF

Q4

Réponse attendue : Les contraintes de LdP sont formalisées en utilisant OCL. Pour une intégration dans un dev Java/EMF, il faut réaliser une traduction OCL vers Java/EMF. i.e chaque contrainte OCL est traduite sous forme d’un programme Java/EMF permettant sa détection.

Si l’étudiant fait référence au plugin OCL/EMF, on accepte aussi.

Notation
100% si tout
0 sinon

Problème:

Q1:
Réponse attendue: On veut voir apparaitre la structure arborescente basée sur les liens de composition.

System 
|
+-Composant (name = CP1)
|  |
|  +- AccessPoint (name=A2) (Extern=true)
|  +- AccessPoint (name=A3) (Extern=true)
|
+-Composant CP2
|  +- AccessPoint (name=A4) (Extern=true)
|
+-Binding (source=A3) (target=A4)

Notation
100% si l'arbre est correct
0 sinon

Q2:

Réponse attendue:

Notation:
100% si la structure suivante est respectée (les concepts Composite et Primitif sont là et le primitif ne peut pas être composé d'autres composant ni de bindings)
! pas de sanction si le composite ne peut pas contenir de composite mais que des composants (le sujet est ambigue)

Q3:

Réponse attentdue:

Composite (name = CC1)
|
+ AccessPoint (name=A1) (Externe=false)
|
+-Composant (name = CP1)
|  +- AccessPoint (name=A2) (Extern=true)
|  +- AccessPoint (name=A3) (Extern=true)
|
+-Composant CP2
|  +- AccessPoint (name=A4) (Extern=true)
|
+-Binding (source=A1) (target=A2)
+-Binding (source=A3) (target=A4)

Notation: idem Q1

Q4:
Correction: Les règles ne sont pas très clairement identifiées dans l'énoncé, il est naturel de les spécifier:
R1 : Un binding appartenant à un composite peut se faire entre deux AccessPoint externe de composant contenus dans le composant
R2 : Un binding appartenant à un composite peut se faire entre un AccessPoint interne du composite et un AccessPoint extern d'un composant contenu dans le composant composite

On considère que owner() est donné et permet de récupérer le composant qui possède l'access point
Au pire on parcourt tous les composants en cherchant celui qui contient l'acess point.

public boolean R1(Binding b , CompositeComponent cont) {
	return b.getTarget().extern && b.getSource().extern && cont.getBindings().contains(b) && cont.getParts().contains(b.getSource().owner()) && cont.getParts().contains(b.getTarget.owner());
}

public boolean R2(Binding b , CompositeComponent cont) {
	return b.getTarget().extern && !b.getSource().extern&& cont.getBindings().contains(b) && b.getSource().owner()==cont && cont.getParts().contains(b.getTarget.owner());
}

public boolean R(Binding b , CompositeComponent cont) {
	return R1(b,cont) || R1(b,cont);
}

Ensuite il suffit de parcourir les binding d'un composant (on peut même le faire de manière récursie)

public boolean validBindings(CompositeComponent c) {
	boolean valid = true;
	for (Binding b: c.getBindings() ) {
		if !R(b,c) valid = false;
	}
}

Notation:

De 10% à 40% par règles
20% pour le bon emploi de EMF

Q5:

Correction:
Commentaire: cette question est volontairement très lourde.
Il faut bien comprendre qu'il s'agit de parcourir le graphe mais de façon plutôt habile.

Voici le principe de l'algo
1) Générer une liste de composant afin de faciliter le parcours du graphe
2) Parcourir cette liste pour construire les lignes correspondant aux Composants et aux AccessPoint des composants (genAccessPoint)
4) Reparcourir cette liste pour instancier leur contenu (genContent)
5) start

public void genAccessPoint(Component c) {
    write(“Component“+c.getName()+“= fac.createComponent(“);
    if (c instanceof  CompositeComponent) write(“true“) else write(“false“);
    Boolean hasAccess = false;
    for (AccesPoint p : c.getPoints()) {
        if (!hasAccess) {write(“new AccessPointDescriptor[]{“);  hasAccess=true;}
        write(“new AccessPointDescriptor(\""+p.getName()+"\",”p.getExtern()+”,\"+p.getName()+\") “);
    }
    if (has Access) write(“}“);
    write(”);”);
}

public void genContent(CompositeComponent c) {
    for (Component sub : c.parts()) {
        write(c.getName()+”.addSubComponent(“+sub.getName()+”);”);
    } 
    for (Binding bin : c.bindings()) {
        Component ownerSource = c.getSource().getOwner();
        Component ownerCible = c.getCible().getOwner();
        write(c.getName()+”.addBinding(”);
        write(ownerSource.getName()+”getAccessPoints()[”+
                ownerSource.getPoints().indexOf(c.getSource()+”],”);
        write(ownerCible.getName()+”getAccessPoints()[”+
                ownerCible.getPoints().indexOf(c.getCible()+”]);”);
    } 
}

Notation:

De 10% à 40% par méthode de génération (on doit retrouver les déclarations des composants et la construction de leur contenu
20% pour l’algo général

Q5(bis):
Correction:
Un méta-modèle présentant une séquence d’actions d’adaptation. 2 méta-classes suffisent (la méta-classe Adaptation et la méta-classe Action). La méta-classe Action doit contenir une propriété permettant de préciser quelle action d’adaptation (start, stop, …)

Notation:

100% si le méta-modèle permet de modéliser des adaptations qui sont des scripts appelant les actions d’adaptation.
40% si il est fait mention d’actions d’adaptation mais qu’il manque l’ordre

Q6:
Correction:
Cette question ne devrait pas poser de problème. Par contre le code dépend entièrement du métamodèle de la question Q5bis.

Notation:

50% par règles.

Q7:
Correction:
Ce méta-modèle doit contenir une nouvelle méta-classe représentant le système complet. Cette méta-classe a une référence vers la méta-classe system (mutliplicité max 1) et une référence vers la méta-classe Adaptation (multiplicité max *).

Notation:
100% si la nouvelle classe avec les 2 références.

Q8:
Correction:
Il faudrait spécifier la notion de contexte d’adapation (sorte de précondition ou d’invariant à l’adaptation). Ensuite vérifier que la précondition ou l’invariant d’une adaptation n’est pas interdite par une autre adaptation.

Notation:
100% si précision de contraintes d’application des adaptations.