Ift 2251 Introduction au Génie Logiciel

Slides:



Advertisements
Présentations similaires
Module Systèmes d’exploitation
Advertisements

Les Systèmes d’Information Financière Atelier conjoint ACBF / Banque Mondiale / AFRITAC de l’Ouest Gérer l’application dans le temps, sur les plans fonctionnel,
Eléments de Génie Logiciel
Processus d'expression du besoin
GEF 435 Principes des systèmes dexploitation Structure des systèmes dexploitation (Tanenbaum 1.7)
LOG4430 : Architecture logicielle et conception avancée
Entre construction théorique et mise en œuvre opérationnelle
1 Les technologies XML Cours 1 : Les Web Services et Architectures Orientées Services Fé vrier Version 1.0 -
Les méthodes formelles en ingénierie des connaissances Damien Lhomme-Desages Jérémie Barlet.
INTRODUCTION.
Tests et Validation du logiciel
Les Ateliers de Génie Logiciel
CSI3525: Concepts des Langages de Programmation Notes # 11: Sous-Programmes ( Lire Chapitre 8 )
Pédagogie par Objectifs
La revue de projet.
MRP, MRP II, ERP : Finalités et particularités de chacun.
MIAGE MASTER 1 Cours de gestion de projet
1- Accueil et introduction Cours MGP Accueil et introduction Gilles Corriveau Maîtrise en Gestion de Projet UQTR Automne 1998.
Etude des Technologies du Web services
LA SEGMENTATION STRATÉGIQUE
Introduction au Génie Logiciel
Démarche de résolution de problèmes
Algorithmique et Programmation
Initiation à la conception de systèmes d'information
L ’approche par processus
DURIBREUX, Michèle & COCQUEBERT & HOURIEZ, Bernard,
Cours #8 Flot de conception d’un circuit numérique
Le Reengineering.
Historique de SystemC Regroupe 4 courants didées: SCENIC Project : Synopsys+UC Irvine Philips System-Level Data Types, VSIA SLD DWG IMEC, Hardware-Software.
Etude globale de système.
Techniques de test Boulanger Jean-Louis.
SCIENCES DE L ’INGENIEUR
Mesures de performance organisationnelle Cours ICO 810 Professeur: Michel Pérusse Hiver 2005 Session 9.
Présentation du mémoire
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Notions de Base Hiver 2002 Petko Valtchev.
Ift 2251 Introduction au Génie Logiciel
RECHERCHE COMMERCIALE
Portée, arrimages et intervenants Évolution des méthodes
Programmation non procédurale Le projet ECOLE 2000
Sensibilisation a la modelisation
Patrons de conceptions de créations
ANALYSE METHODE & OUTILS
Stratégie d’entreprise - Alstom Transport – Marco Férrogalini
INTRODUCTION.
Les principes de la modélisation de systèmes
Le management de l'IVVQ Processus techniques IVVQ
Supports de formation au SQ Unifié
Institut Supérieur des Sciences Appliquées et de Technologie Sousse
LE RAPPORT 1-Sa définition :
2003 (revisé 2008)SEG Chapitre 11 Chapitre 1 “The Systems Engineering Context” Le contexte du génie de systèmes.
Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville«Software Engineering» de Ian Sommerville B.Shishedjiev.
© Petko ValtchevUniversité de Montréal Février IFT 2251 Génie Logiciel Conception Hiver 2002 Petko Valtchev.
Introduction au Génie Logiciel
Initiation à la conception des systèmes d'informations
François CARCENAC,Frédéric BONIOL ONERA-DTIM Zoubir MAMMERI IRIT
Algorithmique : Introduction
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
Management de la qualité
ISNET-43 Atelier de génie logiciel Approche fonctionnelle ou objets Concurrence ou complémentarité ? Synthèse.
L’enseignement de spécialité SLAM
Hiver 2004SEG2501 Chapître 41 Chapître 4 SDL – structure d’un système et son comportement.
Informatique et Sciences du Numérique
© Petko ValtchevUniversité de Montréal Janvier IFT 2251 Génie Logiciel Le Processus Hiver 2002 Petko Valtchev.
Introduction à la Programmation Orientée Objet
Conférence 2TUP Stéphane Barthon 03/12/
INTRODUCTION AUX BASES DE DONNEES
Document de spécification d’exigences Normes IEEE et 29148:2011
Présentation de la méthode Merise
Raison d'être de la structure de fichiers : Les premiers travaux : Début des années 1960 : En 1963 : Près de 10 ans plus tard... (à peu près 1973) : Durant.
PRÉSENTATION AGL LES TESTS LOGICIELS LES TEST LOGICIELS 1 Mickael BETTINELLI Brandon OZIOL Gaétan PHILIPPE Simon LUAIRE.
Transcription de la présentation:

Ift 2251 Introduction au Génie Logiciel Partie 4 Conception Ref. Pressman Ch. 13, 14 et 16 Julie Vachon, DIRO, Université de Montréal, 2001

Définitions, principes, et document de conception 4.1 Introduction: Définitions, principes, stratégies et document de conception

4.1.1 L’activité de conception Définition et objectifs

L’activité de conception Définition Phase du processus de développement qui transforme progressivement la spécification d’analyse du logiciel en un produit final. Comment réaliser le système, quels mécanismes utiliser? Analyse Conception Étape 1 Conception Étape 2 Implémentation Processus progressif Transformation finale en programme exécutable

L’activité de conception La conception est une activité difficile et critique. C’est aussi une activité de création. Elle vise à répondre au «comment»…. Pas de recette toute faite. Ensemble de principes généraux, de méthodes et de stratégies dont l’application pratique dépend du domaine, des contraintes et des qualités recherchées (performance, robustesse, etc.) L’aptitude à réaliser de bonnes conceptions dépend de l’intuition et se développe par la pratique…

L’activité de conception Objectifs But: Transformer progressivement la spécification d’analyse en une description structurée d’un système fiable et évolutif. Pour réaliser ce but principal, il faudra Définir la structure du système par un ensemble de modules: identifier les modules qui composent le système; identifier les relations entre les modules; décrire chacun des modules. Définir les principes à la base de cette décomposition modulaire (abstraction, raffinement, etc.)

L’activité de conception Sous-objectifs La conception logicielle comporte deux sous-activités: Conception architecturale: Activité destinée à définir la structure globale de l’architecture en termes de modules et de relations inter-modules. Conception détaillée: Activité destinée à décrire le détails le contenu des modules individuels (en appliquant, entre autres, le principe de masquage d’information). Ces deux sous-activités sont menées - soit l’une à la suite de l’autre, soit en parallèle (selon les besoins) - en suivant un certains ensemble de principes de conception…

4.1.2 Principes de conception

Principes de conception Règles et éléments fondamentaux du génie logiciel qui doivent guider la phase de conception en vue de construire des systèmes fiables et évolutifs: Abstraction Raffinement Modularité Masquage d’informations Évolutivité et adaptation aux changements Généralité Rigueur et formalisme

Principes de conception Abstraction Principe selon lequel on représente un problème (une donnée, une procédure, une entité, etc.) en éliminant les aspects les moins pertinents pour ne considérer que ceux qui sont essentiels pour servir les buts d’une réflexion spécifique. Permet de maîtriser la complexité d’un problème. Permet de se dégager de certains détails pour se concentrer sur ceux qui sont pertinents. Ex. Les formules mathématiques utilisées pour décrire un circuit électrique. Ex. En Ada, un type de donnée abstrait appelée «client» est utilisé pour représenter les personnes qui sont clientes d’une banque.

Principes de conception Raffinement Processus de conception qui permet d’élaborer une description étape par étape depuis une description très abstraite jusqu’à son implémentation (dans un langage de programmation). A chaque étape, une ou plusieurs parties d’une description sont redéfinies en donnant de plus en plus de détails. Chaque étape de raffinement implique un choix de conception. Il est important de prendre notes des critères ayant influencé ce choix et de garder trace des solutions alternatives. Le raffinement se termine lorsque la description est totalement exprimée dans un langage de programmation. Les principes d’abstraction et de raffinement sont complémentaires. L’abstraction permet d’omettre les détails d’implémentation. Le raffinement permet de révéler ces détails…

Principes de conception Modularité Caractéristique d’un logiciel qui se compose de modules séparés, clairement identifiés, aux interfaces bien définies, pouvant être traités ou modifiés individuellement. La modularité permet de mieux gérer la complexité des systèmes et facilite leur maintenance… Concrètement, la modularité vise trois importants objectifs: Permettre la décomposition d’un système complexe (diviser pour régner, approche descendante) Permettre la composition d’un système à partir de modules déjà existants (assemblage de composants, approche ascendante). Faciliter la compréhension et la maintenance du système en le divisant en parties (possibilité de confiner la recherche d’un problème ou l’application d’une modification à une partie bien comprise du système).

