1ère Année Master ISI

Notes de Cours
Matière : Ingénierie logicielle

Cours 1
Méthodes de génie logiciel
Symphony: une démarche de développement à base de
composant
Présenté par
Khelifa N

2020/2021
 Intégration des composants dans les
méthodes développement
Un composant: est une unité autonome remplaçable dans le système
◦ Peut être spécifié et développé indépendamment
◦ Offre un ensemble d’interface spécifiant les services fournis et les services attendus par d’autre composant
◦ Peut être assemblé a d’autre composant

Lesméthodes développement à base de composants remplace les démarches traditionnelles par

deux types de processus:
◦ Le processus de développement pour la réutilisation(Design for reuse)
 Identifier, spécifier et développer des composant réutilisable
◦ Le processus de développement par la réutilisation (Design by reuse)
 Utiliser des composants réutilisables

Connaissances
Applications du domaines
existantes
Cahier des
charges
Infrastructure application
Design for de
reuse
réutilisation

Design by reuse
Application
 Caractéristiques de Symphony

Cyclede vie en Y
Démarche itérative
Démarche pilotée par les cas d’utilisation
Démarche orientée composant
Le modèle de cycle de vie en Y s’articule sur
trois branches:
Cycle de vie en Y
1. La branche fonctionnelle: Cahier des

Sp es b

tiv re
éc eso

ica tu
modélise les fonctions attendu de l’application pour charges

e
pl ec
ifi

ap chit
ca ins
répondre aux besoins

tio

Ar
n
Le résultat ne dépend d’aucune technologie Etape1: formalisation des
particulière exigences métier
Etape 2: Formalisation des

iq ure
hn ect
processus métier

An

ue
tec hit
La branche technique (architecture applicative

aly
2.

c
Ar
Etape1: Analyse

se
et technique) structurelle
Etape 2: Analyse
Recensement des contraintes et des choix technique dynamique
nécessaire de la conception du système tel que la
conception
sécurité, la montée en charge, l ’intégration de
l’existant Composant Composant
métier technique
Architecture applicative: spécifie les composants
techniques et les Framework technique a mettre en implémentation
place pour exécution des composant métier
Architecture technique: décrit l’architecture
Intégration
matériel et réseau du système en production

3. La branche centrale: Recette

Elle permet de réaliser une conception en intégrant Composant
Métier et technique
le modèle d’analyse dans l’architecture de manière (logiciel)
a obtenir un modèle de conception traçant les Déploiement
composant du système a développer
 Démarche itérative
Chaque itération
regroupe tous les
phases représentant
l’enchainement des
différents activités du
processus

Le résultat de chaque

itération est un
système testé intégré
mais incomplet(un
incrément)

En pratique: pour

chaque itération il faut
choisir un ensemble
d’exigences métier de
les concevoir, de les
implémenter les tester
rapidement
 Démarche pilotée par les cas
d’utilisation (CU)
Les besoins et les usages réels sont intégrés des les phases en amont
du développement par les CU.
Les modèles de CU décrivent les grandes fonctionnalités complètes
du système.
A partir du modèle CU, les concepteurs créent une série de modèles
de conception et de développement pour la réalisation de ces CU.
Les CU sont des mécanismes essentiels de traçabilité entre les
modèles
La traçabilité permet :
1. Une dépendance entre les différents modèles et le modèle de cas
d’utilisation
2. Une navigabilité dans le système dans son ensemble pour facilité la
propagation des modifications
Mécanisme de traçabilité basé sur les cas d’utilisation
Traçabilité par les cas d’utilisation de la branche gauche

PM: processus
métier
PI: processus
informatisé
 Démarche orientée composant
L’application est vue comme, tant au niveau conceptuel que logiciel ;
comme un assemblage de composant métier indépendant et interconnecté
La démarche est basé sur un modèle de composant métier qui permet des
la phase de formalisation des exigences métier, l’identification des
composants métier et de leurs responsabilités dans le système
d’information cible.

