Architecture des SI

1
Architecture des SI

• Lapproche Modelware exploitation des modèles
  au cœur des systèmes apports et besoins pour la
  vérification

2
Lapproche  Modelware 

• Approche rencontrée dans la supervision appliquée
  au génie logiciel
• On modélise une abstraction informationnelle de
  gestion des ressources que lon souhaite gérer à
  des fins dinteropérabilité, partage et
  spécification des modèles complémentaires à une
  approche  MDA  (Model Driven Architecture)
• Plate- forme CAMELEON

3
1. Un nouveau rôle pour les modèles
Intégration logicielle par des référentiel de
modèles

1. lapplication cliente invoque la méthode dun
   objet du réfereniel
2. la plate-forme récupère les informations pour
   connaître le composant fournisseur
   dimplémentation adéquat
3. ,(4) la plate-forme redirige lappel du client
   vers ce composant

4
2. Prise en compte de la description du
comportement

• Lexécution des diagrammes détat se fait en
  fonction des appels réalisés sur le référentiel
• La gestion de lexécution de diagrammes se fait à
  partir dun code généré au préalable
• Létat courant dun objet est représenté par la
  valeur de sa propriété  Status .
• Lassociation dun diagramme détat à une classe
  est signalée au travers dun marqueur  state 
  et qui permet à la plate-forme dappliquer les
  mécanismes internes nécessaires à la gestion des
  diagrammes détat

principe dutilisation des diagrammes détat
transition dans une plate forme dintégration par
les modèles
5
2. Prise en compte de la description du
comportement

• Avantages
• La génération de code pour les diagrammes détat
  transition nest à réaliser quune seule fois
  pour le langage cible choisi pour le
  développement de la plate forme dintégration
  par les modèles
• Permet de tjrs utiliser les diagrammes détats
  transitions quelle que soit la technologie cible
  dimplémentation

6
3. Un modèle darchitecture élargie, basé sur un
référentiel

