La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

GL 1 Join Us Start Here EXPRESSION, ANALYSE DES BESOINS et Conception

Présentations similaires


Présentation au sujet: "GL 1 Join Us Start Here EXPRESSION, ANALYSE DES BESOINS et Conception"— Transcription de la présentation:

1 GL 1 Join Us Start Here EXPRESSION, ANALYSE DES BESOINS et Conception
LMD informatique – Université de Tébessa Cycle de vie logiciel Analyse des besoins Spécification du logiciel Conception du logiciel Join Us Derdour Makhlouf

2 Pourquoi une analyse informatique ?
Lors des premières informatisations, de nombreux problèmes furent rencontrés, entre autre. · Logiciel ne réalisant pas ce pourquoi il était prévu · Logiciel ne pouvant pas évoluer en fonction de : o Nouveaux matériels o Changements dans l'entreprise o La taille de l'entreprise · Études correctes sur le papier mais impossibles à implémenter · Informatisation bouleversant l'organisation humaine de l'entreprise Alors, deux questions se posent : Comment réaliser un logiciel conforme au cahier des charges? (Avec les Ateliers de Génie Logiciel ou AGL !). Comment réaliser un cahier des charges qui décrive exactement et précisément ce que l'on attend? (L'analyse informatique !).

3 Mais, avant d’entamer la discussion sur la phase d’analyse des besoins, on doit d’abord parlé de la phase d’étude préalable ou d’opportunité L’objectif de cette phase est de : Comprendre le problème Analyser les besoins Etudier: la faisabilité du projet, ses contraintes techniques (coût, temps, qualité) et les alternatives possibles Les résultats attendus sont : Décisions sur la faisabilité Première version du Cahier des charges – Plan général du projet – Estimation partielle (50%) des coûts et des délais Et les moyens utilisés sont : – Plan d’entretien entre: clients, utilisateurs, concepteurs,… – Méthodes – Revues

4 Expression des besoins
Tenter un recensement des besoins en allant interroger divers acteurs et c'est donc aussi une manière de voir ses pratiques. Elle comporte l’Analyse et définition des besoins du système (Pas de solution technique à ce niveau). Définitions des besoins fonctionnels – définition des services – complétude et cohérence – modifications lors des étapes ultérieures • méthodes : langage naturel, langage structuré ou formel (SADT), langage de spécification formelle (ADA). Définitions des besoins non fonctionnels – contraintes sur les fonctions du système – soumis aux évolutions technologiques – interaction entre fonctions: conflits -> solutions – langage naturel ou structuré: matrice besoins/propriétés

5 Analyse des besoins Analyser les besoins en informatique, c'est tenter un recensement des besoins en allant interroger divers acteurs et c'est donc aussi une manière d'analyser ses pratiques. De sorte que l'on peut soulever dans le cadre de l'analyse des besoins certaines problématiques qu'il faudra prendre le temps de clarifier. L'analyse de besoins débouche sur les conclusions qui seront reprises dans le cahier des charges du produit logiciel c'est en partie cette analyse qui justifie la raison du produit Valeur ajoutée du logiciel pour l’entreprise Si l'analyse des besoins conclue à la pertinence d'introduire des produits ou des outils logiciels (soft), elle en présentera clairement les raisons et les objectifs visés. La pertinence du choix logiciel (outils et méthode de développements) par rapport aux objectifs doit être claire voire évidente.

6 Cahier des charges Le cahier des charges est un outil capital. On s'y réfère à différents moments du projet : Il est présenté aux responsables financiers pour la demande de budget nécessaire à l'élaboration du produit. Pendant le développement il est une pièce de référence (entre autres pièces) pour le développeur ou l'éditeur ayant pris en charge le développement. Une fois le produit terminé, il est un élément de référence pour le contrôle de validité du produit fourni. Le CC, en plus de son rôle de descripteur des besoins du client sert de document contractuel et juridique entre le client et de développeur (tout ce qui n’est pas écrit, n’existe pas) Prototypage: Solution idéale pour un CC précis et le moins incomplet possible = dvt d’un sous-pb représentatif du pb global à traiter et examiner l’appréciation du client vis-à-vis du prototype afin de préciser au mieux ces besoins sans omissions ou ambiguïtés.

