SlideShare une entreprise Scribd logo
1  sur  33
Télécharger pour lire hors ligne
Génie Logiciel
CONCEPTION
Position dans le cycle de vie
 Contexte :
 étant donnée une spécification
(ce que doit faire le produit)
 Phase de conception :
 architecture du produit
(comment il est structuré pour faire ce qu'il doit faire)
→ document de conception globale / détaillée
(si cycle de vie en V : + plan d'intégration)
 Phase suivante : codage
Cycle de vie :modèle en V (rappel)
Deux niveaux de détail
 Conception globale (ou préliminaire)
 choix fondamentaux d'architecture logicielle
 en lien éventuel avec l'architecture matérielle
 Conception détaillée
 description précise de chaque module
 algorithmes mis en œuvre
 traitements effectués en cas d'erreur
Conception détaillée
 Souvent escamotée
 petite taille des modules
→ description précise des algorithmes pas nécessaire
☛ Pas traitée dans ce cours
Objectifs de la conception
 Séparation les problèmes
 permet d'appréhender un problème complexe
 Décomposition modulaire du logiciel
 permet le développement en parallèle (test y compris)
 facilite la maintenance (corrective ou évolutive)
 documentation et isolation des comportements
 localisation des modifications
 facilite la réutilisation
Importance de la conception
 Influence considérable sur la réalisation du logiciel
 en particulier sur la qualité
 Réponse au besoin spécifique du client
@@Erreur dans la conception (mauvaise architecture)
→ Impacts sur le budget et le temps de réalisation
→ surcoûts récurrents pour palier les défauts
Facteurs de qualité
de la conception / architecture
 Robustesse
 aptitude à fonctionner dans des conditions anormales
 Extensibilité
 aptitude à s'adapter aux changements de spécification
 Réutilisabilité
 aptitude à resservir dans de nouvelles applications
 Compatibilité
 aptitude à être combinée avec d'autres logiciels
 Efficacité
 bonne utilisation des ressources
 Portabilité
 facilité d'adaptation à différents environnements
 Vérifiabilité
 facilité à être vérifiée
Facteurs de qualité
de la conception / architecture
 Sécurité
 Intégrité : aptitude à protéger ses composants (y compris ses données) contre
des modifications non autorisées
 Confidentialité : aptitude à masquer des informations privées (à des agents non
autorisés)
 Correction
 degré de conformité par rapport aux spécifications.
 …
Quelques chiffres
 Bonne conception → facilité de maintenance
 Une analyse des coûts de maintenance fait ressortir les chiffres suivants :
 42% dans les exigences des utilisateurs
 18% modification du format des données
 13% correction d'erreurs en urgence
 9% correction d'erreurs de routine
 6% modification de matériel
 5% documentation
 4% amélioration de l'efficacité
 3% autres
Facilité de maintenance
 Coût de maintenance principal = modification de spécification et format
de données(60%)
→ Pouvoir effectuer les modifications de manière aussi simple que possible
→ Permettre et exploiter la traçabilité des spécifications
☛ Un outil méthodologique : la modularité
Plusieurs notions de module
 Module logique
 élément du découpage logique de la solution du problème
 Module de compilation/chargement
 bloc de code pouvant être compilé/chargé séparément
 ex. : fichier C (types, variables, fonctions), classe Java
(champs, méthodes), script shell (variables, fonctions)
 Module du langage de programmation
 bloc de code nommé pouvant être utilisé (appelé, ...)
 ex. : fonction, classe, fichier d'inclusion C (.h), ...
Critères de modularité
(comment analyser la modularité)
 Décomposabilité modulaire
 Composabilité modulaire
 Compréhensibilité modulaire
 Continuité modulaire
 Protection modulaire
☛Pas toujours facile à satisfaire( contre exemple)
→ être pragmatique, faire au mieux
Décomposabilité modulaire
(critère de modularité)
 Définition
 Le module découpe un problème complexe en problèmes plus petits, solubles
isolément
(décomposition souvent récursive)
 Exemple
 modules issus d'une conception descendante
 Contre-exemple
 module d'initialisation globale
Composabilité modulaire
(critère de modularité)
 Définition
 Les modules peuvent facilement être utilisés et combinés, éventuellement dans
des contextes différents de ceux pour lesquels ils ont été initialement
développés
 Exemple
 bibliothèque de sous-programmes
Protection modulaire
(critère de modularité)
 Définition
 Si une condition anormale se produit pendant l'exécution du module, elle reste
localisée au module (ou à quelques modules voisins)
 Exemple
 validation des données d'entrées au plus tôt
 Contre-exemple
 exceptions inter-modules (lieu de traitement d'erreur séparé du lieu de
production de l'erreur)
Principes de modularité
(règles à respecter)
 Contrôle des tailles
 Découpage logique
 Minimisation des interfaces
 Simplification des interfaces
 Interfaces explicites
 Masquage de l’information
☛ Pas toujours facile à satisfaire (∃ contre-exemples)
→ être pragmatique
Simplification des interfaces
(principe de modularité à respecter)
 Principe
 Les modules doivent échanger aussi peu de données que possible
 Exemples
 faible nombre d'arguments des fonctions/méthodes
 transmission de pointeurs restreinte
 Contre-exemple
 variables globales
 Critères
 continuité, protection
Masquage de l'information
(principe de modularité à respecter)
 Principe
 Toute information d'un module est privée, sauf son interface explicite
 Exemples
 en C : n'est visible à l'extérieur d'un fichier que ce qui est déclaré « extern »
(variables, fonctions)
 Critères
 continuité (le contenu d'un module peut changer sans que les autres modules
doivent être modifiés)
Méthodes de conception
orientée objet
 Méthode de Booch (1986) :
 définir le problème
 développer une stratégie informelle de résolution
 identifier les objets et leurs attributs
 identifier les opérations sur ces objets
 établir les interfaces pour ces opérations
 implémenter les objets
 éventuellement répéter le processus récursivement
Remarques sur la phase de
conception
 Analyse des besoins et conception sont étroitement mêlées
 point de départ : formulation du problème
 élaboration/formulation d'une solution
 structuration logicielle de cette solution
 C'est le cas également avec UML (→)
UML
 Langage de modélisation
 UML = Unified Modeling Language
 notations normalisées
 Pour la résolution de problèmes orientée objet
 Mais c'est une notation, pas une méthode !
Modèle
 Modèle = abstraction du problème sous-jacent
 objets qui interagissent par envoi de messages
 attributs des objets (valeurs → état de l'objet)
 opérations/comportements des objets
 objets de mêmes type = instances d'une classe
(Principaux) diagrammes UML
 diagrammes d'objets
 diagrammes de classes
 diagrammes de cas d'utilisation
 diagrammes de composants
 diagrammes de déploiement
 diagrammes de séquence
 diagrammes de collaboration
 diagrammes d'états-transitions
 diagrammes d'activités
Diagramme de cas d'utilisation
Diagramme de cas d'utilisation
Diagramme de cas d'utilisation
 Expression de besoins/exigences [angl. requirements]
 nouveau cas d'utilisation → nouvelles exigences
 Communication aisée avec le client
 simplicité de notation
 Génération de tests
 ensemble de scénarios → ensemble de cas de test
Diagramme de classe
 Aperçu du système
 classes et relations entre elles
 Vue statique
 existence d'interactions mais pas d'information sur le comportement effectif
Diagramme de classe
 commande client pour une vente au détail
Diagramme de package
 Package = collection d'éléments reliés logiquement
UML et cycle de vie
 Définition des besoins :
 diagramme de cas d'utilisation
 Analyse des besoins
 diagrammes d'état, d'activité
 Conception
 diagrammes d'état, d'activité
 diagrammes de classe, d'objet, de package
 diagrammes de séquence, de collaboration
 diagrammes de déploiement
À retenir
 Conception
 séparation des problèmes / décomposition modulaire
 Méthodologie
 globalement descendante, parfois montante.
 Principes de modularité à respecter
 découpage logique ; taille équilibrée ; masquage de l'information ; interface
minimale, simple et explicite
 Organiser le système autour des données (!)
 Notion de type abstrait
 UML : notations normalisées, vues différentes
Fin
MERCI

Contenu connexe

Tendances

2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciellauraty3204
 
9-Cours de Géniel Logiciel
9-Cours de Géniel Logiciel9-Cours de Géniel Logiciel
9-Cours de Géniel Logiciellauraty3204
 
Test de logiciels
Test de logiciels Test de logiciels
Test de logiciels Bilel Abed
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
DefinitiondesbesoinsumlVINOT Bernard
 
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriMansouri Khalifa
 
Design patterns - Exemples en Java
Design patterns - Exemples en JavaDesign patterns - Exemples en Java
Design patterns - Exemples en JavaOussama BEN KHIROUN
 
Modeliser une application_web
Modeliser une application_webModeliser une application_web
Modeliser une application_webMoez Moezm
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriMansouri Khalifa
 
Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23
Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23
Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23megaplanet20
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...Cyrille Grandval
 
Design Patterns Java
Design Patterns JavaDesign Patterns Java
Design Patterns JavaVINOT Bernard
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes PratiquesEmmanuel Hugonnet
 
Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisationNassim Amine
 

Tendances (19)

2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel2-Cours de Géniel Logiciel
2-Cours de Géniel Logiciel
 
9-Cours de Géniel Logiciel
9-Cours de Géniel Logiciel9-Cours de Géniel Logiciel
9-Cours de Géniel Logiciel
 
Uml Cas Utilisation introduction
Uml Cas Utilisation introductionUml Cas Utilisation introduction
Uml Cas Utilisation introduction
 
Test de logiciels
Test de logiciels Test de logiciels
Test de logiciels
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
Definitiondesbesoinsuml
 
Manuel uml-poweramc
Manuel uml-poweramcManuel uml-poweramc
Manuel uml-poweramc
 
Uml & cas d'utilisation
Uml & cas d'utilisationUml & cas d'utilisation
Uml & cas d'utilisation
 
Uml
UmlUml
Uml
 
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouri
 
Design patterns - Exemples en Java
Design patterns - Exemples en JavaDesign patterns - Exemples en Java
Design patterns - Exemples en Java
 
Modeliser une application_web
Modeliser une application_webModeliser une application_web
Modeliser une application_web
 
UML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouriUML Part 4- diagrammres de classes et d'objets mansouri
UML Part 4- diagrammres de classes et d'objets mansouri
 
Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23
Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23
Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
 
7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation
 
Design Patterns Java
Design Patterns JavaDesign Patterns Java
Design Patterns Java
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
 
Uml 2 pratique de la modélisation
Uml 2  pratique de la modélisationUml 2  pratique de la modélisation
Uml 2 pratique de la modélisation
 
040401+seminar+gelo+diro.ppt
040401+seminar+gelo+diro.ppt040401+seminar+gelo+diro.ppt
040401+seminar+gelo+diro.ppt
 

Similaire à 10-Cours de Géniel Logiciel

Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]linasafaa
 
MVVM de A à Z
MVVM de A à ZMVVM de A à Z
MVVM de A à ZMicrosoft
 
Introduction au Domain Driven Design
Introduction au Domain Driven DesignIntroduction au Domain Driven Design
Introduction au Domain Driven DesignDNG Consulting
 
Architectures n-tiers
Architectures n-tiersArchitectures n-tiers
Architectures n-tiersHeithem Abbes
 
Design applicatif avec symfony2
Design applicatif avec symfony2Design applicatif avec symfony2
Design applicatif avec symfony2RomainKuzniak
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011agnes_crepet
 
Marzouk architecture encouches-jee-mvc
Marzouk architecture encouches-jee-mvcMarzouk architecture encouches-jee-mvc
Marzouk architecture encouches-jee-mvcabderrahim marzouk
 
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4Emmanuel Hugonnet
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flexdavid deraedt
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flexdavid deraedt
 
Sql azure performance et montee en charge (1)
Sql azure   performance et montee en charge (1)Sql azure   performance et montee en charge (1)
Sql azure performance et montee en charge (1)Aymeric Weinbach
 
Projet security et datawarehouse
Projet security et datawarehouseProjet security et datawarehouse
Projet security et datawarehouseomri med
 
Les vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdfLes vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdfBabacarDIOP48
 
7. information modelling
7. information modelling7. information modelling
7. information modellingsugogo
 
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db firstZineb ELGARRAI
 
Cours design pattern m youssfi partie 1 introduction et pattern strategy
Cours design pattern m youssfi partie 1 introduction et pattern strategyCours design pattern m youssfi partie 1 introduction et pattern strategy
Cours design pattern m youssfi partie 1 introduction et pattern strategyENSET, Université Hassan II Casablanca
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logiciellecyrilgandon
 

Similaire à 10-Cours de Géniel Logiciel (20)

Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]
 
MVVM de A à Z
MVVM de A à ZMVVM de A à Z
MVVM de A à Z
 
Introduction au Domain Driven Design
Introduction au Domain Driven DesignIntroduction au Domain Driven Design
Introduction au Domain Driven Design
 
Architectures n-tiers
Architectures n-tiersArchitectures n-tiers
Architectures n-tiers
 
Design applicatif avec symfony2
Design applicatif avec symfony2Design applicatif avec symfony2
Design applicatif avec symfony2
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011
 
Marzouk architecture encouches-jee-mvc
Marzouk architecture encouches-jee-mvcMarzouk architecture encouches-jee-mvc
Marzouk architecture encouches-jee-mvc
 
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4Industrialisation Du Logiciel   Introduction Et Bonnes Pratiques   V1.4
Industrialisation Du Logiciel Introduction Et Bonnes Pratiques V1.4
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flex
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flex
 
Sql azure performance et montee en charge (1)
Sql azure   performance et montee en charge (1)Sql azure   performance et montee en charge (1)
Sql azure performance et montee en charge (1)
 
Projet security et datawarehouse
Projet security et datawarehouseProjet security et datawarehouse
Projet security et datawarehouse
 
Les vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdfLes vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdf
 
7. information modelling
7. information modelling7. information modelling
7. information modelling
 
Entity_framework_db first
Entity_framework_db firstEntity_framework_db first
Entity_framework_db first
 
Cours design pattern m youssfi partie 1 introduction et pattern strategy
Cours design pattern m youssfi partie 1 introduction et pattern strategyCours design pattern m youssfi partie 1 introduction et pattern strategy
Cours design pattern m youssfi partie 1 introduction et pattern strategy
 
Cours spring
Cours springCours spring
Cours spring
 
Single Page Application
Single Page ApplicationSingle Page Application
Single Page Application
 
Qualité logicielle
Qualité logicielleQualité logicielle
Qualité logicielle
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
 

10-Cours de Géniel Logiciel

  • 2. Position dans le cycle de vie  Contexte :  étant donnée une spécification (ce que doit faire le produit)  Phase de conception :  architecture du produit (comment il est structuré pour faire ce qu'il doit faire) → document de conception globale / détaillée (si cycle de vie en V : + plan d'intégration)  Phase suivante : codage
  • 3. Cycle de vie :modèle en V (rappel)
  • 4. Deux niveaux de détail  Conception globale (ou préliminaire)  choix fondamentaux d'architecture logicielle  en lien éventuel avec l'architecture matérielle  Conception détaillée  description précise de chaque module  algorithmes mis en œuvre  traitements effectués en cas d'erreur
  • 5. Conception détaillée  Souvent escamotée  petite taille des modules → description précise des algorithmes pas nécessaire ☛ Pas traitée dans ce cours
  • 6. Objectifs de la conception  Séparation les problèmes  permet d'appréhender un problème complexe  Décomposition modulaire du logiciel  permet le développement en parallèle (test y compris)  facilite la maintenance (corrective ou évolutive)  documentation et isolation des comportements  localisation des modifications  facilite la réutilisation
  • 7. Importance de la conception  Influence considérable sur la réalisation du logiciel  en particulier sur la qualité  Réponse au besoin spécifique du client @@Erreur dans la conception (mauvaise architecture) → Impacts sur le budget et le temps de réalisation → surcoûts récurrents pour palier les défauts
  • 8. Facteurs de qualité de la conception / architecture  Robustesse  aptitude à fonctionner dans des conditions anormales  Extensibilité  aptitude à s'adapter aux changements de spécification  Réutilisabilité  aptitude à resservir dans de nouvelles applications  Compatibilité  aptitude à être combinée avec d'autres logiciels  Efficacité  bonne utilisation des ressources  Portabilité  facilité d'adaptation à différents environnements  Vérifiabilité  facilité à être vérifiée
  • 9. Facteurs de qualité de la conception / architecture  Sécurité  Intégrité : aptitude à protéger ses composants (y compris ses données) contre des modifications non autorisées  Confidentialité : aptitude à masquer des informations privées (à des agents non autorisés)  Correction  degré de conformité par rapport aux spécifications.  …
  • 10. Quelques chiffres  Bonne conception → facilité de maintenance  Une analyse des coûts de maintenance fait ressortir les chiffres suivants :  42% dans les exigences des utilisateurs  18% modification du format des données  13% correction d'erreurs en urgence  9% correction d'erreurs de routine  6% modification de matériel  5% documentation  4% amélioration de l'efficacité  3% autres
  • 11. Facilité de maintenance  Coût de maintenance principal = modification de spécification et format de données(60%) → Pouvoir effectuer les modifications de manière aussi simple que possible → Permettre et exploiter la traçabilité des spécifications ☛ Un outil méthodologique : la modularité
  • 12. Plusieurs notions de module  Module logique  élément du découpage logique de la solution du problème  Module de compilation/chargement  bloc de code pouvant être compilé/chargé séparément  ex. : fichier C (types, variables, fonctions), classe Java (champs, méthodes), script shell (variables, fonctions)  Module du langage de programmation  bloc de code nommé pouvant être utilisé (appelé, ...)  ex. : fonction, classe, fichier d'inclusion C (.h), ...
  • 13. Critères de modularité (comment analyser la modularité)  Décomposabilité modulaire  Composabilité modulaire  Compréhensibilité modulaire  Continuité modulaire  Protection modulaire ☛Pas toujours facile à satisfaire( contre exemple) → être pragmatique, faire au mieux
  • 14. Décomposabilité modulaire (critère de modularité)  Définition  Le module découpe un problème complexe en problèmes plus petits, solubles isolément (décomposition souvent récursive)  Exemple  modules issus d'une conception descendante  Contre-exemple  module d'initialisation globale
  • 15. Composabilité modulaire (critère de modularité)  Définition  Les modules peuvent facilement être utilisés et combinés, éventuellement dans des contextes différents de ceux pour lesquels ils ont été initialement développés  Exemple  bibliothèque de sous-programmes
  • 16. Protection modulaire (critère de modularité)  Définition  Si une condition anormale se produit pendant l'exécution du module, elle reste localisée au module (ou à quelques modules voisins)  Exemple  validation des données d'entrées au plus tôt  Contre-exemple  exceptions inter-modules (lieu de traitement d'erreur séparé du lieu de production de l'erreur)
  • 17. Principes de modularité (règles à respecter)  Contrôle des tailles  Découpage logique  Minimisation des interfaces  Simplification des interfaces  Interfaces explicites  Masquage de l’information ☛ Pas toujours facile à satisfaire (∃ contre-exemples) → être pragmatique
  • 18. Simplification des interfaces (principe de modularité à respecter)  Principe  Les modules doivent échanger aussi peu de données que possible  Exemples  faible nombre d'arguments des fonctions/méthodes  transmission de pointeurs restreinte  Contre-exemple  variables globales  Critères  continuité, protection
  • 19. Masquage de l'information (principe de modularité à respecter)  Principe  Toute information d'un module est privée, sauf son interface explicite  Exemples  en C : n'est visible à l'extérieur d'un fichier que ce qui est déclaré « extern » (variables, fonctions)  Critères  continuité (le contenu d'un module peut changer sans que les autres modules doivent être modifiés)
  • 20. Méthodes de conception orientée objet  Méthode de Booch (1986) :  définir le problème  développer une stratégie informelle de résolution  identifier les objets et leurs attributs  identifier les opérations sur ces objets  établir les interfaces pour ces opérations  implémenter les objets  éventuellement répéter le processus récursivement
  • 21. Remarques sur la phase de conception  Analyse des besoins et conception sont étroitement mêlées  point de départ : formulation du problème  élaboration/formulation d'une solution  structuration logicielle de cette solution  C'est le cas également avec UML (→)
  • 22. UML  Langage de modélisation  UML = Unified Modeling Language  notations normalisées  Pour la résolution de problèmes orientée objet  Mais c'est une notation, pas une méthode !
  • 23. Modèle  Modèle = abstraction du problème sous-jacent  objets qui interagissent par envoi de messages  attributs des objets (valeurs → état de l'objet)  opérations/comportements des objets  objets de mêmes type = instances d'une classe
  • 24. (Principaux) diagrammes UML  diagrammes d'objets  diagrammes de classes  diagrammes de cas d'utilisation  diagrammes de composants  diagrammes de déploiement  diagrammes de séquence  diagrammes de collaboration  diagrammes d'états-transitions  diagrammes d'activités
  • 25. Diagramme de cas d'utilisation
  • 26. Diagramme de cas d'utilisation
  • 27. Diagramme de cas d'utilisation  Expression de besoins/exigences [angl. requirements]  nouveau cas d'utilisation → nouvelles exigences  Communication aisée avec le client  simplicité de notation  Génération de tests  ensemble de scénarios → ensemble de cas de test
  • 28. Diagramme de classe  Aperçu du système  classes et relations entre elles  Vue statique  existence d'interactions mais pas d'information sur le comportement effectif
  • 29. Diagramme de classe  commande client pour une vente au détail
  • 30. Diagramme de package  Package = collection d'éléments reliés logiquement
  • 31. UML et cycle de vie  Définition des besoins :  diagramme de cas d'utilisation  Analyse des besoins  diagrammes d'état, d'activité  Conception  diagrammes d'état, d'activité  diagrammes de classe, d'objet, de package  diagrammes de séquence, de collaboration  diagrammes de déploiement
  • 32. À retenir  Conception  séparation des problèmes / décomposition modulaire  Méthodologie  globalement descendante, parfois montante.  Principes de modularité à respecter  découpage logique ; taille équilibrée ; masquage de l'information ; interface minimale, simple et explicite  Organiser le système autour des données (!)  Notion de type abstrait  UML : notations normalisées, vues différentes

Notes de l'éditeur

  1. La phase de conception de logiciel met en œuvre un ensemble d'activités qui à partir d'une demande d'informatisation d'un processus permettent la conception, l'écriture et la mise au point d'un logiciel jusqu'à sa livraison au demandeur.
  2. Architecture Logiciel: décrit d’une manière symbolique et schématique les différents éléments d’un ou de plusieurs systèmes informatiques, leurs interrelations et leurs interactions. le modèle d'architecture, produit lors de la phase de conception, ne décrit pas ce que doit réaliser un système informatique mais plutôt comment il doit être conçu de manière à répondre aux spécifications. Précise: la base de données, librairies, interfaces, etc. ? Sur quel matériel chacun des composants sera installé ?
  3. L’analyse décrit le « quoi faire » alors que l’architecture décrit le « comment le faire » Architecte logiciel: rigueur, logique, bon sens, un esprit de synthese,… On apprend pas à devenir architecte logiciel, c’est le resultats des experiences aquises dans le dom de dev log ` ` ` ` ```` ` `
  4. Les facteurs de qualité peuvent etre considérés comme un ensemble d’activités à mettre en oeuvre dans les phases de réalisation du logiciel permettant d’assurer la qualité du logiciel.
  5. La facilité de maintenance du produit dépendra de sa conception globale.
  6. Un module peut être vu comme un bloc de code pouvant être appelé. Cette définition permet de considérer une procédure ou fonction; Yourdon élargit la définition d'un module en 1979 : "toute portion de code entre deux éléments servant d'encadrement (begin ...end, (), {}, ...) et pouvant être nommé."
  7. La continuité modulaire est assurée si des petites modifications de spécifications n'amènent pas à revoir l'ensemble de l'architecture. Les modifications ne doivent affecter que quelques modules. Ce critère est lié à l'extensibilité.
  8. Bottom-up; …
  9. Minimisation des interfaces : Tout module doit communiquer avec aussi peu d'autres que possible. Si un système est composé de n modules, le nombre d'interconnexions doit être plus près du minimum (n-1 ) que du maximum (n * n-1/2). Ce principe permet de vérifier les règles de protection et de continuité. Simplification des interfaces : Les modules qui communiquent doivent échanger aussi peu de données que possible. Ceci permet d'assurer les critères de continuité et de protection. Interfaces explicites : lorsque deux modules communiquent, ceci doit se voir clairement dans le texte de l'un et/ou de l'autre. Ceci permet de satisfaire les critères de composabilité et décomposabilité. Masquage de l'information : toute information d'un module est privée sauf l'interface. Ceci afin de vérifier le critère de continuité : le contenu d'un module (calculs...) peut changer sans que ses appels soient changés.
  10. Langage de modelisation de 3eme Generation, normalisé par l’OMG(Object Management Group) au début des années 1997 permettant de decrier une application en function des methods objets avec lesquelles elle a été construite. Au depart 12 types de diagrammes standard ont ete defines. Langage unifié: OCL, Booch, OOSE, OMT…
  11. Modèle: une représentation simplifiée d'un problème. le modèle: Grâce au modèle il est possible de représenter simplement un problème, un concept et le simuler. La modélisation comporte deux composantes : 1-L'analyse, c'est-à-dire l'étude du problème 2-la conception, soit la mise au point d'une solution au problème