Principes de conception Modularité - cohésion Les modules sont caractérisés par deux propriétés importantes: la cohésion (propriété propre à un module) et le couplage (propriété entre modules). 1) La cohésion. Un module est hautement cohésif si tous ses éléments sont fortement liés. Les éléments d’un module (procédures, déclarations, instructions, etc.) sont groupés ensemble dans le même module pour une raison logique et non par hasard. Ces éléments coopèrent pour atteindre un objectif commun i.e. la fonctionnalité du module.

Principes de conception Modularité - couplage 2) Le couplage. Mesure l’interdépendance de deux modules (ex. un module A appelle une fonction offerte par un module B). Si deux modules dépendent beaucoup l’un de l’autre, ils sont fortement couplés. Si deux modules sont fortement couplés, il sera difficile de les analyser, comprendre, modifier, tester et réutiliser de façon séparée

Principes de conception Modularité On désire concevoir des systèmes fortement cohésifs et faiblement couplés. Système fortement cohésif et faiblement couplé Système fortement couplé Expliquer en quoi le système électrique d’une maison représente un bon système modulaire…

Principe de conception Modularité Diviser pour régner… Effort nécessaire proportionnel à la complexité perçue: C(p1) > C(p2) -> E(p1) > E(p2) Par expérience, il semble que: C(p1 +p2) > C(p1) + C(p2). Donc: E(p1 +p2) > E(p1) + E(p2) Conclusion: il vaut mieux diviser pour régner… mais pas trop!

Principes de conception Modularité Pour une conception donnée, quel est le nombre de modules approprié? Coût de développement d’un module Coût du logiciel Coût d’intégration d’un module Nombre optimal de modules Nombre de modules

Principes de conception Modularité, contrôle hiérarchique et partitionnement Les modules sont généralement organisés en hiérarchies représentant la relation de contrôle entre les modules. - Il sont partitionnés horizontalement et verticalement. - On utilise généralement une notation en arbre pour représenter cette hiérarchie. Partitionnement horizontal: généralement utilisé pour séparer les fonctions du système. Ex. la saisies des entrées, la transformation des données et la sortie des données. Partionnement vertical: généralement utilisé pour factoriser le travail. Les modules aux niveaux supérieurs sont des modules de contrôle, alors que les modules au niveaux inférieurs sont les exécutants.

favorisent la cohésion et minimise le couplage… Principes de conception Modularité, contrôle hiérarchique et partitionnement Il faut rechercher des structures qui favorisent la cohésion et minimise le couplage… STRUCTURE EN FORME DE CIGARE fan-out (éventail de sortie) mesure du nombre de modules qui sont directement contrôlés par un module donné. mesure du nombre de modules qui contrôlent un module donné. fan-in (éventail d’entrée)

Éviter les structures en galette. Principes de conception Modularité, contrôle hiérarchique et partitionnement Éviter les structures en galette. Pourquoi???

Principes de conception Masquage d’information (encapsulation) Principe suggérant que les modules cachent (aux autres modules) les choix de conception qui les caractérisent… - Les informations (données et procédures) d’un module qui ne sont pas utiles aux autres modules devraient être inaccessibles. Les communications entre modules n’impliquent qu’un échange d’informations nécessaires. Le principe d’abstraction permet de définir ces informations essentielles. Facilite la maintenance et les modifications apportées aux modules…. Modifications invisibles aux autres modules…

Principes de conception Masquage d’information module • algorithme interface • structures de données • politique d’allocation de ressources clients "secret" Un choix de conception spécifique

Principes de conception Évolutivité et adaptation aux changements Principe selon lequel les choix de conception sont réalisés en anticipant les modifications qui pourraient être apportées au logiciel et en étant attentif à l’évolution possible ou attendue du logiciel. But: obtenir une conception flexible qui puisse bien s’accommoder des modifications futures…. Bien qu’initialement élégante, une structure mal adaptée aux changements peu devenir fort difficile à maintenir…

