GUI Modeler - SNIper

Document d'Architecture Logicielle

Version <1.1>

Historique des Révisions

Date	Version	Description	Auteur
17/11/2001	1.0	Création	ISI3_BE1
23/01/2002	1.1	Ajout d'informations liées à l'architecture et au développement	ISI3_BE1

Table des matières

1. Introduction 4

1.1 Objectif 4

1.2 Portée 4

1.3 Références 4

2. Représentation de l’architecture 4

2.1 Le format XML 4

2.1.1 Introduction 4

2.1.2 Avantages 4

2.1.3 Moyens envisagés 4

2.1.4 Outils existant 5

2.2 Alternatives 5

3. Buts de l’architecture et Contraintes 6

4. Vue des cas d’utilisation 6

4.1 Réalisation des cas d’utilisation 6

4.1.1 Cas d’utilisation 6

4.1.2 Diagrammes de séquence 7

5. Vue Logique 9

5.1 Couches 9

5.2 Contenu 9

5.3 Paquetages de conception significatifs du point de vue de l’architecture 9

6. Vue Implémentation 10

6.1 Contenu 10

6.2 Couches 10

7. Vue données 11

8. Taille & Performance 11

9. Qualité 12

9.1 Architecture 12

9.2 Généricité 12

9.2.1 Interfaces 12

9.2.2 Classes abstraites 13

Document d'Architecture Logicielle

1. Introduction

1.1 Objectif

Ce document présente l’architecture du système sous différents angles, chacun correspondant à une vue décrivant un aspect de ce système. Ces vues indiquent les décisions significatives prises concernant l’architecture du système.

1.2 Portée

Ce document est destine aux analystes et aux concepteurs.

1.3 Références

· Document Vision v1.0 – ISI3_BE1

· Glossaire v1.0 – ISI3_BE1

2. Représentation de l’architecture

La mise en œuvre de la persistance des diagrammes est une partie importante de l’architecture. Les diagrammes sont représentés de façon interne sous forme de fichier. Le format proposé est le XML.

2.1 Le format XML

2.1.1 Introduction

Comme HTML (Hypertext Markup Language) XML est un langage de balisage, c'est-à-dire un langage qui présente de l'information encadrée par des balises. Mais contrairement à HTML, qui présente un jeu limité de balises principalement destinées à la présentation (titre, paragraphe, image, lien hypertexte, etc.), XML est un métalangage, qui va permettre d'inventer à volonté de nouvelles balises pour isoler toutes les informations nécessaires.

Exemple de texte au format XML :

<?xml version="1.0"?>

<personne>

<name>

Ryan, Mad Dog Madden

</name>

</personne>

2.1.2 Avantages

· Le principal concerne la possibilité de représenter la plupart des données dans ce format

· Etant un simple fichier texte, la taille de ce dernier est minime

· Largement étendu, ce format est normalisé et de plus en plus utilisé

2.1.3 Moyens envisagés

Il est nécessaire d’implémenter ou de réutiliser un module permettant la conversion d’objets JAVA en XML et vice-versa. Une bibliothèque existante, Castor, permet de réaliser ces conversions.

2.1.4 Outils existant

Comme cité précédemment, Castor est un outil permettent la conversion d’objets de type JAVA en flux XML.

· Il est dû au groupe Exolab

· Son code source est accessible librement et l’utilisation de ce logiciel est gratuite

· Composé seulement d’un fichier, cet outil est en fait une bibliothèque utilisable facilement

Cet outil étant très ciblé, les fonctionnalités sont réduites. Sa seule fonction est la conversion d’objets de JAVA vers XML et vice-versa. La bibliothèque sera donc utilisée dans son ensemble, et sans aucune modification de son code.

Exemple :

Prenons l’exemple d’un objet nommé « personne ». Il possède 3 attributs : son nom, de type « chaîne de caractères », sa date de naissance, de type « Date », et un parent de type « personne ».

Pour cet exemple, les attributs de cette personne son valorisés comme suit :

- nom : « Pierre »

- date de naissance : 01-02-1950

- père :

§ nom : « Paul »

§ date de naissance : 10-10-1970

Voici le texte obtenu après la conversion de l’objet au format XML par Castor :

<?xml version="1.0"?>

<personne>

<date-of-birth>1950-02-01T00:00:00.000</date-of-birth>

<pere>

<date-of-birth>1970-10-10T00:00:00.000</date-of-birth>

<nom>Paul</nom>

</pere>

<nom>Pierre</nom>

</personne>

2.2 Alternatives

Aucune alternative n’a encore été étudiée.

Les tests que nous avons effectués ayant été concluants, aucune alternative ne sera étudiée.

3. Buts de l’architecture et Contraintes

· Le système de fichier utilisé doit pouvoir être réutilisé dans les modules futurs.

· Le format de fichier est important dans le sens où il intervient en plus dans les cas de création et de sauvegarde de SEF, de génération automatique de SEF …

· Le code réutilisé doit être entièrement libre de droit.

· Le principal but de l’architecture choisie est de ne pas avoir à re-concevoir cette même architecture ainsi que le format de fichier dans les prochains incréments.

4. Vue des cas d’utilisation

Les cas d’utilisation critiques pour l’architecture sont ceux liés à la gestion des fichiers et l’impression.

Voici les diagrammes d’interactions les concernant

4.1 Réalisation des cas d’utilisation

4.1.1 Cas d’utilisation