Lemodèle métier de la démarche spécifie trois types de composants

métiers:
1. Composant processus: permet décrire un processus applicatif (processus de
gestion d’une agence; processus de gestion personnel … )
2. Composant entité: constitue la base du composant métier (agence, banque, point
de vente… )
3. Composant donnée: représente les donnée de référence (la codification des
salaires…)
 Symphony : aspect fonctionnel

Spécification
des besoins
Analyse : modèle conceptuel des composants
métiers
◦ Classe interface
◦ Classe maitre
◦ Classe partie
◦ Classe rôle
Organisation des composants
 Spécification des besoins
Comprendre la finalité attendue par chaque acteur : pour qui ? Pourquoi ? Dans
quelle condition ? Comment et quels résultats ?
Techniquement :
Définition des cas d’utilisation
Affectation des cas d’utilisation aux composants
(la technique est d’appliquer analyse syntaxique sur le nom des cas d’utilisation, en choisissant le
complément de verbe comme nom du composant)


On peut Ajouter
le diagramme d’activité pour identifier les cas d’utilisation à informatiser
Diagramme de séquence pour exprimer les<<composant
demandes
métier>> de service entre composants
Nom_comosant_M1

CU1
<<include>>
CU1 <<composant métier>>
Nom_comosant_M2

Acteur
CU2 Acteur
<<include>>

CU2
Définition des cas d’utilisation Affectation des cas d’utilisation aux
composants
 Analyse : modèle conceptuel des
composants métiers
L’architecture des CM est inspirer des CRC (Classe Responsabilité
collaboration)
Un CM est modélisé par un paquetage composé en trois parties:
1. Une partie contrant extérieur (ce que je sais faire)
2. Une partie structurelle (ce que je suis)
3. Une partie collaboratrice (ce que j’utilise)

<<métier>>
N_Composant métier

<<interface>> <<maitre>>
Class_maitre <<Role>>
service  Class_Role

<<Partie>>
Class_Partie

Ce que je sais faire Ce que je suis Ce que j’utilise

 Une partie contrant extérieur :
Classe interface

La classe interface permet:

◦ D’accéder a la structure interne au composant et
d’éxecuter les services qu’il offre.
◦ De définir la signature des opérations

<<interface>>
service 

Operation1()
Operation2()
Operation3()
 Une partie structurelle (1) : Classe
maitre

C’est la classe principale du CM pour laquelle les opérations

sont réalisées.
Classe maitre est autonome (sauf règle de gestion)
Elle doit vérifier les règles suivantes:
1. Etre le centre du problème
2. Existe en un seul exemplaire lorsque l’on traite le problème

<<maitre>>
Class_maitre

attr1
attr2

Operation1()
Une partie structurelle (2) :
Classe partie
C’est une classe complémentaire de la classe
maitre ayant un intérêt dans son contexte
Classe partie est reliée avec la classe maitre
par la relation de composition.

<<partie>>
Class_Partie

attr1
attr2

Operation1()
 Une partie collaboratrice:
Classe rôle
Une classe rôle représente un fournisseur de service auprès du
composant client.
Un fournisseur est un autre composant qui rend un ou plusieurs services
Ces services sont appelés chez le client au travers de la classe rôle
En UML :
1. les dépendance sont représentées par une dépendance stéréotypée utilisation
2. Les attributs importés dans le rôle sont représentés par la notation attribut
dérivé <</>>
3. Les attributs proposés à la classe rôle n’ont de pertinence effectif que dans le
cadre du CM

<<Role>>
Class_Role
 Organisation des composants

ce sont les relations inter composant métier dont

l’objectif et d’établir des relations facilitant :
◦ l’adaptation (héritage)
◦ l’assemblage(utilisation et agrégation)
Les relations sont :
◦ Communication par lien d’utilisation
◦ L’agrégation de composant
◦ La relation d’héritage d’interface
◦ La relation de spécialisation de classe de composant
 Organisation des composants (1)