7 Ce que contient un cahier des charges
Voici une liste de rubriques qui peuvent figurer dans le cahier des charges d'un produit logiciel: Selon Heninger (1980) spécification du comportement externe du système contraintes de réalisation outil de référence aux programmeurs éléments pour les étapes ultérieures réponses aux événements désirables ou non facile à mettre à jour Validation des besoins Par les utilisateurs et développeurs cohérence : Pas de conflit entre besoins complétude: Tous les besoins et contraintes réalisme: Réalisables avec la technologie matériels et logiciels validité: Des fonctionnalités supplémentaires si nécessaire

8 Structure du cahier des charges
1- Présentation du CC – identité du maître d’ouvrage – organisation du document – convention et terminologie 2- Présentation du logiciel à développer – présentation de la problématique visée – domaine d’application – objectif technique et économique – marché – utilisateurs 3- Description de l’environnement d’utilisation – pré-requis d’accueil – contraintes – ressources (variantes) 4- Description des fonctions à satisfaire – fonctions principales – fonctions secondaires – options 5- Description qualitative – Interface utilisateur – Performances :tps de réponses, économie en espace mémoire – Fiabilité (Mean Time Between Failure) – Sureté de fonctionnement (ROLLBACK, robustesse, dépendabilité, protection) 6- Documentation à développer – Documentation des spécifications formelles – code source + binaire – plan de test – manuel qualité – manuel de référence (finalité du logiciel) – manuel d’installation – manuel utilisateur 7- Plan de certification (ISO xxx, x=0,1,2,...) – critères d’évaluation – fichiers de tests – standards et normes 8- Plan de développement – Planning de dvt (dates et documents à fournir) – Coût et dates de paiement - Sanctions éventuelles

9 Exemple : Un produit pédagogique multimédia interactif
Une analyse de besoins peut recouvrir un simple recensement de demandes auprès des enseignants par exemple. Leurs demandes peuvent être plus ou moins spontanées ou influencées par une politique d'établissement ouverte ou fermée au multimédia. Une enquête circonstanciée réalisée avec le concours de l'ensemble des acteurs concernés, soit la direction, les directeurs de programmes d'enseignement, les enseignants. A un certain stade l'avis même des étudiants peut être recueilli.

10 La démarche (Comment réaliser une analyse des besoins ?)
Sur un plan méthodologique strict on peut décrire la démarche d'analyse des besoins en cinq phases : Le cadrage du champ d'investigation (enquête) : Il s'agit de déterminer avec précision le public concerné. Il faudra peut-être discerner plusieurs types de public, une certaine hétérogénéité ou au contraire des caractéristiques communes : âge, niveau d'étude, conditions de vie (difficultés à se déplacer, maladie, etc.), milieu socio-professionnel, etc. Le constat : Il s'agit d'obtenir une représentation aussi précise que possible de la situation dans laquelle se trouve le public auquel on a choisi de s'intéresser (ce qui va, ce qui ne va pas). Le diagnostic : Il complète le constat en présentant des hypothèses expliquant la situation, en risquant un diagnostic. Le projet Le plan d'action : quelle décision va-t-on prendre pour la réalisation du projet ? N'existe-t-il pas déjà un produit ou un outil sur le marché répondant aux objectifs identifiés qui éviterait de se lancer dans un développement coûteux ? S'il existe un produit dans une autre langue, n'est-il pas possible de le traduire et de l'adapter ?

11 Les méthodes Le responsable de l'analyse des besoins va construire un outil adapté à au contexte de son investigation. Parmi les moyens utilisés, citons : Les entretiens individuels (auprès des enseignants, de la direction) Les réunions (groupe d'enseignants cherchant à faire évoluer les outils pédagogiques) Les enquêtes à base de questionnaire (distribution ou en ligne via Internet) L’évaluation des réponses, leur analyse et leur synthèse. L'évaluation des formations en cours Le choix des personnes interrogées est déterminant de même que la manière de formuler les questions (questions ouvertes, fermées, indirectes en évitant d'influencer la personne, pertinence des questions, nombre de questions, etc.)

12 Elaborer des activités d'apprentissage interactives
Exemple Voici quelques exemples de projets répondant à des besoins identifiés : Elaborer des activités d'apprentissage interactives Simuler des activités, des expériences Rechercher et traiter de l'information via le réseau Internet Elaborer des activités de travail collaboratif Conclusion L’expression des besoins vise à : – Définition des services attendus par l'utilisateur – Analyse des fonctions et de leurs contraintes – Pas encore de solutions techniques – Collaboration de l'utilisateur importante – Utilisation de modèles, méthodes ou de techniques: statiques ou dynamiques – Validation correcte avant la phase suivante – Définir les limites – Envisager les évolutions

