|
Cadre Fonctionnel |
Modèles de fiches de développement EJB |
En-tête
statique :
|
Titre |
Rôle du composant |
|
Identifiant Java |
Package et classe |
|
Fiches de référence |
Liste de fiches d'information complémentaires |
|
Identifiant Fiche |
NATURE_EJB_IDENTIFIANT NATURE = EB, SB, MDB… IDENTIFIANT=à choisir en fonction du rôle du composant |
|
Identifiant d’analyse |
Références sur documentation d’analyse (diagramme de classes, diagramme de séquences…) |
|
Identifiant de phase |
Identifiant de phase du projet |
|
Référent Technique |
Responsable technique / Chef de projet (e-mail) |
|
Auteur |
Nom du développeur (e-mail) |
|
Validation |
Personne validant la fiche |
|
Version |
1.0 |
|
Date création |
Date de réalisation |
|
Date validation |
Date de validation |
|
API |
Description rapide de l’API EJB employée 1.0 / 2.0 |
|
Dépendances statiques |
Ensemble des conditions nécessaires à la compilation du composant (classes parentes, interfaces…) |
|
Dépendances dynamiques |
Ensemble des conditions nécessaires à l’exécution du composant (classes…) |
|
Objets associés |
Objets annexes utilisables par le composant. Notion d’agrégation de composant. |
|
Design pattern |
Design pattern utilisé comme utilisateur ou participant |
2°) Contexte d’installation :
|
Serveur |
Serveur EJB |
|
Configuration |
Nature de la configuration (Bean-Management/Container) |
|
API |
Listes des API utilisées |
|
Déploiement |
Fichier de déploiement |
|
Script |
Script d’installation |
|
Base de données |
Alias et/ou URL des bases de données |
|
Ressource JNDI |
Identifiants JNDI |
|
Topic/Queue JMS |
Identifiants de Messages |
3°) Contexte de
fonctionnement :
|
Propriétés |
Description des propriétés utilisées par le fichier de déploiement |
|
Traitements |
Description des principaux traitements (mini-algorithme) |
|
Méthodes publiques |
Liste des procédures et fonctions publiques |
|
Ressources « consommées » |
Liste des ressources utilisées (message…) |
|
Ressources « produites » |
Liste des ressources produites (messages, base et tables modifiées, …) |
4°) Contexte de validation :
|
Conformité de modélisation |
Validation de la conformité avec la modélisation. Lorsque la correspondance n’est pas directe, en justifier la cause. |
|
Intégration objet |
Validation de la conformité objet (méthodes de l’interface suffisantes…) |
|
Intégration architecture |
Validation de la cohérence et du fonctionnement dans l’architecture. Lorsque l’architecture est incomplète, utiliser des simulateurs pour les parties manquantes |
|
Bugs majeurs |
Liste des bugs importants découverts ( testeur, date, contexte, titre, priorité …). Ces bugs doivent être corrigés et contrôlés avant toute amélioration. |
|
Bugs mineurs |
Liste des bugs devant être corrigés sans priorités particulières. |
5°) Contexte de correction :
|
Corrections majeurs |
Informations sur les corrections de bugs majeurs dans la phase courante. |
|
Corrections mineurs |
Informations sur les corrections de bugs mineurs pour la phase suivante. |
|
Répercussion de modélisation |
Changement à apporter dans la modélisation (diagramme de classes…) |
|
Répercussion objet |
Changement à apporter dans l’organisation objet |
|
Répercussion d’architecture |
Changement à apporter dans l’organisation de l’architecture |
6°) Contexte d’amélioration :
|
Améliorations majeures |
Améliorations importantes à réaliser (design pattern, performances…) avec numéro de priorité dans la phase courante. |
|
Améliorations mineures |
Améliorations à réaliser en prochaine phase. |
|
Amélioration objet |
Amélioration de l’organisation objet (classes interfaces, indépendantes…) |
|
Répercussion de modélisation |
Répercussion des améliorations probables dans la modélisation. Ces remarques pourront être pris en compte pour la modélisation de la prochaine phase. |
|
Répercussion objet |
Répercussion sur les associations et l’utilisation par un client. |
|
Répercussion d’architecture |
Répercussion sur l’architecture actuelle. |