1. Communication par lien d’utilisation (liaison dynamique)
 Un CM client sollicitant un CM fournisseur doit connaitre identité et l’appeler via son interface
◦ Ces relations sont des dépendances spécialisées en type « utilisation »

2. L’agrégation de composant (composant imbriqué)

 Utilisée lorsque le CM fournisseur n’est pas réutilisable dans le contexte de l’étude en cours
 Le CM fournisseur est intégré dans le CM client et ses services ne sont connu qu’on interne du
composant métier client
 Toutes les classes du CM client peuvent être uniquement reliées à la classe maitre agrégée

<<Metier>>
N_CM1

<<Metier>>
N_CM2

<<maitre>> <<Maitre>>
Class_Maitre1 Class_Maitre2
 Organisation des composants (2)
3. La relation d’héritage d’interface
 Permet de préciser qu’une classe maitre d’un
4. La relation de spécialisation de classe
CM s’engage a proposer les opérations publiées de composant
par un autre CM • La relation permet de préciser qu’une classe
 Le CM fournissant son interface est souvent une maitre d’un composant est une spécialisation
abstraction représentant une structure générique d’une classe maitre d’un autre CM

<<Metier>>
<<Metier>>
N_CM1
N_CM1

<<interface>>
<<Maitre>>
Clas_service1
Class_Maitre1

<<Metier>>
<<Metier>>
N_CM2
N_CM2

<<Interface>> <<Maitre>> <<Maitre>>

<< Implémente>> <<Interface>>
Clas_service2 Class_Maitre2 Clas_service2 << Implémente>> Class_Maitre2
 Architecture d’un composant métier
Symphony
<<metier>>
N_Composant métier

<<maitre>>
Class_maitre
<<Role>>
0..* Class_Role

<<interface>>
service 

0..* <<Role>>
0..*

<<Partie>>
0..* Class_Role
<<Partie>>
Class_Partie Class_Partie

Ce que je sais faire Ce que je suis Ce que j’utilise

 Symphony : aspect architecture
L’objectif:
◦ est de spécifier des composants techniques à mettre en
place pour supporter l’éxécution des composants métiers
◦ Est d’anticiper le développement des composants
génériques
Les étapes:
◦ Description des couches applicatives
◦ Etablissement de la cartographie des composants
techniques
◦ Description des composants et des classes techniques
◦ Description des règles de transformation
 Description des couches applicatives
Le style architecturale préconisé est architecture n_tier basé sur les couches
La spécification des couches consiste d’appliquer des patrons de conception (Façade…)
Cette architecture permet d’atteindre un haut niveau de productivité, maintenance et de
réutilisation
La relation de dépendance entre les différents couches permet un bon découplage
Une architecture n_tier permet de décomposer le système en sous système

Modele Process
Entité

Mappingl
control

Donnée
Process
View

Client
Mapping O_R Données
Présentation Processus Entreprise
 Architecture multicouche préconisé par
Symphony
Couche présentation : définit les composants permettant de gérer
la présentation et l’interaction avec les couches inferieurs(exemple
JEE elle est basé sur MVC en utilisant les servlet, JSP,JavaBean)
Couche processus: réalisé par les classes encapsulant logique
applicative (processus administrative, gestion des dossier… )
Couche entreprise: représente l’ensemble de des composants
métiers entités et données de références
Couche projection objet relationnel: permet de transformer les
objets en requêtes SQL
Couche Données: les données sauvegardées
 Etablissement de la cartographie des
composants techniques
Cette activité permet de:
◦ Définir la cartographie des composants technique à mettre en
place en convergence avec les besoins fonctionnels
Quelque catégories recensés dans le cadre d’une application
de gestion:
◦ Composant de Framework de présentation (STRUTS, JSF)
◦ Composant de projection objet relationnel (Lido, TopLink, ... etc)
◦ Composant d’authentification (JAAS…)
◦ Composant de notification (JavaMail,NetSize…)
◦ Composant d'édition(FOP,Cocon,….)
◦ Composant de recherche
◦ Composant de gestion de Pool de connexion
 Description des composants et des
