Assises du GDR I3

page 1Nancy, décembre 2002

Assises du GDR I3

Composants dans l'Ingénierie des SI

Concepts clés et techniques de réutilisation

Franck Barbier, LIUPPACorine Cauvet, LSISMourad Oussalah, IRINDominique Rieu, LSR-IMAGSondes Bennasri, Carine Souveyet, CRI, Paris 1


PlanPlan

* Introduction sur la réutilisation

* Cadre de référence pour la comparaison des composants

* Les types de composants pour les SI (métiers, architecturaux,

patrons)

* Types de démarche : Pour et Par réutilisation

* Synthèse sur les démarches les plus appliquées

* Conclusion


« Il n ’y a qu ’une méthode pour inventer, qui est

d’imiter.

Il n ’y a qu’une méthode pour bien penser, qui est de

continuer quelque pensée ancienne et éprouvée ».

Alain

Réutilisation Réutilisation

Une évolution « naturelle » du métier

- réduire les coûts et les délais de conception, d’implantation

- et de maintenance si la réutilisation s’allie à la traçabilité

Conséquences sur les produits

Plus rapides à développer, Plus faciles à maintenir,

Certainement meilleurs, Moins originaux.


Réutilisation dans l’ingénierie logicielleRéutilisation dans l’ingénierie logicielle

adaptation de J-M. Nerson, CACM 92

SpécificationsInformelles

Modèle Descriptif & NormatifInformatisable

Modèle Effectif Informatisé

Logiciel

Expression des besoins

Analyse

(abstraction du monde réel)

Conception (solution technique)

Implantation (solution opérationnelle)

CCOOMMPPOOSSAANNTTSS


Réutilisation dans l’ingénierie logicielleRéutilisation dans l’ingénierie logicielle

SpécificationsInformelles

Modèle Descriptif & NormatifInformatisable

Modèle Effectif Informatisé

Logiciel

Expression des besoins

Analyse

(abstraction du monde réel)

Conception (solution technique)

Implantation (solution opérationnelle)

Patrons d’analyse Modèles de domaine Composants métiers conceptuels

ERP, Frameworks Patrons d’architecture Patrons de conception

Composants métiers logicielsBibliothèques de classes


Un composant réutilisable :

- traite un problème récurrent de l’ingénierie des SI

- capitalise un fragment de produit ou de processus

- offre une solution conceptuelle et/ou logicielle testée, acceptée et

adaptable

Réutilisation dans l’ingénierie du logicielRéutilisation dans l’ingénierie du logiciel

Nécessité de les classifier, les documenter, les organiser, les composer…Nécessité de démarches centrées réutilisation.

Une très grande variété de composants réutilisables

La réutilisation ne doit plus être limitée aux produits logiciels


PlanPlan




patrons)



* Conclusion


Critères de caractérisation des composantsCritères de caractérisation des composants

* type de connaissance : produit ou processus,

* couverture : générale (horizontale), métier (verticale), entreprise

* portée : étapes d ’ingénierie,

* nature de la solution : logicielle ou conceptuelle,

* technique de réutilisation : spécialisation, composition, instanciation,

duplication…* ouverture : boîte noire, blanche ou en verre,

* granularité : taille du composant en nombre de classes, de modules,…


PlanPlan




patrons)



* Conclusion


Critères de caractérisation : application aux bibliothèques logiciellesCritères de caractérisation : application aux bibliothèques logicielles

Type des connaissances

Couverture

Portée

Nature de la solution

Tech. de réutilisation

Ouverture

Granularité

Spécialisation et Instanciation

Classe de bibliothèques

Logicielle

Boîte en verre

Très faible

Produit

Implantation

Horizontale


Critères de caractérisation : application aux aux composants métiersCritères de caractérisation : application aux aux composants métiers


Couverture

Portée



Ouverture

Granularité

Spécialisation et Instanciation

Classe de bibliothèques

