DEMARCHE DE DEVELOPPEMENT OBJET POUR LES LOGICIELS

Transcription

1 REFERENTIEL NORMATIF du CNES Référence : Méthode et Procédure ACCORD du Bureau de Normalisation BN n 26 du 18/09/2006 APPROBATION Président du CDN Alain CUQUEL

2

3 Page 3 PAGE D'ANALYSE DOCUMENTAIRE TITRE : MOTS CLES : Analyse, Conception, Objet NORME EQUIVALENTE : Néant OBSERVATIONS : Néant RESUME : Ce document présente les grandes lignes de la démarche de développement orientée objet pour les logiciels. Il est complété par quatre annexes donnant des règles sur la mise en œuvre de cette démarche, un exemple d'application et des documents type. Il annule et remplace le document RNC-CNES-Q «Démarche de développement objet pour les logiciels» (changement de nomenclature). SITUATION DU DOCUMENT : Ce document fait partie de la collection des Méthodes et Procédures associées au Référentiel Normatif du CNES (ECSS et MP). Ce document est affilié au document RNC- ECSS-E «Software Part 1 : principles and requirements». NOMBRE DE PAGES : 17 LANGUE : Française Progiciels utilisés / version : Word 2002 SERVICE GESTIONNAIRE : Inspection Générale Direction de la Fonction qualité (IGQ) AUTEUR(S) : DATE : 28/04/06 G. GUILLOT (DCT/AQ/SO) JEAN- CHARLES DAMERY (DCT/AQ/SO) RELECTURE / CONTROLE : M. RENARD P. ARBERET C. PELLIZZONI CNES 2005 Reproduction strictement réservée à l'usage privé du copiste, non destinée à une utilisation collective (article 41-2 de la loi n du 11 Mars 1957).

4 Page 4 PAGES DES MODIFICATIONS VERSION DATE PAGES MODIFIEES OBSERVATIONS 1 10/12/05 Création Document élaboré avec le support de Virtualité Réelle (T. Leydier). Annule et remplace le document RNC-CNES-Q «Démarche de développement objet pour les logiciels». Inclut :Changement d identification des documents, simplification, modifications pour prise en compte du retour d expérience (groupe de travail SPICE sur les spécifications), conformité à l évolution de l ECSS E40 part 1B «Software Part 1 : principles and requirements», et conformité avec les autres documents normatifs traitant du développement. Accepté au BN n 26 du 18/09/2006.

5 Page 5 TABLE DES MATIERES 1. INTRODUCTION OBJET LE REFERENTIEL DOCUMENTAIRE DDO VUE GENERALE DU REFERENTIEL DETAIL DU REFERENTIEL DETAIL DU REFERENTIEL NIVEAU GENERAL NIVEAU FORMALISME ET DEMARCHE NIVEAU LANGAGE COMMENT UTILISER LE REFERENTIEL DDO DOCUMENTS DE REFERENCE REFERENCIEL NORMATIF REFERENCES TECHNIQUES PRESENTATION DES REGLES RUBRIQUES CODIFICATION DES REGLES PROCESSUS DE DEVELOPPEMENT... 14

6 Page 6 1. INTRODUCTION Ce document «Démarche de développement objet pour les logiciels» est rattaché à la norme RNC-ECSS- E40 «Ingénierie des logiciels». 2. OBJET Ce document normatif est le document de plus haut niveau d un ensemble documentaire complet dont l objectif est le développement orienté objet pour les logiciels. Il contient : une description générale du référentiel documentaire «Démarche de développement objet». Ce référentiel documentaire est baptisé DDO. une description des processus de développement.

7 Page 7 3. LE REFERENTIEL DOCUMENTAIRE DDO 3.1. VUE GENERALE DU REFERENTIEL La structure documentaire pour le développement orienté objet a été définie afin d éviter les redondances. Elle comprend 3 niveaux : général, formalisme et démarche, langage. Niveau général Document chapeau DDO ANNEXE A : PRINCIPES ANNEXE B : DOCUMENTATION ANNEXE C : TERMINOLOGIE ANNEXE D : EXEMPLES Niveau Formalisme et Démarche UML HOOD Niveau Langage ADA ADA BORD FORTRAN 77 C FORTRAN 90 C++ JAVA