classes techniques
Cette étapes consiste a détailler les composants
techniques :

◦ Interface
◦ Les classes spécialisables
◦ Fonctionnement interne
 Description des règles de
transformation
Spécifier et ou identifier les règles de
conception applicable dans la conception de
l’application ces règles doivent permettre:
◦ Transformer le modèle d’analyse en modèle de
conception
◦ Générer les interfaces des composants
distribués(IDL)
◦ Générer des classes de composant (inutile si la
génération est réalisé par un outil)
◦ Traduire les modèles d’état
Symphony : aspect conception

Conception des composants

Conception de la persistance
 Conception des composants
Concevoir les composants revient à transformer le diagramme de classe d’analyse en
diagramme de classe de conception :
1. Décomposer le contrat pour affecter, a partir de la responsabilité d’un composant
métier, les opérations élémentaires aux classes du composant métier et placer les
opérations sur toutes les classes
2. Ajouter les types aux attributs et les méthodes d’accès, de création, de destruction et de
recherche
3. Déterminer les classes abstraites
4. Appliquer les diffèrent patron de conception (fabrication, DAO,…) pour concevoir les
diffèrent type de composant et obtenir une meilleur conception (évolution,
maintenance)
5. Choisir les structures de données ensemblistes (tableaux,…)
6. Traduire les associations (en particulier les associations n aires et classes association)
7. Définir la visibilité des attributs, méthodes et rôles des objets
8. Définir la navigabilité des associations et s’assurer que les associations sont mono
directionnel (sauf nécessité )
9. Définir les identificateurs techniques (par exemple: compteur numérique)
 Conception des composants (1)
patron de conception des CM (approche JAVA)
Les composants processus sont implémentés sous forme de paquetage JAVA
contenant :
1. Une classe interface (précise les différentes étapes du processus implanté)
2. Une classe qui implémente l’interface
3. Une classe factory
process

ComposantProcFactory
<<interface>>
<<utilisation>>
service  -composantFactory:ComposantProcFactory

+OpeComposant() +newInstance()
+CréercomposantProcess()
+RechercheComposantprocess()
+ComposantProcFactory()
<<Implement>>

<<maitre>>
<<utilisation>>
ComosantProcesImpl

+OpeComposant()
 Conception des composants (1)
patron de conception des CM (approche JAVA)(2)
Entity Impl
Les composants entités et données de
ComposantEntityFactory
références sont implémentés sous
<<interface>> composantFactory:Composant
forme d’un paquetage JAVA contenant: CompEntity <<utilisation>> EntityFactory

1. Une classe interface OpeComposant()

newInstance()
CréercomposantProcess()
2. Une classe qui implémente cette  
RechercheComposantprocess()
ComposantProcFactory()
interface <<Implement>>

3. Une factory <<maitre>> <<utilisation>>

4. Les classes parties et les classes rôles ComosantEntityImpl

5. Une classe DAO(Data access OpeComposant()

Objet)regroupant les méthodes d’accès à

ComposantEntityValue
la base de données
attributA
attributB ComposantEntityDAO

ComposantEntityDAO()

<<partie>> <<Role>>
partie Role
 Conception de la persistance
L’objectif
de cette étapes est de transformer le
diagramme de classe de chaque composant en un
modèle de table:
◦ Définir les tables métier et spécifier les types des champs
◦ Décrire les relations traduisant les classes et celles des
associations
◦ Traduire l’héritage en utilisant les techniques de
propagation
◦ Décrire les clé primaire et les clé étrangère
◦ Définir les règles stockées
◦ Déterminer les accélérateur (index spécifique)
Merci de votre attention
Démarch
e itérative