Transcript Développement à base des composants

Développement à base des
composants
Le contenu est basé aux transparents du 7ème édition
de «Software Engineering» de Ian Sommerville
B.Shishedjiev - Génie logiciel
1
Origine et définitions
• Origine
– De programmation objet-orienté
– Différences
• Les objets sont plus détaillés et spécifiques
• Les composants sont plus abstraits et indépendants. Ils
peuvent être examiné comme des fournisseurs
autonomes de services.
B.Shishedjiev - Génie logiciel
2
Origine et définitions
• Définitions
– Councill et Heinmann:
• A software component is a software element that conforms to
a component model and can be independently deployed and
composed without modification according to a composition
standard
• Le composant de logiciel est un élément de logiciel qui est en
conformité avec le modèle des composants et intégré sans
modification selon la procédure standard de composition
– Szyperski:
• A software component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. A software component can be deployed
independently and is subject to composition by third-parties.
• C’est une unité de composition avec interface spécifié par
contrat et ses dépendances ne sont que de contexte et
explicites. Il peut être déployé de façon indépendante et est
soumis à la composition par des tiers.
B.Shishedjiev - Génie logiciel
3
Origine et définitions
• Principes
–
–
–
–
Indépendants
Implémentation cachée
Communication fait par des interfaces bien spécifiés
Plateformes partagées
• Essentiels de génie logiciel basé aux
composants
– Composants indépendants spécifiés par leurs
interfaces
– Standard pour faciliter l’intégration
– Middleware qui support l’interopérabilité
– Processus de développement approprié
B.Shishedjiev - Génie logiciel
4
Origine et définitions
• Problèmes
– Fiabilité – comment l’utilisateur va croire que le composants ne
va pas échouer
– Certification – qui va certifié le composant
– Les propriétés intégrales – comment les prévoir
– Compromis des besoins – comment faire le compromis entre les
besoins assurés des différents composants
• Caractéristiques
–
–
–
–
–
Standardisé
Indépendant
Composable
Déployable
Documenté
B.Shishedjiev - Génie logiciel
5
Interface de composants
Requires interface
Defines the services
from the component’s
environment that it
uses
Provides interface
Component
Defines the services
that are provided
by the component
to other components
• Exemple
Requires interface
Provides inter face
sensorManagement
Data collector
sensorData
B.Shishedjiev - Génie logiciel
addSensor
removeSensor
star tSensor
stopSensor
testSensor
initialise
repor t
listAll
6
Composants et objets
•
•
•
•
•
Les composants sont déployables
Les composants ne définirent pas des types
L’implémentation des composants est opaque
Les composants sont indépendant de langage
Les composants sont standardisés
B.Shishedjiev - Génie logiciel
7
Modèles
• Définition
– Le modèle de composants c’est la définition des
standard pour implémentation, documentation et
déploiement du composant
• Exemples
– EJB
– .NET (COM+)
– Corba Component Model
B.Shishedjiev - Génie logiciel
8
Eléments du modèle
Customisation
Naming
convention
Composition
Interface
definition
Specific
interfaces
Interfaces
Documentation
Meta-data
access
Usage
information
Packaging
Evolution
support
Deployment
and use
Component model
B.Shishedjiev - Génie logiciel
9
Middleware de support
• Le modèle est la base de middleware qui assure
l’exécution des composants
• Middleware services
– Services de plateforme – pour communication entre
le composants
– Services horizontaux – services partagés pour être
utilisés par plusieurs composants
• Déploiement en conteneur – il contient tous les
interfaces nécessaires pour accéder les services
de support
B.Shishedjiev - Génie logiciel
10
Middleware de support
• Services du modèle
Horizontal services
Component
management
Transaction
management
Resource
management
Concurrency
Persistence
Security
Platform services
Addressing
Inter face
definition
B.Shishedjiev - Génie logiciel
Exception
management
Component
communications
11
Réutilisation des composants
• Besoins
–
–
–
–
–
Plus générales
Liés au domaines abstraites et stables (ex. hôpital)
Cachent les présentations d’états
Une large indépendance
Exception doivent être publiées par l’interface du
composant
• Compromis
– entre réutilisabilité et utilisabilité
– entre généralité et efficacité
– Entre les hauts frais de développement et les bas
frais de réutilisation
B.Shishedjiev - Génie logiciel
12
Réutilisation des composants
• Changes qui doivent être faits
– En généralisant autres composants
• Supprimer les méthodes spécifiques de l’application
• Faire les noms plus générales
• Ajouter des méthodes pour élargir la couverture
• Assurez la gestion des exceptions cohérente
• Ajouter un interface de configuration qui fait le composant
plus adaptable
• Intégrer des composants afin de minimiser la dépendance
– Quand on adapte un système hérité
• Répaqueter les fonctions utile comme un composant
• Ecrire une composant enveloppe qui implémente l’interface
et permit l’accès au système hérité
B.Shishedjiev - Génie logiciel
13
Le processus de développement
Outline
system
requirements
Identify candidate
components
Modify
requirements
according to discovered
components
Architectur al
design
Identify candidate
components
Compose
components to
create system
B.Shishedjiev - Génie logiciel
14
Le processus
• La spécification des besoins
– Plus schématique
– Si les besoins ne sont pas couverts par les
composant trouvés on peut discuter la modification
des besoins.
• Identification des composants
– Confiance
– Les besoins
– Validation
• La spécification peut de ne pas être assez détaillée
pour concevoir des bon tests
• Le composant peut avoir une fonctionnalité peu désirée
B.Shishedjiev - Génie logiciel
15
La composition
• Définition
– Le processus d’intégration
– C’est normal d’écrire un code qui «colle» les
composants
B.Shishedjiev - Génie logiciel
16
La composition
• Types de composition
a) Composition séquentielle
b) Composition hiérarchique
c) Composition additive
A
A
B
A
B
(a)
B
B.Shishedjiev - Génie
(b ) logiciel
(c)
17
La composition
• Incompatibilité des interfaces
– Incompatibilité des paramètres
– Incompatibilité des opérations
– Incomplétude des opérations
strin g location (strin g pn )
p ho neDatab ase (string command )
ad dressFind er
strin g owner (string p n)
strin g pro per ty Ty pe (strin g pn )
Adaptateur qui
sépare le
post code de
location
string
d isp lay Map (string po stCo de, scale)
map DB (string command )
map per
B.Shishedjiev - Génie logiciel
p rin tMap (strin g po stCo de, scale)
18
Composition
• Adaptateur
sens orManagement
ad dSen so r
remo veSens or
star tSen so r
star t
sens or
stop
g etd ata
Adapter
Data co llector
sens orData
B.Shishedjiev - Génie logiciel
stop Sens or
testSen so r
in itialise
repo r t
listAll
19
Composition
• Sémantique de l’interface
«This method adds a photograph to the library and associates the
photograph identifier and catalogue descriptor with the
photograph»
g etImage
ad dItem
ad ap to r
Pho to
Library
retrieve
catEntry
Imag e
Man ag er
g etCat alo gEnt ry
User
In ter face
On a besoin d’un langage qui décrit la sémantique – OCL (Object
design langage
B.Shishedjiev - Génie logiciel
20
Composition
• Les compromis de la composition
– Conflits
• Entre besoins non-foncionnels et besoins fonctionnels
• Entre la délivrance rapide et l’évolution
– Décisions
• Laquelle des compositions est effective pour l’accomplir
la fonctionnalité désirée?
• Laquelle vous permis des changements futures?
• Quelles seront les propriétés intégrales du système
composé?
B.Shishedjiev - Génie logiciel
21
Composition
Deux compostions alternatives
(a)
(b)
Data
collection
Report
generator
Data
management
Data
collection
B.Shishedjiev - Génie logiciel
Report
Data base
Report
22