13 La spécification du logiciel
Tout produit complexe à construire doit d’abord être spécifié ; par exemple un pont de 30 mètres de long, supportant au moins 1000 tonnes, construit en béton, etc. Ces spécifications peuvent être considérées comme un contrat entre un client (la collectivité qui veut réaliser le pont) et un producteur (l’entreprise de génie civil). En informatique, le client et le producteur peuvent être différents selon les phases du cycle de vie.

14 Les différents niveaux de spécifications
A/- La spécification des besoins ou spécification des exigences (‘requirements’) Contrat entre les futurs utilisateurs et les concepteurs. Concerne les caractéristiques attendues (exigences fonctionnelles et non fonctionnelles : efficacité, taille, sûreté, sécurité, portabilité, etc.). Intervient pendant la phase d’analyse des besoins et se rédige en langue naturelle. B/- La spécification d’un système Concerne la nature des fonctions offertes, les comportements souhaités, les données nécessaires, etc. Intervient pendant la phase d’Analyse du système. C/- La spécification d’une architecture de système Contrat entre les concepteurs et les réalisateurs. Intervient pendant la phase de Conception générale. Définit l’architecture en modules de l’application à réaliser. D/- La spécification technique d’un module, d’un programme, d’une structure de données ou d’un type de données : Contrat entre le programmeur qui l’implante et les programmeurs qui l’utilisent. Intervient pendant la phase de Conception détaillée.

15 De manière générale une spécification décrit les caractéristiques attendues (le quoi) d’une implantation (le comment). Dans cette partie nous traitons essentiellement de la spécification d’un système en termes de fonctions, de données, de comportement. Il est souhaitable qu’une spécification soit claire, non ambiguë et compréhensible (Les descriptions en langue naturelle manquent souvent de précision). Les spécifications doivent aussi être cohérentes (pas de contradictions) et complètes. La complétude peut prendre deux formes : ‘Interne’, c’est à dire que tous les concepts utilisés sont clairement spécifiés, ‘Externe’, par rapport à la réalité décrite. Forme illusoire dans la pratique -> on ne peut pas en général spécifier tous les détails ou tout le ‘monde’ qui entoure un système.

16 La conception du logiciel
La phase de conception suit immédiatement la phase d'analyse. Elle est prise en charge par l'équipe de développement. Elle vise à définir une architecture modulaire du logiciel ou encore une décomposition en modules qui facilitera la maintenance et permettra le développement parallèle par différents programmeurs. On regroupe en général sous le terme conception deux étapes distinctes : - Conception globale : elle permet de définir les choix fondamentaux de l'architecture du logiciel en liaison avec l'architecture matérielle. - Conception détaillée : elle décrit précisément chaque module, les algorithmes mis en oeuvre et les traitements effectués en cas d'erreur. La documentation produite sera très utile en phase de maintenance. La phase de conception détaillée n'est pas traitée dans ce cours. Elle a souvent tendance aujourd'hui à être escamotée car la taille des modules étant réduite il n'est souvent pas nécessaire de décrire précisément les algorithmes mis en jeu. La phase de conception globale se termine avec la rédaction du document de conception globale et du plan d'intégration qui ne sera pas traité ici.

17 Principes de conception
Cette partie liste sept principes fondamentaux (proposés par Carlo Ghezzi): • Rigueur, • Séparation des problèmes (« separation of concerns »), • Modularité, • Abstraction, • Anticipation du changement, • Généricité, • Construction incrémentale.