4.1.2 Diagrammes de séquence

4.1.2.1 Créer un SNI

4.1.2.2 Ouvrir un SNI

4.1.2.3 Sauvegarder un SNI

4.1.2.4 Imprimer un SNI

5. Vue Logique

5.1 Couches

5.2 Contenu

Description globale des paquetages de l'application :

5.3 Paquetages de conception significatifs du point de vue de l’architecture

Le paquetage « objetsmetiers » est le plus significatif pour l’architecture car les classes qu’il contient ont dû faire l’objet d’une description pour la persistance (cf. 7-
Vue données).

Nous avons aussi défini des classes jouant le rôle d’intermédiaire entre SNIper et Castor. Ces classes sont les suivantes :

6. Vue Implémentation

La version finale de Sniper se présentera sous la forme d’un fichier .jar.

Celui-ci sera exécuté par la commande java –jar sniper.jar (si sniper.jar est le nom du fichier livré).

7. Vue données

La persistance se fait à l’aide de l’outil « Castor » qui permet de transformer un objet en flux XML. Pour cela, cet outil a besoin d’un fichier, nommé « fichier de mapping », qui lui permet de faire la concordance entre l’objet lui-même et son équivalent en XML. Dans ce fichier , on décrit la structure (attributs) de tous les objets qu’on veut convertir via Castor, et on indique le nom de méthode d’accès à ces attributs.

Voici un extrait du « mapping » pour l’objet UDSaisie :

<?xml version="1.0" ?>

<!DOCTYPE mapping (View Source for full doctype...)>

- <mapping>

- <class name="sniper.objetsmetiers.UDSaisie" access="shared">

- <field name="nbUDSaisie_"

type="integer"

set-method="setNbUDSaisie"

get-method="getNbUDSaisie"

required="false"

direct="false"

lazy="false">

<bind-xml name="nb-Ud-Saisie" node="element" />

</field>

- <field name="label_"

type="java.lang.String"

set-method="setLabel"

get-method="getLabel"

required="false"

direct="false"

lazy="false">

<bind-xml name="label" node="element" />

</field>

- <field name="x_"

type="integer"

set-method="setX"

get-method="getX"

required="false"

direct="false"

lazy="false">

<bind-xml name="x" node="element" />

</field>

…

</class>

</mapping>

8. Taille & Performance

Le logiciel risque d’être plus lent sur les postes Unix que sur les postes Windows. Il devra néanmoins être utilisable sur les deux types de plate-forme.

9. Qualité

9.1 Architecture

L’architecture choisie et ce document seront réutilisés pour les prochains incréments et le développement des prochains modules : le format de fichier est choisi pour être compatible avec l’éditeur de SEF (SEF Control) et le visionneur d’interfaces (GUI Viewer).

9.2 Généricité

9.2.1 Interfaces

L’héritage multiple n’existe pas en Java. Aussi est-il judicieux d’utiliser au maximum des interfaces plutôt que des classes abstraites, lorsque ceci est possible.

Lors de la première itération, nous avons décidé de produire un code relativement générique et permettant par la suite de minimiser les modifications de ce code. Aussi nous avons fait usage d’interfaces permettant une généricité importante. Voici une partie du diagramme de classe montrant la généricité du modèle de conception, au niveau des objets métiers :

Le diagramme SNI contient des éléments SNI. ElementSNI est une interface. Tous les éléments à insérer dans un SNI par la suite devront implémenter cette interface. Ainsi, il n’est pas nécessaire de modifier le code. En ce qui concerne ce code, en voici un extrait concernant l’affichage d’un SNI chargé à partir d’un fichier préalablement sauvegardé. On remarque que seules sont utilisés les classes génériques et les interfaces.

public void associerDessinSNI() {

…

try {

for (int i = 0; i < getSNI().getElementsSNI().size(); i++) {

String s;

/* les elements sont dans un tableau. On récupère les éléments un par un */

ElementSNI elt = (ElementSNI) getSNI().getElementsSNI().elementAt(i);

/* on récupère ici la classe correspondant à l’élément que l’on vient de récupérer. Par exemple :

sniper.objetsmetiers.UDSaisie */

s = elt.getClass().getName();

tab[0] = elt.getClass();

s = "sniper.gui.representation.Dessin" + s.substring(21, s.length());

c = Class.forName(s);

paramsConstructeur[0] = elt;

/* on crée un nouvel objet correspondant à l’élément à insérer dans le SNI.

Le paramètre « paramsConstructeur » contient la liste des paramètres nécessaires au dessin

de l’objet dans le SNI. En effet, la liste des paramètres n’est pas la même pour une UD que

pour une liaison entre 2 UD */

DessinElement d = (DessinElement) c.getConstructor(tab).newInstance(paramsConstructeur);

/* cet objet créé est maintenant inséré dans le dessin du SNI */

getPanneauSNI().ajouterEltDessin(d);

d.afficher(elt.getParamsAfficher());

}

}

catch (Exception e) {

…

}

}

9.2.2 Classes abstraites

Lorsque des attributs ont été nécessaires, nous avons remplacé l’interface par une classe abstraite. C’est le cas de la classe UD. Toute UD possède les mêmes attributs qui sont :

- un label

- une position sur l’axe des « x »

- une position sur l’axe des « y »

- une largeur

- une hauteur

Toutes les UD spécifiques hériteront donc, comme UDSaisie, de la classe abstraite UD.