Conceptuelle

Boîte blanche

variable

Produit

Analyse

Verticale

Plusieurs définitions• Un composant métier est un composantlogiciel:

• une entité encapsulée• une entité autonome de déploiement

• différence avec un composant logiciel• spécifique à un domaine d’application c-à-d réutilisable au sein du même domaine d’application

Problème lors de l’intégration des composants

Interopérabilité sémantique

• le demandeur et le fournisseur ont la même sémantique des services et des données échangées



Couverture

Portée



Ouverture

Granularité

Patron

Conceptuelle

Imitation puis Intégration

Boîte blanche

Faible

Critères de caractérisation : application aux patronsCritères de caractérisation : application aux patrons

« un patron décrit à la fois un problème qui se produit très fréquemment dans votre environnement et l’architecture de la solution à ce problème de telle façon que vous puissiez utiliser cette solution des milliers de fois sans jamais l’adapter deux fois de la même manière»

C. Alexander

Une base de savoir et de savoir-faire pour résoudre un problème récurrent dans un domaine

• permet d’identifier le problème à résoudre

• propose une solution consensuelle pour y répondre

• offre les moyens d’adapter cette solution



Couverture

Portée



Ouverture

Granularité

Patron de conception

Produit

Horizontale (générale)

ConceptionDétaillée

Conceptuelle


Boîte blanche

Faible : 2 à 4 classes


[Gamma 95]

E.Gamma

0204060Est =

20,4Ouest = 30,6Nord = 45,9

sujetobservateurs

Exemple : l’Observateur

Intention : définir une ou plusieurs dépendances entre

un sujet et ses observateurs de sorte que si le sujet change

d'état, tous ses observateurs en soit informés et mis à jour.

Motivation :



Couverture

Portée



Ouverture

Granularité

Patron de conception

Produit

Horizontale (générale)

ConceptionDétaillée

Conceptuelle


Boîte blanche



[Gamma 95]Exemple : l’Observateur

Solution:

Sujet

état_sujet

lire_etat ()modifier_etat ()notifier ()lier (Observeur)délier (Observeur)

Observateur

état-obs.

mise_à_jour( )

1..*

observateurs

pour tout o de observateurso.mise_a_jour()

return état-sujet


Coad GoF

Systèmes de patronsSystèmes de patrons

SIGMA 2000

produit

processus

entreprise

domaine

générique

analyse

conceptio

nim

plantation

SIP [Gzara 00]

Coad GoF

Ambler

« Un langage de patrons est une collection structurée de patrons construits l’un sur l’autre pour transformer les besoins et les contraintes dans une architecture ». C. Alexander / J. Coplien

Portée

couverture

Type de connaissance

Un patron processus fournit une collection de techniques, d’actions et/ou de tâches à suivre pour le développement des logiciels.

Ambler 98


Critères de caractérisation : application aux patrons architecturauxCritères de caractérisation : application aux patrons architecturaux


Couverture

Portée



Ouverture

Granularité

Patrons architecturaux

ADL (Architecture Description languages)

ArchitectureComposant-Architecture

SystèmeComposant-

Système

est-composant-de

est-composant-de

est-conforme-à est-conforme-à

Décomposition hiérarchiqueConformité d’interfaceIntégrité de la communication

Critères de conformité

Conceptuelle

Produit

Horizontale

Conception détaillée


Boîte blanche



Critères de caractérisation : application aux patrons architecturauxCritères de caractérisation : application aux patrons architecturaux

Point de vue architectural

Niveau d’abstraction

Domaine

Implémentation

Processus

Flot de contrôle

Flot de données

GraphiqueTextuel

Mon domaine

Domaine connexe

Tout Domaine

.. S

pé

cific

atio

n

arc

hite

ctu

re H

au

t-n

ive

au

Arc

hite

ctu

re d

éta

illé

e

Co

de

so

urc

e


Couverture