18 Séparation des problèmes
Rigueur La production de logiciel est une activité créative, mais qui doit se conduire avec une certaine rigueur. Certains opposent parfois créativité et rigueur. Il n’y a pas contradiction : par exemple, le résultat d'une activité de création pure peut être évalué rigoureusement, avec des critères précis. Le niveau maximum de rigueur est la formalité, c’est à dire le cas où les descriptions et les validations s’appuient sur des notations et lois mathématiques. Il n’est pas possible d’être formel tout le temps : il faut bien construire la première description formelle à partir de connaissances non formalisées ! Mais dans certaines circonstances les techniques formelles sont utiles. Séparation des problèmes C’est une règle de bons sens qui consiste à considérer séparément différents aspects d’un problème afin d’en maîtriser la complexité. C’est un aspect de la stratégie générale du « diviser pour régner ». Elle prend une multitude de formes : • Séparation dans le temps (les différents aspects sont abordés successivement), avec la notion de cycle de vie du logiciel que nous étudierons en détail, • Séparation des qualités que l’on cherche à optimiser à un stade donné (ex : assurer la correction avant de se préoccuper de l’efficacité), • Séparations des ‘vues’ que l’on peut avoir d’un système (ex : se concentrer sur l’aspect ‘flots de données’ avant de considérer l’aspect ordonnancement des opérations ou ‘flot de contrôle’), • Séparation du système en parties (un noyau, des extensions, …), • Etc. Les méthodes aident à organiser le travail en guidant dans la séparation et l’ordonnancement des questions à traiter.

19 Modularité Un module est un élément de petite taille (en général un ou quelques sous-programmes) qui sert, par assemblage à la construction de logiciels. Un module doit être cohérent et autonome. Un ensemble de modules (un logiciel ou un assemblage de modules) doit être bien organisé en architecture robuste. La modularité se fait ressentir dans la conception et dans la programmation, d'où on peut parler de deux sortes de modules : modules de conception et modules de programmation. Un système est modulaire s’il est composé de sous-systèmes plus simples, ou modules. La modularité est une propriété importante de tous les procédés et produits industriels (cf. l’industrie automobile ou le produit et le procédé sont très structurés et modulaires). La modularité permet de considérer séparément le contenu du module et les relations entre modules (ce qui rejoint l’idée de séparation des questions). Elle facilite également la réutilisation de composants biens délimités. Un bon découpage modulaire se caractérise par une forte cohésion interne des modules (ex : fonctionnelle, temporelle, logique, ...) et un faible couplage entre les modules (relations inter modulaires en nombre limité et clairement décrites). Toute l’évolution des langages de programmation vise à rendre plus facile une programmation modulaire, appelée aujourd’hui ‘programmation par composants’.

20 Anticipation du changement
Abstraction L’abstraction consiste à ne considérer que les aspects jugés importants d’un système à un moment donné, en faisant abstraction des autres aspects (c’est encore un exemple de séparation des problèmes). Une même réalité peut souvent être décrite à différents niveaux d’abstraction. Par exemple, un circuit électronique peut être décrit par un modèle mathématique très abstrait (équation logique), ou par un assemblage de composants logiques qui font abstraction des détails de réalisation (circuit logique), ou par un plan physique de composants réels au sein d'un circuit intégré. L’abstraction permet une meilleure maîtrise de la complexité. Anticipation du changement La caractéristique essentielle du logiciel, par rapport à d’autres produits, est qu’il est presque toujours soumis à des changements continuels (corrections d'imperfections et évolutions en fonctions des besoins qui changent). Ceci requiert des efforts particuliers pour prévoir, faciliter et gérer ces évolutions inévitables. Il faut par exemple : • faire en sorte que les changements soient les plus localisés possibles (bonne modularité), • être capable de gérer les multiples versions des modules et configurations des versions des modules, constituant des versions du produit complet.

21 Construction incrémentale
Généricité Il est parfois avantageux de remplacer la résolution d’un problème spécifique par la résolution d’un problème plus général. Cette solution générique (paramétrable ou adaptable) pourra être réutilisée plus facilement. Exemple : plutôt que d’écrire une identification spécifique à un écran particulier, écrire (ou réutiliser) un module générique d’authentification (saisie d’une identification - éventuellement dans une liste - et éventuellement d’un mot de passe). Construction incrémentale Un procédé incrémental atteint son but par étapes en s’en approchant de plus en plus ; chaque résultat est construit en étendant le précédent. On peut par exemple réaliser d’abord un noyau des fonctions essentielles et ajouter progressivement les aspects plus secondaires. Ou encore, construire une série de prototypes ‘simulant’ plus ou moins complètement le système envisagé. Ces principes sont très abstraits et ne sont pas utilisables directement. Mais ils font partie du vocabulaire de base du génie logiciel. Ces principes ont un impact réel sur beaucoup d’aspects et constituent le type de connaissance le plus stable, dans un domaine où les outils, les méthodes et les techniques évoluent très vite.