Principes de conception Évolutivité et adaptation aux changements Changements éventuels qui peuvent être pris en compte lors de la conception: Changement d’algorithme. Ex. Changement d’algorithme de tri… Changement de structure de données pour représenter une même information. Ex. Remplacement d’une liste par un arbre… Changement de la machine abstraite sous-jacente. Ex. Changement de compilateur, changement de système d’exploitation. 4) Changement d’un périphérique. Changement de l’environnement social. Ex. La formule du calcul des taxes a changé. Ex. Passage à l’euro…

Principes de conception Généralité Lorsqu’on résout un problème, il est important de mettre l’accent sur la recherche d’une solution pour un problème plus général que celui à résoudre et qui se cache sans doute derrière lui. Une solution générale a plus de chance d’être réutilisée. Peut-être existe-elle déjà? Un module général pourra, peut-être, être utilisé à plusieurs niveaux dans l’application. Inconvénient: une solution générale est parfois moins performante qu’une solution spécialisée…

Principes de conception Rigueur et formalisme La rigueur est un complément nécessaire à la créativité dans l’activité de conception logicielle. Formalisme Le summum de la rigueur est le formalisme. Le formalisme est encore plus exigeant que la rigueur puisqu’il demande que le processus de développement soit conduite et évalué par des lois mathématiques. Si on est formel, on est nécessairement rigoureux. Mais si on est rigoureux, on n’est pas nécessairement formel. Ex. On peut décrire un système en langue naturelle de façon rigoureuse. Pour être formel toutefois, on utilisera un langage logique, des modèles mathématiques, etc. Pendant la phase de conception, on pourra utiliser rigueur et formalisme de façon à bénéficier de leurs effets positifs sur la fiabilité, la vérification, la maintenance, la réutilisation, la portabilité et la compréhension des systèmes conçus (… expliquez pourquoi??)

4.1.3 Stratégies de conception

Stratégies de conception ascendante (bottom-up) «Décider de l’information à encapsuler et regrouper graduellement en modules de plus haut niveau.» Stratégie descendante (top-down) «Décomposition en composants gérables.» Conception architecturale Conception des interfaces Conception détaillée des composants (modules et données) On peut employer les deux stratégies au cours d’une même conception…

Stratégies de conception Approche descendante Avantages Processus simple. Permet de maîtriser la complexité de gros systèmes en sous-problèmes. Met en évidence le degré de couplage et permet de le contrôler assez tôt dans le processus de conception. - Offre une définition claire et facile à comprendre: idéale pour documenter une conception. Inconvénients Les sous-problèmes ont tendance à être analysés en isolation. Réutilisation des composants peu exploitée (le partitionnement précoce des problèmes empêche de voir les solutions communes… Moins grande attention portée à la conception des données et au masquage de l’information.

Stratégies de conception Approche ascendante Avantages Favorise le masquage de l’information: encapsulation de l’information dans un module (pour lequel on crée une interface) qui peut à son tour être utilisé par un module de plus haut niveau… Favorise la réutilisation. Inconvénients Pas facile de savoir quelle information il faut précisément encapsuler (une approche descendante est parfois nécessaire…) - La représentation de la conception n’est pas toujours simple et facile à comprendre…

Quelques méthodes de conception Avant l’intra… Années 70-75: développement modulaire, approche par raffinement, programmation structurée. [Dennis, Wirth, Dahl, Diskstra, Hoare, Mills, etc.] Années 75-80: processus de transformation des DFD et des modèles de données dans une définition de conception. [Stevens,Jackson, Warnier, etc.] Après l’intra… Années 90-95: Approches orientées-objet pour dériver les conceptions. [Jacobson et als] Années 95-2000: Utilisation de pattern de conception pour implémenter les architectures logicielles. [Shaw, Bass, Gamma, Buschmann, Brown, etc.]

Document de conception (ou spécification de conception) Le document doit comprendre les éléments suivants: Sommaire du travail de conception: objectifs à atteindre en regard de la spécification d’analyse. Description de la conception des bases de données: structure, système de fichiers, structure des données. Description de la conception architecturale: explication de la façon dont la structure générale du système a été dérivée depuis la spécification d’analyse. Description de la conception des interfaces usagers. Prototype peut être fourni. Description détaillée des composants: description des fonctions et procédures. Description en langue naturelle et/ou en intégrant une notation structurée. Annexe: description d’algorithmes, procédures alternatives, notices, etc.