REFERENTIEL NORMATIF du CNES Référence : Méthode et Procédure DEMARCHE D'ANALYSE DU LOGICIEL Annexe Technique de la MP RNC-CNES-Q-80-529 APPROBATION Président du CDN ; date et nom :
Page i.1 PAGE D'ANALYSE DOCUMENTAIRE TITRE : MOTS CLES : Analyse Objet UML RESUME : Ce document présente des règles et recommandations pour la démarche d analyse du logiciel orientée objet. SITUATION DU DOCUMENT : Ce document est une annexe technique au document RNC-CNES-Q-80-529 "Démarche de Développement Objet pour les logiciels" qui fait partie de la collection des Méthodes et Procédures associées au Référentiel Normatif du CNES (ECSS et MPM). Ce document est affilié à l'assurance Produit des Logiciels. NOMBRE DE PAGES : 16 Progiciels utilisés / version : Word 97 LANGUE : Française SERVICE GESTIONNAIRE : Délégation à l'assurance de la Qualité du Centre Spatial de Toulouse (DTS/AQ) AUTEUR(S) : DATE : 07/10/00 Jean-Charles POUPLARD / Jean-Alain VERON / Isabelle ZENONE RELECTURE / CONTROLE : Pour ACCORD : Le Président du Comité Technique de Normalisation : CNES 2000 Reproduction strictement réservée à l'usage privé du copiste, non destinée à une utilisation collective (article 41-2 de la loi n 57-298 du 11 Mars 1957).
Page i.2 PAGES DES MODIFICATIONS VERSION DATE PAGES MODIFIEES OBSERVATIONS 1 07/10/00 Document initial Document élaboré avec le support de MMS (C. Pinaud, M.A. Gandrieau) et Virtualité Réelle (T. Leydier)
Page i.3 SOMMAIRE 1. INTRODUCTION... 1 2. OBJET... 1 3. DOMAINE D'APPLICATION... 1 4. DÉMARCHE D ANALYSE DU LOGICIEL... 2 4.1. INITIALISATION DE L ACTIVITÉ D ANALYSE...2 4.1.1. RAPPEL DES FACTEURS QUALITÉ PROJET ET IMPACT SUR L ACTIVITÉ D ANALYSE...2 4.1.2. DÉLIMITATION DES PHASES CONCERNÉES PAR L ACTIVITÉ D ANALYSE...3 4.1.3. DEFINITION DU MAQUETTAGE ET DU PROTOTYPAGE...3 4.1.4. DÉFINITION DES ITÉRATIONS PROPRES À L ACTIVITÉ D ANALYSE...3 4.2. ANALYSE INITIALE...4 4.2.1. DÉFINITION DES SOUS-SYSTÈMES...4 4.2.2. APPROCHES POUR L ANALYSE INITIALE...4 4.2.3. IDENTIFICATION DES ACTEURS...4 4.2.4. DESCRIPTION DU CONTEXTE PROJET...5 4.2.5. IDENTIFICATION DES ÉVÉNEMENTS...6 4.2.6. IDENTIFICATION DES CAS D UTILISATION...6 4.2.7. DESCRIPTION DES CAS D UTILISATION...6 4.2.8. DESCRIPTION DU SUIVI DES ÉVENEMENTS...6 4.2.9. DESCRIPTION DES INTERACTIONS...6 4.2.10. DESCRIPTION DES OBJETS...7 4.2.11. PREMIERE IDENTIFICATION DES CLASSES...7 4.3. PREMIÈRE ITÉRATION...8 4.3.1. PREMIÈRE DESCRIPTION DE LA VUE LOGIQUE...8 4.3.2. RECHERCHE DES CATÉGORIES, RECHERCHE DE NOUVELLES CLASSES...8 4.3.3. DÉSCRIPTION DE LA DYNAMIQUE...8 4.3.4. COMPLÉMENT...8 4.3.5. EVALUATION DE LA QUALITE DE L ANALYSE...9 4.4. AUTRES ITÉRATIONS...9 5. PHENOMÉNOLOGIE DE L ACTIVITÉ D ANALYSE DU LOGICIEL... 10
Page 1 1. INTRODUCTION Ce document est une annexe technique au document RNC-CNES-Q-80-529 «Démarche de Développement Objet pour les logiciels». 2. OBJET Cette annexe décrit les règles et recommandations qui concernent la démarche d analyse du logiciel orientée objet. Il fait partie du référentiel documentaire DDO (Démarche de développement du logiciel orienté objet) et présente des particularités qui sont liées à la phase d analyse du logiciel. 3. DOMAINE D'APPLICATION Ce document est conçu à l'attention de plusieurs types d utilisateurs : le chef de projet qui doit connaître les activités menées lors de l analyse, faire les choix nécessaires à partir des règles générales en fonction des spécificités du projet et s'assurer de la mise en œuvre des dispositions retenues, le responsable qualité qui doit avec le chef de projet valider les règles relatives à l analyse, extraire les recommandations pertinentes pour son projet et éventuellement adapter et compléter les règles en fonction du contexte, le responsable technique qui est chargé de l encadrement technique de l activité d analyse, l ingénieur qualité qui doit appliquer les règles de contrôle de la qualité relatives à l analyse, les équipes chargées de l analyse du logiciel qui doivent appliquer les règles et les recommandations retenues.
Page 2 4. DEMARCHE D ANALYSE DU LOGICIEL Définition des Sous Systèmes Approche pour l analyse initiale Identification des acteurs Description du Contexte Description des événements Description des cas d utilisation Description du suivi des évènements Description des interaction Description des objets Vue générale de l analyse du logiciel Première identification des classes Description de la vue logique Recherche de nouvelles classes Description de la dynamique Compléments de la vue logique Evaluation de la qualité Analyse initiale Itération 4.1. INITIALISATION DE L ACTIVITE D ANALYSE L initialisation de l activité d analyse est conduite par le chef de projet ou le responsable technique, en accord avec le responsable qualité. Il s agit de clarifier un certain nombre d objectifs et de définir des règles qui vont guider toute l activité d analyse. 4.1.1. RAPPEL DES FACTEURS QUALITE PROJET ET IMPACT SUR L ACTIVITE D ANALYSE Les facteurs qualité prépondérants pour le projet sont évalués en début de projet. Ils vont guider la mise en œuvre de la démarche et les choix essentiels. En ce qui concerne l analyse, deux facteurs vont intervenir sur la mise en œuvre : - la maintenabilité - la réutilisabilité La définition des facteurs qualité et de leur évaluation est décrite dans l annexe C du référentiel DDO (Chapitre «Facteurs qualité»). L évaluation des objectifs de réutilisation et la réutilisabilité est décrite dans l annexe C du référentiel DDO (Chapitre «Réutilisation et réutilisabilité»). On définit notamment en fonction des facteurs qualité, quelles sont les règles de vérification de la qualité de l analyse (décrites dans l annexe C du référentiel DDO (Chapitre «Vérification»)) que l on doit appliquer effectivement sur le projet.
Page 3 4.1.2. DELIMITATION DES PHASES CONCERNEES PAR L ACTIVITE D ANALYSE L activité d analyse peut concerner plusieurs phases : - Dans un processus de développement fondé sur un cycle en V standard, cette activité concerne généralement une seule phase qui est celle de la spécification du logiciel. - Dans un processus de développement alternatif, plusieurs phases vont intervenir. L objectif de cette activité consiste à définir précisément les entrées et les sorties de chacune de ces phases pour le projet courant. Ce travail pourra être mené parallèlement à la définition des itérations propres à l activité d analyse. 4.1.3. DEFINITION DU MAQUETTAGE ET DU PROTOTYPAGE On définit quels sont les maquettes et les prototypes qui sont développés dans le cadre de l analyse ; on définit les moyens de développement et les modes de développement des maquettes ; on définit comment seront validés et utilisés les maquettes et les prototypes. Des règles pour guider la définition des maquettes sont décrites dans l annexe C du référentiel DDO (Chapitre «Maquetage et prototypage»). 4.1.4. DEFINITION DES ITERATIONS PROPRES A L ACTIVITE D ANALYSE Il s agit de définir le principe, le nombre et les critères d arrêt pour les itérations propres à l activité d analyse. - le principe : l activité d analyse sera itérative. Il s agit de choisir entre une itération à «effet de cliquet» et une itération «dialectique». Ces deux types d itérations sont définis dans l annexe C du référentiel DDO (Chapitre «Itérations»). - le nombre : il s agit de définir le nombre minimal et maximal d itérations. Un minorant du nombre minimal est 1 (il y a aura au moins une itération) - les critères d arrêt de l analyse : parmi les critères possible1, on aura : la description des cas d utilisation permet d obtenir une spécification non ambiguë la description des objets et des classes a été effectuée les diagrammes sont cohérents du point de vue des termes utilisés la description de la dynamique des classes les plus complexes dynamiquement a été effectuée la documentation d analyse est complète et vérifiée la vérification de la qualité de l analyse est correcte (cette vérification est basée sur les règles qui ont été retenues pour le projet) 1 Chaque projet devra définir ses propres critères : la liste proposée est donnée à titre illustratif.
Page 4 les maquettes et prototypes prévus ont été réalisés, validés et livrés On trouve dans l ensemble de la documentation DDO des indications complémentaires qui illustrent ces critères et les actions ou fournitures associées. 4.2. ANALYSE INITIALE L analyse initiale est la première étape de l analyse : elle va de la décomposition en sous-systèmes, à la définition de la première vue des classes de l analyse. 4.2.1. DEFINITION DES SOUS-SYSTEMES La partition du logiciel en sous-systèmes est souvent effectuée en amont de l analyse du logiciel, lors de l analyse du système ou lors de la définition des exigences. Si cette définition n a pas été effectuée, ce sera la première tâche de l analyse. La définition des sous-systèmes est complétée par une vue qui les décrit et qui présente l interface complète entre chacun des sous-systèmes. On pourra utiliser un diagramme de classe UML pour représenter les sous-systèmes. Les règles et principes à suivre pour découper un logiciel en sous-systèmes sont décrits dans l annexe C du référentiel DDO (Chapitre «Sous-systèmes»). L ensemble des activités décrites dans la suite de ce document sera effectué sous-système par soussystème. 4.2.2. APPROCHES POUR L ANALYSE INITIALE L analyse orientée objet consiste à décrire une décomposition comportementale et une décomposition statique. La description du comportement consiste à décrire ce que fait le logiciel : c est une vue dynamique du logiciel, La décomposition statique consiste à décrire le logiciel sous forme de classes et de catégories, et de relations entre ces classes et catégories : c est une vue statique du logiciel. Le présent document donne le démarche à suivre pour établir ces deux décompositions. Pour un projet ayant une forte composante dédiée aux manipulations de données, il sera plus facile de démarrer par une décomposition statique avant de détailler la description comportementale. On pourra alors modifier l enchaînement des activités décrites dans les chapitres suivants en parallélisant : identification des acteurs, des cas d utilisation et des scénarios identification des classes. 4.2.3. IDENTIFICATION DES ACTEURS La description des acteurs permet d identifier précisément la «frontière» du logiciel à analyser en définissant les personnes, matériels ou autres logiciels qui interagissent avec ce logiciel. Cette identification est effectuée en suivant les règles décrites dans la MPM UML (Chapitre «Acteurs»)
Page 5 4.2.4. DESCRIPTION DU CONTEXTE PROJET DIAGRAMME DU CONTEXTE Le diagramme de contexte est un diagramme de collaboration à haut niveau qui permet de montrer les interactions à haut niveau entre acteurs et logiciel vu comme une boîte noire. Message Acteur Application Message Message Message DESCRIPTION DES LIMITES Acteur Acteur La description des limites du projet permet de formaliser la «frontière» du logiciel en définissant clairement ce qui fait partie du logiciel, et ce qui n en fait pas partie. La description des limites consiste à identifier un premier niveau de cas d utilisation directement rattachés aux acteurs définis dans l étape précédente. Ces cas sont décrits dans un diagramme de cas d utilisation. La description des limites du projet est très importante dans le cas où on étendrait l analyse au domaine et au métier : cette description permet de limiter l analyse du domaine et de séparer les origines domaines et les origines application. Acteur Mécanisme Application Métier
Page 6 4.2.5. IDENTIFICATION DES EVENEMENTS L identification des événements est un travail complémentaire à la description des acteurs. Ce travail va permettre une bonne préparation de la description des cas d utilisation. Un événement est attaché au monde réel : il représente sous forme abstraite un incident ou un signal qui marque un changement d état. Un événement est ainsi toujours associé à un récepteur : ce récepteur est généralement un acteur ou un objet du monde réel. On décrit en début d analyse les événements en précisant pour chacun d eux : La signification de l événement : c est la description de ce qui se passe dans le monde réel lorsque l événement se produit l objet ou l acteur destination des paramètres éventuels 4.2.6. IDENTIFICATION DES CAS D UTILISATION L identification des cas d utilisation consiste à identifier a priori sans les décrire, l ensemble des cas d utilisation possibles du logiciel. Cette identification est effectuée sur la base de la description du contexte projet et en suivant les règles décrites dans la MPM UML (Chapitre «Structuration des cas d utilisation»). 4.2.7. DESCRIPTION DES CAS D UTILISATION La description graphique des cas d utilisation est effectuée avec les diagrammes de cas d utilisation d UML. La description textuelle des cas d utilisation est effectuée à l aide d un modèle de cas d utilisation fourni dans la MPM UML. Les règles à suivre pour décrire les cas et remplir le modèle sont décrites dans la MPM UML (Chapitres «Diagramme des cas d utilisation» et «Description textuelle des cas») 4.2.8. DESCRIPTION DU SUIVI DES EVENEMENTS La description du suivi des événements consiste à identifier des séquences d enchaînements d événements : ces séquences sont déclenchées par des acteurs. Les événements envoyés s adressent à des objets qui peuvent eux-mêmes réagir par l envoi de nouveaux événements. Cette description doit être simple, naturelle sans détailler les mécanismes de déclenchement. Elle doit s attacher également à faire ressortir les objets du problème. Elle est formalisée à l aide de diagrammes de séquences très simplifiés. Les règles à suivre pour décrire les diagrammes de séquence sont décrites dans la MPM UML (Chapitres «Diagramme de séquence») 4.2.9. DESCRIPTION DES INTERACTIONS La description des interactions consiste à regrouper sur un diagramme les objets qui participent à un scénario et à montrer leurs interactions sans entrer dans le détail des messages échangés. Elle doit s attacher également à faire ressortir les objets du problème.
Page 7 Elle est formalisée à l aide de diagrammes de collaboration très simplifiés. Les règles à suivre pour décrire les diagrammes de collaboration sont décrites dans la MPM UML (Chapitres «Diagramme de collaboration»). 4.2.10. DESCRIPTION DES OBJETS Lors de l analyse initiale, on décrit sous forme de tableau de synthèse, la liste des objets que l on a identifiés lors de la description des acteurs, des cas d utilisation et des scénarios. Pour chaque objet, on traduit sous forme de responsabilité les interactions associées. L identification est soit immédiate à partir des diagrammes d interactions, soit effectuée au travers d une analyse du vocabulaire. On mènera une analyse du vocabulaire lorsque l on veut obtenir une bonne décomposition en objets : l approche à partir des diagrammes d interactions est plus fonctionnelle et donne de moins bons résultats2 3. On recherchera une bonne décomposition en objets en phase d analyse : lorsque l on étend l analyse au domaine (cas d un projet de type filière ou d un fort besoin de réutilisabilité), lorsque l on réutilisera en phase de conception, les résultats de l analyse. La technique d analyse du vocabulaire est décrite dans l annexe C du référentiel DDO (Chapitre «Principes d initialisation d une décomposition objet»). 4.2.11. PREMIERE IDENTIFICATION DES CLASSES L identification des classes consiste à grouper les objets décrits dans l étape précédente. On groupera dans une classe les objets qui ont un comportement semblable. L identification des classes donne lieu à la production d un tableau des classes. On utilise ensuite la technique des catégories pour compléter les classes issues de l analyse du vocabulaire. On met en œuvre enfin la technique du tableau noir pour affiner les classes. Les techniques des catégories et du tableau noir sont décrites dans l annexe C du référentiel DDO (Chapitre «Principes d initialisation d une décomposition objet»). 2 La description des objets nécessite une approche globale pour le logiciel complet, ou éventuellement pour chaque sous-système. L utilisation exclusive des diagrammes d interaction implique des vues partielles et cloisonnées des objets participants, ce qui est incompatible avec le besoin d approche globale. 3 L analyse du vocabulaire doit cependant partir des cas d utilisation et des diagrammes d interactions décrits et se limiter à ce vocabulaire ci.
Page 8 4.3. PREMIERE ITERATION La première itération est obligatoire. 4.3.1. PREMIERE DESCRIPTION DE LA VUE LOGIQUE La première description de la vue logique consiste à décrire un diagramme de classe. Pour chaque classe, on décrit la justification de son existence (lien avec un cas d utilisation) et une liste de responsabilités. Les règles à suivre pour décrire cette vue logique sont décrites dans la MPM UML (Chapitres «Vue logique») 4.3.2. RECHERCHE DES CATEGORIES, RECHERCHE DE NOUVELLES CLASSES Lors de la première itération, on va chercher à organiser les classes afin d obtenir un véritable modèle. Pour ce faire, on va appliquer des règles décrites dans l annexe C du référentiel DDO (Chapitre «Règles d itérations sur les catégories et les classes») en se focalisant sur les règles applicables en analyse. 4.3.3. DESCRIPTION DE LA DYNAMIQUE La description de la dynamique complémentaire consiste à compléter pour les classes à comportement complexe leur description par un diagramme états - transitions ou un diagramme d activités. Les règles à suivre pour élaborer ces diagrammes ainsi que la notion d objet à comportement complexe sont décrites dans la MPM UML (Chapitre «Vue dynamique»). 4.3.4. COMPLEMENT 4.3.4.1. COMPLEMENTS DE SPECIFICATION Le complément de spécification consiste à décrire : des spécifications de performances : les performances peuvent concerner des aspects quantitatifs comme la taille mémoire maximale utilisée ou le temps de réponse sur chaque fonction, mais peuvent également concerner des aspects qualitatifs comme l ergonomie, la souplesse, etc. des interfaces à respecter, les facteurs qualité prépondérants applicables en phase de conception et de codage, des contraintes sur le processus d implémentation (documentation, gestion de configuration, traçabilité, autres outils), d autres contraintes opérationnelles. 4.3.4.2. COMPLEMENTS : MISE EN CONFORMITE Cette étape consiste à reprendre les cas d utilisation et les diagrammes d interaction. On reprendra les cas d utilisation afin d améliorer leur complétude et introduire les termes créés lors de l identification des classes et des catégories.
Page 9 On ne visera pas l exhaustivité4. On vise à décrire les cas qui permettent de rendre la spécification non ambiguë en vue de son utilisation par les architectes. On reprendra les diagrammes de collaboration et de séquence afin de les compléter éventuellement et introduire les termes créés lors de l identification des classes et des catégories. 4.3.5. EVALUATION DE LA QUALITE DE L ANALYSE Cette vérification est basée sur les règles de vérification qui ont été retenues pour le projet. L ensemble des règles de vérification est présenté dans l annexe C du référentiel DDO (Chapitre «Vérification»). 4.4. AUTRES ITERATIONS Les autres itérations sont facultatives : elles doivent être planifiées. Les principes d itération sont présentés dans l annexe C du référentiel DDO (Chapitre «Principes d itération»). 4 On ne confondra exhaustivité et non ambiguïté.
Page 10 5. PHENOMENOLOGIE DE L ACTIVITE D ANALYSE DU LOGICIEL Le diagramme suivant montre la répartition de la charge consommée lors de l activité d analyse. Les valeurs sont exprimées en pourcentage de la charge totale de l activité. Cette répartition correspond à une phénoménologie standard et pourra être considérée comme une référence. Charge 20 18 16 14 12 10 8 6 4 2 0 3 3 IDENTIFICATION DES ACTEURS DEFINITION DES SOUS SYSTEMES 5 IDENTIFICATION DES EVENEMENTS DESCRIPTION DU CONTEXTE PROJET 3 10 DESCRIPTION DES CAS D UTILISATION IDENTIFICATION DES CAS D UTILISATION 18 8 DESCRIPTION DES INTERACTIONS DESCRIPTION DU SUIVI DES EVENEMENTS 6 3 3 RECHERCHE DES CATEGORIES DESCRIPTION DES OBJETS PREMIERE IDENTIFICATION DES CLASSES PREMIERE DESCRIPTION DE LA VUE LOG... DESCRIPTION DE LA DYNAMIQUE COMPL... 8 6 COMPLEMENTS EVALUATION DE LA QUALITE DE L ANALYSE 8 9 7
REFERENTIEL NORMATIF REALISE PAR : Centre Spatial de Toulouse Délégation à l'assurance de la Qualité 18 Avenue Edouard Belin 31401 TOULOUSE CEDEX 4 Tél : 05 61 27 31 31 - Fax : 05 61 27 31 79 CENTRE NATIONAL D'ETUDES SPATIALES Siège social : 2 pl. Maurice Quentin 75039 Paris cedex 01 / Tel. (33) 01 44 76 75 00 / Fax : 01 44 46 76 76 RCS Paris B 775 665 912 / Siret : 775 665 912 00082 / Code APE 731Z