22 Processus de conception de logiciel
La conception d'un logiciel peut être effectuée par un processus de résolution de problème qui, à partir d'une conception initiale, identifie des abstractions de plus en plus raffinées. Le processus se répète jusqu'à ce que l'on soit en mesure de préparer une spécification de la conception de chaque abstraction. À chaque itération de ce processus il faut effectuer les étapes suivantes : Étude et compréhension du problème (analyse et spécifications) : examiner le problème sous différents angles. Identifier les caractéristiques d'au moins une solution possible. Il est souvent utile (et parfois indispensable) d'évaluer plusieurs solutions. Décrire toutes les abstractions utilisées dans la solution. Il est conseillé de créer et de mettre au point une description informelle de la conception, ce qui permet de corriger les erreurs de haut niveau avant de commencer la documentation de la conception.

23 On peut raffiner la description donnée précédemment du processus de conception comme suit :
Conception de l'architecture : identifier les sous-systèmes et leurs relations. Spécification abstraite : pour chaque sous-système produire une spécification abstraite des services qu'il offre et des contraintes auxquelles il est soumis. Conception de l'interface : pour chaque sous-système, concevoir et documenter (de manière claire) l'interface avec les autres sous-systèmes. Conception des composants de chaque sous-système. Conception détaillée des structures de données. Conception détaillée des algorithmes. La conception doit représenter le système à plusieurs niveaux d'abstraction. Chaque activité de conception doit produire une spécification formelle correspondante au niveau d'abstraction, ces spécifications seront donc de plus en plus détaillées et doivent aboutir à la spécification des algorithmes et des structures de données permettant l'implantation du système. Mais, malgré l'apparence séquentielle de ce processus, il n'est pas rare d'entamer une nouvelle phase de conception avant la fin de la précédente pour avoir des retours d'information.

24 Qualité de la conception
Une « bonne » conception se définit en termes de la satisfaction des besoins et des spécifications : les critères de qualités peuvent donc varier énormément d'un système à un autre ou même pour deux implantation différentes d'un même système. Par la suite on considérera de préférence les facteurs qui facilitent la gestion du produit tout le long de son cycle de vie. Il s'agit essentiellement de l'extensibilité, la réutilisabilité, la compatibilité, la portabilité la vérifiabilité et la facilité d'emploi. Une bonne structuration participe largement à la production d'un logiciel qui possède ces caractéristiques. Comme dans beaucoup de domaine, cette bonne structuration se base sur la Modularité.

25 La modularité où les boites noires réutilisables...
Découpage du logiciel en modules “indépendants” présentant des caractéristiques d’abstraction, d’encapsulation, et de faible couplage Abstraction : chaque module doit correspondre à une abstraction préexistante et doit pouvoir être défini de façon abstraite, indépendamment de tout traitement susceptible d’utiliser le module. Encapsulation : masquage de la mise en œuvre effective du module, du “comment c’est fait” . Seules les éléments accessibles de l’extérieurs sont visibles et spécifiés précisément. Faible couplage : limitation des connexions entre modules (dépendances de génération,...). Il est indispensable que les liens entres modules soient bien définis (couches logicielles) et le moins nombreux possible pour qu’il y ait effectivement modularité.

26 Cohésion Définition: degré d’interaction à l’intérieur d’un module dans le but d’accomplir une et une seule fonction. Yourdon et Constantine [79] ont établi une série de degrés de la cohésion classique pour décrire la cohésion des méthodes : Cohésion de coïncidence: Les éléments du module n'ont rien en commun, néanmoins ils sont présents dans le même module. plusieurs fonctionnalités sans rapport non réutilisable Cohésion logique: les éléments accomplissent des tâches similaires comme la gestion des entrées/sorties ou la gestion des fautes. Plusieurs fonctionnalités reliées, sélectionnées par le module qui appelle L'interface est difficile à comprendre Cohésion temporelle: les éléments réalisent des tâches semblables et exécutent leurs tâches dans la même tranche de temps. plusieurs fonctionnalités reliées dans le temps les fonctionnalités sont faiblement reliées entre elles Cohésion procédurale: les éléments d'une méthode sont connectés par le même flux de contrôle. plusieurs fonctionnalités reliées par la procédure du produit