Portée



Ouverture

Granularité

Patrons architecturaux

Conceptuelle

Produit/Processus

Horizontale

Conception détaillée


Boîte blanche



Un patron constitue une base de savoir et de savoir-faire pour résoudre un problème récurrent dans un domaine

Un système de patrons est une collection de patrons coordonnés intégrant une démarche de conception pour résoudre un problème complexe

Patron & système de patronsPatron & système de patrons

Actuellement les systèmes de patrons sont des catalogues « papiers »- Peu organisés, formalisés, instrumentés

De nombreux travaux :- Formalisation des solutions qu’est ce qu’une spécification générique ? Comment exprimer la variabilité ?- Expression des relations inter-patrons pour organiser les systèmes, exprimer les démarches,…- Mise en œuvre des patrons dans des ateliers de développement- Unification des formalismes existants….


PlanPlan




patrons)



* Conclusion


Ingénieur d ’applications

Ingé

nier

ie d

’ap

plic

atio

ns

Application

Par réutilisationPour la réutilisation

Concepteur de composants

Ingé

nier

ie d

e co

mpo

sant

s

Bibliothèque de composants

Développement Pour et Par RéutilisationDéveloppement Pour et Par Réutilisation


PlanPlan




patrons)



* Conclusion


Démarches d’Ingénierie de systèmes à base de Démarches d’Ingénierie de systèmes à base de composantscomposants

Trois méthodes sont sélectionnées

– Catalysis [D ’Souza et al. 98]

– Select perspective [Allen et al. 98]

– Rational Unified Process (RUP)[Jacobson et al. 99]


Résumé des caractéristiques généralesRésumé des caractéristiques générales

RUP SelectCatalysis

Itératif et incrémental



UML + extensions

UML + extensions

UML, E/R, CSC Catalyst

Cool:Spex, Cool:Gen ...

Rational Rose, etc

Select Component Factory

Très complexe

Moyennement complexe

Moyennement complexe

Processus dedéveloppement

Notation

Outils Case

Complexitéd’apprentissage


Étude détaillée de la prise en charge des composants Étude détaillée de la prise en charge des composants (1/2)(1/2)

Logique, implémentation

Pas de règles

Pas d’indications

Introduction descomposants dans le cycle de développement

Règles d’identifications des composants

Niveau de décomposition



Catalysis RUP Select

Pas de règles Pas de règles

Pas d’indications

Pas d’indications


Oui avec OCL

Framework avec des indications sur la manière pour les construire

Rigueur dans laspécification des composants

Réutilisation

Non mentionné Non mentionné

Catalysis RUP Select

Package de services sans précision sur l’approche à suivre pour les identifier et les construire

Un processus supportant la gestion d’une librairie de composants réutilisables

Logique : Type

Implémentation: package, composant

Représentation des composants

Logique : sous système

Implémentation: diagramme composants

Logique : package de services

Implémentation: diagramme composants


FaiblessesFaiblesses

• Introduction tardive des composants dans le cycle de

développement (logique, implémentation)

•Manque de guidage du concepteur

– Difficulté de passer des besoins aux composants

– Pas de règles précises sur la granularité des composants (arrêt de la

décomposition)

•Prise en charge partielle de la réutilisation


PlanPlan




patrons)



* Conclusion


ConclusionConclusion

• Effervescence des travaux dans le domaine mais beaucoup de disparité.

• Diversité des composants : composants logiciels, métiers, architecturaux, patrons.

• Des solutions commencent à émerger mais :

– Nécessité de standardiser la notion de « composant »

– D’organiser les composants en fonction du problème (classification)

– De définir des mécanismes d’intégration (assemblage, composition …)

– De formaliser des démarches centrées réutilisation dès la phase d’analyse

Date post:	11-Jan-2016
Category:	Documents
Upload:	tekla
View:	37 times
Download:	0 times

Assises du GDR I3

Documents