8 Page DETAIL DU REFERENTIEL NIVEAU GENERAL Le niveau général contient toutes les règles et recommandations générales à une démarche de développement orientée objet, quelle que soit la méthode d analyse ou de conception choisie, et quel que soit le langage de programmation DOCUMENT CHAPEAU DDO Le document chapeau est le présent document. Il contient une introduction à l ensemble du référentiel documentaire, un guide de lecture et une description des processus de développement orienté objet. Le guide de lecture est le point d entrée recommandé pour un utilisateur novice ANNEXE A : PRINCIPES DE MISE EN ŒUVRE DES CONCEPTS OBJETS L annexe A de DDO contient les principes de mise en œuvre des concepts objets exprimés sous forme de règles : ces principes sont communs aux méthodes, communs aux formalismes, mais également communs à l activité d analyse et à l activité de conception du logiciel. La principale justification d existence de cette annexe est la non-duplication de règles ou de principes communs. Elle présente ainsi des règles indépendantes, organisées en chapitres mais ne comporte pas de fil directeur comme une démarche ou un enchaînement d activités. Sauf cas exceptionnel, on ne lira pas ce document de bout en bout, mais on s y rapportera lors de la lecture d autres documents comme la MP UML ou la MP HOOD ANNEXE B : DOCUMENTATION L annexe B de DDO contient les plans types des documents à produire en phase d analyse et de conception dans le cadre d une démarche de développement orienté objet ANNEXE C : TERMINOLOGIE L annexe C décrit la terminologie «orientée objet» utilisée au CNES. Elle comporte deux volets : la terminologie générale, la terminologie propre à une méthode ou un langage. Plus qu une introduction à la terminologie, cette annexe a l ambition d expliquer les concepts objets standard sur lesquels s appuient les recommandations décrites dans les documents méthodologiques ANNEXE D : EXEMPLES L annexe D contient un exemple complet décrivant la mise en œuvre d une démarche orientée objet de l initialisation d un projet jusqu aux activités de réalisation et de déploiement : cet exemple est un exemple fabriqué afin d illustrer les démarches d analyse et de conception et les règles décrites dans DDO. Il donne ainsi une cohérence à l ensemble de la démarche NIVEAU FORMALISME ET DEMARCHE Le niveau formalisme et démarche contient les règles et recommandations propres aux méthodes et formalismes.

9 Page REGLES ET RECOMMANDATIONS POUR L UTILISATION DU FORMALISME UML UML est un formalisme de description très riche et très fourni. Ce document décrit les règles et recommandations à suivre lors de la mise en œuvre de UML sur un projet CNES : comment utiliser chaque diagramme, comment structurer les vues, etc. Ce document décrit également dans le détail : La «Démarche d analyse du logiciel orientée objet» préconisée au CNES. La «Démarche de conception du logiciel orientée objet» préconisée au CNES lorsque l on utilise UML REGLES ET RECOMMANDATIONS POUR L UTILISATION DE LA METHODE HOOD Ce document décrit les règles et recommandations à suivre lors de la mise en œuvre de la méthode HOOD sur un projet CNES NIVEAU LANGAGE Le niveau langage contient les règles et recommandations propres aux langages.

10 Page COMMENT UTILISER LE REFERENTIEL DDO Trois cas principaux d utilisation de DDO ont été identifiés : Utilisation de DDO pour l analyse Le client dans le cadre de l écriture de la STBL, ou le fournisseur dans le cadre de l appropriation de l expression des besoins de la SRL, suit une démarche orientée objet. La démarche d analyse à suivre est décrite dans la MP UML Utilisation de DDO pour la conception Le fournisseur suit une démarche orientée objet. Deux cas sont alors possibles : La démarche choisie est descendante et le formalisme est HOOD : la démarche de conception à suivre est décrite dans la MP HOOD. La démarche choisie est ascendante et le formalisme est UML : la démarche de conception à suivre est décrite dans la MP UML Utilisation de DDO pour la réalisation Le fournisseur réalise dans un contexte de conception orienté objet. Plusieurs cas sont alors possibles selon les langages cibles : Le langage cible est JAVA : les règles de programmation à suivre sont décrites dans la MP JAVA Le langage cible est C++: les règles de programmation à suivre sont décrites dans la MP C++ Le langage cible est ADA 95 : les règles de programmation à suivre sont décrites dans la MP ADA ou ADA BORD Le langage cible ne supporte pas les mécanismes objets, comme FORTRAN, C ou ADA 83 : des règles de traduction des mécanismes objets sont décrites dans l annexe A de DDO (Chapitre Codage). En outre les règles de programmation sont respectivement décrites dans les MP FORTRAN, C et ADA ou ADA BORD.