27 Cohésion de communication: les éléments d'une méthode sont connectés par le même flux de contrôle et opèrent sur le même ensemble de données. plusieurs fonctionnalités reliées par la procédure du produit et qui utilisent les mêmes données non réutilisable Cohésion séquentielle: les éléments d'une méthode présentent une cohésion de communication et sont connectés par un flux de contrôle séquentiel. plusieurs fonctionnalités ayant chacune leur point d’entrée et un bloc de code indépendant mais qui utilisent les mêmes données les fonctionnalités sont structurées implantation d’un type abstrait de données Cohésion fonctionnelle: les éléments sont liés par une cohésion séquentielle et contribuent tous à la réalisation d'une tâche particulière. La cohésion fonctionnelle représente la meilleure cohésion, elle vérifie le principe de la localité [YC79] et par conséquent réduit l'effort de la maintenance. une seule fonctionnalité réutilisable

28 Pressman représente les degrés de la cohésion, introduits par Yourdon et Constantine. Sous la forme d'un spectre En orienté objet, les modules désignent les classes. Les éléments de la classe peuvent être à leur tour soit des méthodes soit des classes. Les éléments d'une méthode représentent des instructions, des variables locales ou des variables d’instance accessibles directement ou via des méthodes spéciales. D’après Eder et al. La distinction entre la cohésion d'une méthode et la cohésion d'une classe est fondamentale [EKS95]. La cohésion des éléments définie dans une même classe est traitée séparément de la cohésion calculée pour des éléments hérités et des éléments définis directement dans la classe. La cohésion des classes décrit la liaison des éléments définis à l'intérieur de la classe. Les variables d’instance et les méthodes héritées ne sont pas considérés. Nous tenons à souligner qu’il n’y a pas de définition largement reconnue dans le monde orienté objet, comme c’est le cas dans le paradigme procédural.

29 Un modèle de classification de cohésion est établi en prenant comme modèle la cohésion des types abstraits de données: 1. Séparable : la cohésion d'une classe est classifiée séparable si l'objet représente de multiples abstractions de données n'ayant aucune relation entre elles. C'est le cas d'une classe possédant une méthode qui n'accède à aucune variable d’instance et n'invoque aucune des autres méthodes de la classe. Un autre cas que nous rencontrons quelques fois en analysant du code source est celui des variables d’instance référencées par aucune méthode. Dans ces deux cas de figure, la classe est candidate à la division en une ou plusieurs classes. La cohésion séparable peut être localisée par une analyse syntaxique. 2. Multi-facette : une classe est classifiée multi-facette si ses éléments représentent de multiples abstractions de données liées entre elles et accessibles par au moins une méthode. La cohésion multi-facette est détectée par une analyse sémantique. Effectivement, au moins une méthode accède à une variable d’instance ou invoque une méthode appartenant à un concept sémantique distinct. 3. Non-déléguée : une classe est classifiée non-déléguée si elle n'est pas séparable, n'est pas multi-facette et au moins une méthode utilise une variable d’instance décrivant seulement un composant de la classe. La variable d’instance ne décrit pas l'abstraction de données représentée par la classe mais seulement un de ses composants. 4. Cachée : une cohésion est classifiée cachée si une abstraction de données est cachée dans l'abstraction de données représentées par la classe. Des variables d’instance et des méthodes peuvent être vues comme une nouvelle classe à part entière. Il s'agit dans ce cas d'identifier l'abstraction de données et de définir la nouvelle classe. 5. Modèle : la cohésion modèle est le degré le plus élevé de la cohésion de classe. Elle indique une classe représentant un seul concept sémantique, aucune de ses méthodes ne peut être déléguée à une classe, et elle ne renferme pas de classes cachées. La cohésion prend en compte les éléments nouvellement définis dans la classe. Par contre, la cohésion d'héritage considère toutes les variables d’instance et les méthodes héritées des ancêtres. Elle décrit le degré de liaison entre les éléments définis dans la classe et les éléments hérités. La cohésion d'héritage ne considère pas seulement la super-classe, elle passe à travers tous les ancêtres de la classe selon l'arbre de hiérarchie. Les degrés de la cohésion d'héritage sont identiques aux degrés de la cohésion de classe.

