Fiches / Articles

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

1°) Contexte objet :


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.