11 Page DOCUMENTS DE REFERENCE Pour faciliter la lecture, les documents de références sont présentés dans cette section suivant la classification suivante : Les normes et standards constituant le référentiel normatif sur lequel s appuie ce document, en distinguant les normes de niveau général couvrant l ensemble des processus et les normes spécifiques d une activité ou d une technologie donnée. Les références techniques concernant les technologies visées dans ce document, classées par technologie REFERENCIEL NORMATIF NORMES GENERALES ECSS RNC-ECSS-Q-80, Assurance Produit des Logiciels (version B) RNC-ECSS-E-40, Ingénierie des Logiciels (version B, parties 1 & 2) ISO ISO/IEC 12207, Processus du cycle de vie des logiciels, NORMES SPECIFIQUES CNES RNC-CNES-E , Contenu d'une Spécification Technique de Besoins Logiciel RNC-CNES-Q , Contenu d'un Dossier des logiciels réutilisés RNC-CNES-E , Règles et recommandations pour l utilisation du formalisme UML RNC-CNES-E , Règles et recommandations pour l utilisation du formalisme HOOD RNC-CNES-Q , Règles et recommandations pour l utilisation du langage Ada RNC-CNES-Q-80-5xx, Règles et recommandations pour l'utilisation du langage FORTRAN RNC-CNES-Q , Règles et recommandations pour l'utilisation du langage C RNC-CNES-Q , Règles et recommandations pour l'utilisation du langage C++ RNC-CNES-Q , Règles et recommandations pour l utilisation du langage Java RNC-CNES-Q , Règles et recommandations pour l utilisation du langage Ada pour les logiciels embarqués RNC-CNES-Q , Règles essentielles pour l'utilisation du langage FORTRAN 77 RNC-CNES-Q , Règles essentielles pour l'utilisation du langage FORTRAN REFERENCES TECHNIQUES GENERAL ESA PSS-05-0, Software Engineering Standards, Issue 2, 1991 Guidelines and Recommendations for use of object-oriented techniques, ATR report D1400, 1997

12 Page PROCESSUS ET GESTION DE PROJET Anchoring the SW process, Boehm IEEE Computer Society Press SW Risk Management, Boehm IEEE Computer Society Press Le processus Unifié de développement logiciel ; Jacobson, Booch & Rumbaugh 1999 Addison Wesley (édition française Eyrolles 2000) RAD Une méthode pour développer plus vite, Hugues 1996 InterEditions DEVELOPPEMENT OBJET Object Oriented SW Engineering : a Use Case driven Approach ; Jacobson 1992 Addison Wesley The object Advantage : Business Process Reengineering with Object Technology 1994 Addison Wesley Modeling Reactive Systems with Statecharts ; Harel & Politi, 1998 Mc Graw Hill UML The Unified Modelling Language Reference Manual.3 [OMG] UML user Guide ; Jacobson, Booch & Rumbaugh Addison Wesley HOOD HOOD Technical Group, HOOD Reference Manual, release 4, SCHEMAS D ANALYSE ET DE CONCEPTION Design Patterns ; Gamma, Helm, Johnson & Vlissides, 1994 Addisson Wesley A system of design patterns ; Buschmann, Meurier, Rohnert & Sommerland, 1996 John Wiley & Sons DIVERS The Common Object Request Broker : Architecture and Specification (CORBA) ; OMG, 1996 Specification and Description Language (SDL) ; CCITT, 1998