• But de la plate forme CAMELEON
• Fournir un socle commun pour des applications de
  type segment sol (centre de ctl de satellites,
  centre de mission,
• Pouvoir étendre la plate-forme à différent
  niveaux d'architecture CAMELEON au travers de 3
  types de composants logiciels
• - Les applications clientes
• - Les applications de type Object Manager (OM)
• - Les composants de type Object Provider (OP)

7
4. Un référentiel multi-vue pour la gestion de
différents aspects

• CAMELEON propose une couche additionnelle,
  appelée fonctions élémentaires pour la
  gestion des aspects non fonctionnels
• Mise en place de ces fonctions sappuie sur 2
  mécanismes et API de base pour exploiter le
  référentiel
• Mécanismes de redirection
• Mécanismes dinterception
• Des API daccès au réferentiel et dinvocation de
  méthodes des objets du réferentiel
• Des API dabonnement aux évenements du
  réferentiel

8
4. Un référentiel multi-vue pour la gestion de
différents aspects

• Fonctions élémentaires mises en œuvre dans
  CAMELEON
• Fonction de configurations
• Fonction de sécurité
• Fonction de tolérence aux pannes
• Fonction de persistence
• Fonction de gestion des états
• Fonction de dépendance active
• Fonction dhistorique
• Fonction de gestion de connaissance de gestion
• Fonction de gestion de temps
• Fonction de gestion des actions

9
4. Un référentiel multi-vue pour la gestion de
différents aspects

• N.B
• A un modèle PIM peuvent venir se greffer
  différents aspects
• En configurant par maquettage le modèle PIM
• En liant (association entre objets) des éléments
  du PIM avec des éléments PSM
• En dé finissant linformation relative aux
  composants logiciels déployés sous la forme de
  modèles PDM.
• --gt accès aux infos techniques de la plate-forme
  cible à partir du référentiel
• --gt méthodes des objets du référentiel
  implémentés par les composants dapplication ou
  les fonctions hébergées au sein de la plate-forme
  CAMELEON.
• --gt Appels de méthodes redirigés automatiquement
  à partir du marquage de type Provider défini
  sur chaque classe ou méthode.

10
5. Vers une approche MODELWARE

• CAMELEON utilise les technologies JAVA et CORBA
  (pour la communication en interne entre les
  différents éléments de la plate-forme, et aussi
  en tant que connecteur technologiques)
• Les modèles peuvent être déployés au travers de
  référentiels distribués
• --gt Permet de choisir le déploiement des infos et
  des opérations en fonction des contraintes du
  système cible tout en respectant son
  organisation.

11
6. Elements de vérification dans le cycle de vie

• PIM platform independent model est une vue dun
  système indépendante de la plateforme (Exemple
  système de facturation exprimé en UML)
• PDM platform description model (Exemple
  modèles de composants à différents niveaux
  d'abstraction C, EJB, )
• PSM platform specific model est une vue dun
  système spécifique de la plateforme (Exemple
  Système de facturation exprimé en  UML profile
  for CORBA  )
• Source Univ-nantes Jean Bézivin Equipe ATLAS
  (INRIA IRIN)

12
(No Transcript)
13
6. Éléments de vérification dans le cycle de vie

• Pour obtenir des PSM il y a transformation de
  modèles. Il faut donc vérifier
• La conformité aux règles imposées par le
  méta-modéles et par les patterns gt éviter des
  développements spécifiques et/ou redondants
• La consistance des modèles résultants (PSM)gt
  éviter un retour à la conception
• La réutilisabilité gt capitalisation/réutilisation
  des vérifications de conformité et de
  consistance

14
6. Éléments de vérification dans le cycle de vie

• 6.1 Vérifications off-line
• 6.1.1 Modèles statiques
• La modélisation se base sur le méta modèle CIM
  (Common Information Model). Ce méta modèle
  implique plusieurs choses
• Notion dHéritage
• Nommage pour chaque élément modélisé
• Accès aux propriétés get() implicite
• Liste de marqueurs est disponible pour indiquer
  certaines caractéristique (ex Write sur un
  attribut de classe)

15
6. Éléments de vérification dans le cycle de vie

• 6.1.1(suite) Vérification de modèles. Quelques
  conventions
• Typage gt ensemble de type prédéfinis
• Respect des niveaux dabstraction de modélisation
  PIM PDM gt Leur but étant la réutilisation de
  modèles
• Application de patterns gt automatiser certains
  traitements sur les classes
• Arbre de nommage avec propriétés clés gt unicité
  des noms dans le cas dassociations de
  compositions formant un arbre
• Relations inter-modèles gt correspondance entre
  des modèles hétérogènes, grâce au marqueur
  mapping-string

16
6. Éléments de vérification dans le cycle de vie

• 6.1.2 Modèles dynamiques
• Différentes techniques de vérifications
• Transformation de modèles UML (diagramme classe,
  etat-transition)
• Spécification de test à partir dun ensemble de
  combinaisons possibles. Ces combinaisons pouvant
  être traduites en diagramme de séquence afin de
  construire un référentiel.

17
6. Éléments de vérification dans le cycle de vie

• 6.2 Vérification on-line
• 6.2.1 Modèles statiques, vérifications
• Dépassement de valeurs min ou max
• Non respect de cardinalité
• Valeurs énumératives inconnues
• Respect des contraintes OCL (Object Constraint
  Language)

18
6. Éléments de vérification dans le cycle de vie

• 6.2.2 Modèles dynamiques
• Ces vérifications sont effectuées sur les
  machines au sein de la plateforme
• Il est donc possible de mettre en place certaines
  contraintes
• Interdire lexécution de certaines méthodes en
  fonction de létat dun objet
• Changer les droits daccès dun objet en fonction
  de son état
• Traiter les exceptions
• Ajout de règles de contrôle avant et après
  lexécution dune méthode

19
7. Conclusion

• Lapproche  Modelware  donne un nouveau rôle
  aux modèles
• Il est possible de lier des modèles différents
  par  marquage 
• Amélioration de la démarche de conception grâce à
  des référentiels de modèles