30 Couplage Degré d’interaction entre les modules d’un système
Les sept degrés de couplage tel que rapportés par Pressman [Pre97] sont : 1. Couplage Non direct : deux modules ne sont pas directement reliés. 2. Couplage de Données : les données sont échangées en paramètre seulement. 3. Couplage « Stamp » : un module passe à un autre une portion d’une structure de données. 4. Couplage de Contrôle : un module passe un « flag » à l’autre qui s’en sert à des fins de contrôle d’exécution. 5. Couplage Externe : un module est lié à quelque chose d’extérieur au logiciel. 6. Couplage Commun : plusieurs modules partagent un ensemble des données. 7. Couplage de Contenu : un module modifie des données ou des instructions d’un autre.

31 Pressman montre les degrés de couplage sous forme d’un spectre
En orienté objet les modules se traduisent en méthodes ou en classes. Les méthodes peuvent être couplées par invocation d'une autre méthode ou par le partage des variables avec d’autres méthodes. De la même manière, une classe est couplée à une autre classe s’il y a une relation entre elles. Eder et al.

32 Le couplage au monde orienté objet
On distingue trois types de couplage: couplage d'interaction, couplage de composant et couplage d'héritage. • Couplage d'Interaction : ce type de couplage survient lorsqu’une classe invoque une ou plusieurs méthodes de l'autre. Par analogie aux sept degrés de couplage procédural, Eder et al. Ont établi sept degrés de couplage pour la relation d’interaction. Couplage de Contenu : c'est le pire des couplages. Il signifie qu'une méthode accède directement à l'implantation d'une méthode appartenant à une autre classe. Une telle méthode doit donc parfaitement connaître la structure interne de la méthode qu'elle accède. En effet, tout changement dans une méthode influence l'autre. Le paradigme orienté objet en général, l'encapsulation et la dissimulation d’information (information hiding) en particulier, interdisent l'accès à l'implantation d'une méthode ou aux variables d’instances cachées. Cependant, le couplage de contenu peut survenir lorsqu'un programmeur utilise des particularités de certains langages de programmation qui ne respectent pas la propriété de la dissimulation de l’information. Par exemple, l'option friend en C++ permet d'accéder aux variables d’instance des autres classes. Couplage Commun : il signifie que plusieurs méthodes partagent un même ensemble de données. Le couplage commun est meilleur que le couplage de contenu, dans le sens que toutes les communications implicites sont regroupées dans un endroit commun. Néanmoins, le nombre de communications entre les différentes méthodes est polynomial, et le principe de localité d'une bonne conception orientée objet n'est pas considéré. Couplage Externe : Dans ce type de couplage, les données partagées sont structurées de telle manière à faciliter leurs accès par les différentes méthodes. Cependant, le principe de localité [Pres97] n'est toujours pas respecté, et la plus part des inconvénients du couplage externe sont toujours présents.

33 Couplage de Contrôle : une classe présentant un couplage de contrôle communique avec une méthode d'une autre classe à travers le passage de paramètres. Couplage "Stamp" : deux classes présentent un tel couplage, si deux de leurs méthodes respectives se passent comme paramètre une structure de données entière alors qu'une partie de cette structure aurait suffi. Couplage de Données : deux classes présentent un couplage de données, si elles échangent des données seulement en paramètres. Ce type de couplage est le plus recommandé dans les systèmes orientés objet. Le couplage de données minimise l'effort de maintenance grâce aux restrictions de la propagation des changements. Couplage Non-direct : deux méthodes ne dépendent pas directement l'une de l'autre. Chaque changement dans une des méthodes n'influence aucune autre méthode. • Couplage de Composant : une classe, utilisant comme variable d’instance une autre classe, présente un couplage de composant avec cette dernière. • Couplage d'Héritage : deux classes présentent un couplage d'héritage si une des deux classes est directement ou indirectement une sous-classe de l'autre. L'héritage est un élément important dans le paradigme orienté objet. Il améliore la réutilisation à travers la spécialisation et la généralisation. À première vue, il semble contradictoire de réduire le couplage et de vouloir promouvoir la réutilisation. Néanmoins, l'héritage peut être utilisé pour réduire le couplage par la conception de super-classes regroupant des fonctionnalités communes à plusieurs classes.

34 See you soon…


Télécharger ppt "GL 1 Join Us Start Here EXPRESSION, ANALYSE DES BESOINS et Conception"

Présentations similaires


Annonces Google