13 Page PRESENTATION DES REGLES RUBRIQUES Pour chaque règle, la description fait apparaître les rubriques suivantes : - la référence de la règle, - l'énoncé de la règle, - la description de la règle [si nécessaire], - la justification de la règle [si nécessaire], - un exemple [si nécessaire] CODIFICATION DES REGLES La codification utilisée pour référencer les règles est la suivante : <Domaine>.<Règle> <Domaine> est un mot clé désigné dans une liste et <Règle> un acronyme qui précise la règle dans le domaine. La liste des mots clés pour domaine est définie dans le tableau suivant : Acronyme de domaine Codage ComportDyn ComportStat Configuration Doc Formalisation Formation Infrastruc InitObjet ItérCatClass Management MécanBase Person Qualité Sous-Système Tâches Tests Traçabilité VerifDyn VerifStatique Signification règles associées au codage règles associées au comportement dynamique règles associées au comportement statique règles associées à la gestion de configuration règles associées à la documentation règles associées à la formalisation règles associées à la formation règles associées à l infrastructure règles de recherche des objets initiaux règles d itérations sur les classes et les catégories règles associées au Management règles associées à des mécanismes de base règles de personnalisation du projet règles associées à l assurance et au contrôle qualité règles associées aux sous-systèmes règles associées à la définition des tâches règles associées au test et à la validation règles associées à la Traçabilité règles associées à la vérification dynamique règles associées à la vérification statique

14 Page PROCESSUS DE DEVELOPPEMENT Expression du besoin système Cette activité consiste à décrire le système complet : elle n est donc pas circonscrite au logiciel. Elle donne lieu à la production d un document : le STB. Elle reste très en amont du développement. Le principal objectif est la définition des sous-systèmes et la partition entre le logiciel et le matériel. Elle est de fait faiblement impactée par les technologies objets. On pourra utiliser à ce niveau des diagrammes de déploiement de type UML afin de décrire l architecture matérielle du système et la distribution du logiciel. Expression du besoin logiciel L activité d expression du besoin logiciel est réalisée par le client dès lors qu il y a un logiciel à développer. Elle consiste à décrire en détail les exigences associées au logiciel. Pour décrire ces exigences, le client peut utiliser une démarche classique ou une démarche orientée objet : Dans une démarche classique, la spécification logicielle est le résultat d une décomposition des fonctions du système définies dans la spécification des besoins : c est une décomposition fonctionnelle. Dans une démarche orientée objet, cette décomposition fonctionnelle est remplacée par une décomposition comportementale et une décomposition statique. La description du comportement du logiciel consiste à décrire ce que fait le logiciel : dans une approche orientée objet, cette description du comportement est établie à l aide de cas d utilisation et de scénarios, et non pas de fonctions. La décomposition statique du logiciel complète la description du comportement en détaillant les objets : dans une approche orientée objet, la décomposition statique montre les objets du monde réel (le monde du problème). Les règles à suivre pour mener une analyse lors de la phase de la spécification logicielle sont décrites dans la MP UML (RNC-CNES-E ) et dans la MP STBL (RNC-CNES-E ). L expression du besoin logiciel donne lieu à la production d un document : la STBL. Analyse critique de l expression du besoin logiciel L activité d analyse critique de l expression des besoins est effectuée côté fournisseur. L objectif essentiel de cette activité est l appropriation des besoins par l industriel. Cette appropriation peut impliquer : La rédaction d exigences complémentaires (côté industriel). La rédaction d exigences de réalisation du logiciel. La re-formulation de la STBL dans un formalisme ou un langage plus approprié au savoir faire et aux techniques de l industriel.

15 Page 15 La re-formulation d une STBL obtenue à l aide d une démarche classique pourra par exemple donner lieu à la mise en œuvre d une démarche orientée objet. Cette re-formulation donne lieu à la production d un document supplémentaire : la SRL. Lorsque cette analyse conduit à la mise en œuvre d une démarche orientée objet, on suivra la démarche décrite dans la MP UML. Conception préliminaire L activité de conception préliminaire est fortement impactée par les technologies objet. Elle consiste à effectuer les grands choix de conception, à décrire une décomposition statique, une décomposition dynamique et une architecture matérielle. La décomposition statique consiste à décrire le logiciel sous forme d objets et de relations entre ces objets. En conception préliminaire, on s attache à décrire les objets de la solution. La décomposition dynamique consiste à décrire le comportement du logiciel du point de vue de la machine cible et non pas du point de vue de l utilisateur externe. L architecture matérielle consiste à décrire le matériel utilisé et l interface matériel / logiciel mise en œuvre. Au CNES, deux formalismes de conception sont préconisés : il s agit de choisir entre un formalisme UML et un formalisme HOOD. La méthode HOOD combine démarche et formalisme : on associe HOOD3 à une démarche descendante à «effet de cliquet». On peut cependant entrouvrir cette association, dans le cadre notamment de HOOD4 en installant un complément ascendant afin de tendre vers une approche mixte, sans casser le principe de «l effet de cliquet». Dans le cas d approche à base d UML, le choix de la démarche est plus libre : les «puristes» préconisent de coupler démarche objet et approche ascendante associée à une itération dialectique, ce qui améliore la réutilisabilité de la solution mais peut conduire à des problèmes de maîtrise du projet. On pourra donc très bien décider de la mise en œuvre d UML sur la base d une analyse descendante stricte associée à des «effets de cliquet». Le choix du formalisme peut être guidé par les critères suivants : connaissance du formalisme par les membres de l équipe : HOOD est bien connu au CNES et chez les industriels qui œuvrent dans le domaine spatial puissance du formalisme : existence de modèles adaptés, existence de rubriques informationnelles adaptées. UML est très complet. HOOD peut s avérer déficient pour modéliser la dynamique ou les interactions. couverture de l analyse et de la conception, ou uniquement de la conception : HOOD ne couvre que la conception disponibilité, connaissance, ergonomie des outils de modélisation effort d adaptation des outils de modélisation au projet capacité des outils en matière de génération de code compatibilité entre outils de modélisation et langage cible : les outils UML sont orientés C++ ou Java (rarement C ou ADA) langage cible : le passage à ADA est plus naturel avec HOOD réutilisation de modèles existants sous un format particulier

16 Page 16 exigence externe (par exemple HOOD imposée par ESA) Les approches et les règles à suivre pour mener une conception lors de la phase de conception préliminaire sont décrites dans la MP de référence UML (RNC-CNES-E ) ou HOOD (RNC- CNES-E ). L activité de conception préliminaire donne lieu à la production d un document : le DCP. Conception détaillée L activité de conception détaillée consiste à compléter la modélisation de conception préliminaire afin de préparer le codage. Dans une approche non-objet, cette activité consiste souvent à décrire du pseudo-code afin de préciser le fonctionnement des opérations. Dans une approche objet, on va préférer : définir des préconditions et des postconditions : cette approche préférable au pseudo-code permet une réelle plus value à la conception préliminaire sans empiéter sur le code compléter la modélisation par des diagrammes plus précis comme des machines à état Codage Deux cas peuvent se présenter : le langage de programmation supporte les mécanismes objets : dans ce cas, le codage sera facilité. Une étude de faisabilité devra néanmoins évaluer pour les projets critiques l impact en terme de coût en ressources informatiques de l utilisation de ces mécanismes. le langage de programmation ne supporte pas les mécanismes objets. L annexe A «Principes généraux de mise en œuvre des concepts objets» du référentiel DDO explique alors comment passer d un modèle objet à un modèle procédural. Tests et Validation Dans une approche orientée objet, les activités de tests et de validation devront s appuyer sur la description des cas d utilisation et des scénarios. Des règles de mise en œuvre des tests sont précisées dans l annexe A «Principes généraux de mise en œuvre des concepts objets» du référentiel DDO.

17 REFERENTIEL NORMATIF REALISE PAR : Centre National d Etudes Spatiales Inspection Générale Direction de la Fonction Qualité 18 Avenue Edouard Belin TOULOUSE CEDEX 9 Tél. : Fax : CENTRE NATIONAL D'ETUDES SPATIALES Siège social : 2 pl. Maurice Quentin Paris cedex 01 / Tel. (33) / Fax : RCS Paris B / Siret : / Code APE 731Z