Embed Size (px)
Citation preview
D J A M E L D O U H A
D . D O U H A @ U N I V - B A T N A 2 . D Z
Résumé : Modélisation Analyse et conception
Abstraction (rappel)
09/12/2019 DOUHA
2
L’abstraction est le processus qui consiste à représenter des objets qui appartiennent au monde réel dans le monde du programme que l’on écrit. Il consiste essentiellement à extraire des variables pertinentes, attachées aux objets que l’on souhaite manipuler, et à les placer dans un modèle informatique convenable.
On appelle la phase d'analyse "l'analyse métier", est les abstractions qui en découlent le "domaine métier". Lorsque l'on écrit un logiciel qui fait des choses (ce n'est pas toujours le cas...), on définit toujours le "domaine métier", et les objets de ce domaine.
Principes de la Modélisation
09/12/2019 DOUHA
3
Objectif principal de la modélisation est de maîtriser la complexité.
Modéliser: abstraire la réalité pour mieux comprendre le système à réaliser / réalisé.
Le modèle doit être relié au monde réel
Par exemple : l’existant avant les travaux, le réalisé, le restant à réaliser.
Un modèle peut être exprimé avec différents niveaux d’abstraction / raffinement
Par analogie : répartition électrique de l’immeuble, de la cage d’escalier, de l’appartement, de la pièce.
Principes de la Modélisation
09/12/2019 DOUHA
4
Une seule « vue » du système n’est pas suffisante : Les intervenants multiples du projet informatique possèdent des préoccupations multiples
Par analogie :un architecte qui dessine plusieurs plans pour concevoir une maison; plan de masse, vues de face et de côté, schéma électrique, plan de plomberie, plan de calculs de construction.
La conception d’un système informatique est organisée dans une architecture de modélisation qui prévoit plusieurs visions du même problème pour aider à trouver une solution acceptable.
La cohérence entre les différentes vues du système est importante, chaque vue ciblant des catégories différentes d’intervenants ayant des besoins différents.
Modélisation Orientée Objet
09/12/2019 DOUHA
5
Relier le modèle au monde réel par la notion d’objet
Orienté objet = abstraire et décomposer le système informatique en objets
Le monde réel est constitué d’objets physiques ou immatériels.
Relier les objets virtuels de modélisation(solution) depuis les objets du monde réel (problématique)
Favoriser les abstractions naturelles du monde réel utilisables en modélisation .
Objets vus comme des « boîtes noires » : seules les propriétés visibles de l’extérieur intéressent
Objets possédant un nom, qualifiables, classables, polymorphes, dé-/composables, interagissant avec d’autres objets, etc.
UML et approche OO
09/12/2019 DOUHA
6
UML ne préconise aucune démarche.
La définition d’un logiciel peut être scindée en deux étapes majeures : l’analyse (analyse des besoins, du domaine et de la solution applicative) et la conception.
Une démarche itérative permet de garantir que l’analyse soit cohérente et complète.
Objectifs supplémentaire lors de la modélisation orientée objet
Meilleure indépendance du modèle par rapport aux fonctions demandées
Meilleure capacité d’adaptation et d’évolution du modèle lorsque des fonctionnalités sont modifiées ou ajoutées
Modélisation vs Conception
09/12/2019 DOUHA
7
Quelle est la différence entre la modélisation et la conception ?
La modélisation et la conception sont deux termes différents mais souvent associés en informatique.
Modéliser (modélisation) c'est formaliser la solution, dans un ensemble de notations et de règles connues.
Concevoir (conception) c'est imaginer (construire) une solution pour un projet.
Modélisation vs Conception(suite)
09/12/2019 DOUHA
8
Quelle est la différence entre la modélisation et la conception ?
Lors de la modélisation, nous utilisons un langage de modélisation comme UML pour créer un modèle (méta modèle). Une fois la solution ou l’idée est figée sous forme d’un modèle, nous passons à la conception. C’est-à-dire selon le modèle réalisé (les diagrammes UC, CL, SE… réalisés), nous choisissons les technologies les plus adapter et nous les mettons en œuvre.
Donc, la modélisation est une façon de concevoir un produit (ex : une pièce auto) sur ordinateur et cela nous permet d'économiser de la matière première.
Modélisation vs Conception(suite)
09/12/2019 DOUHA
9
Les méthodes de conception proposent des modélisations et une démarche de mise en œuvre.
La modélisation est le support de la conception. Cependant, nous pouvons modéliser un système sans le concevoir, ce qui veut dire nous le représentons. Nous pouvons également concevoir sans modélisation et cela reste dans la tête ou reste incommunicable.
Nous finissons par les paroles dans l’art poétique de Nicolas Boileau (1636-1711):
Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément.
Approche Fonctionnelle vs objet
09/12/2019 DOUHA
10
Approche fonctionnelle ou structurelle :
l'architecture du système est dictée par la réponse au problème (i.e. la fonction du système).
Approche Objet :
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures logicielles fondées sur les objets du système, plutôt que sur la fonction qu'il est censé réaliser. C’est-à-dire l'architecture du système est dictée par la structure du problème.
Analyse Conception OO
09/12/2019 DOUHA
11
Rôle de l’expression des besoins
09/12/2019 DOUHA
12
Permettre une meilleure compréhension du système
Comprendre et structurer les besoins du client
Clarifier, filtrer et organiser les besoins, ne pas chercher l’exhaustivité
Une fois identifiés et structurés, ces besoins :
Définissent le contour du système à modéliser,
Précisent le but à atteindre,
Permettent d’identifier les fonctionnalités principales du système (UCs)
Rôle de l’analyse
09/12/2019 DOUHA
13
Le but de l’analyse est de traduire dans un langage qui se rapproche doucement de celui des informaticiens les modèles exprimés dans l’expression des besoins.
Cependant, pour rester compréhensible par les clients ou utilisateurs, elle ne prend en considération que des entités du domaine (métier)
Elle sert d’interface, avec l’expression des besoins, aux dialogues avec les clients et les utilisateurs
L’analyse doit servir de support pour la conception, l’implémentation et la maintenance.
Rôle de l’analyse (suite)
09/12/2019 DOUHA
14
Le modèle de l’analyse décrit le problème (ce que doit faire le système et comment il le fait tel que vu d’un point de vue métier) sans spécifier la solution technique (avec les canevas logiciels)
Analyse = LE-QUOI
Rôle de la conception
09/12/2019 DOUHA
15
Le but de la conception est de fixer les choix techniques et de préparer l’implantation
Le modèle de la conception décrit la solution (comment le problème est résolu).
Conception = LE-COMMENT
La conception doit servir de support pour l’implémentation et la maintenance.
Le plus souvent, le modèle de la conception n’est pas destiné à être compréhensible par les utilisateurs mais par les développeurs.
09/12/2019 DOUHA
16
Pour définir les besoins (contexte et système)
contexte: Pour identifier les acteurs qui utiliseront le système.
l’environnement direct du logiciel
décrire QUI devra utiliser le logiciel
cas d’utilisation: Pour indiquer de quelles façons les acteurs utiliseront le système.
en précisant QUI devra pouvoir faire QUOI grâce à cette partie du logiciel.
dans la partie «Accueil», le rédacteur peut écrire du texte, changer la police et la couleur du texte, aligner le texte, etc.
Dans la partie « Révision », le vérificateur peut insérer des commentaires, indiquer des modifications, etc.
Etape Analyse Quand ? QUEL DIAGRAMME? Et POURQUOI?
09/12/2019 DOUHA
17
Analyse de domaine
cas d’utilisation : Pour détailler les fonctionnalités en y ajoutant des liens entre cas d’utilisation (réorganisation: relation : include, extend, heritage et package).
la décomposition en packages. La décomposition peut se faire en réfléchissant à des « familles » de fonctionnalités qui seraient nécessaires.
Quelles sont les grandes parties qui doivent composer le logiciel
Pour une partie précise, qui, parmi les acteurs identifiés (ou utilisateurs) l’utilisera ?
La partie « Accueil » sera utilisé aussi bien par un rédacteur.
La partie « Mise en page », en revanche, sera probablement seulement utilisé par un rédacteur.
La partie « révision» sera utilisé par un vérificateur ou validateur.
Etape Analyse Quand ? QUEL DIAGRAMME? Et POURQUOI?
09/12/2019 DOUHA
18
Analyse de domaine (suite)
d’activité :Afin de décrire le déroulement des cas d’utilisation.
Diagramme d'activités utile pour la représentation des processus métiers et des cas d'utilisation.
classes : Pour préciser les informations nécessaires pour les actions d’un cas d’utilisation.
On modélise les concepts statiques du métier du client (les classes et les interfaces du système) et leurs relations statiques.
Une classe décrit les responsabilités, le comportement et le type d’un ensemble d’objets.
Etape Analyse Quand ? QUEL DIAGRAMME? Et POURQUOI?
Etape Analyse Quand ? QUEL DIAGRAMME? Et POURQUOI?
09/12/2019 DOUHA
19
Analyse applicative (ou analyse de la solution)
Diagramme de séquences : Afin de détailler le déroulement d’un cas d’utilisation tout en indiquant les informations à utiliser.
Diagramme d’état-transition : Afin d’identifier tous les états par lequel un objet peut passer et donc de trouver les actions qui permettent d’obtenir un changement d’état.
Diagramme de collaboration (de communication): Pour identifier les messages échangés entre objets et trouver de nouvelles actions.
Analyse : exemple DSE
Analyse : exemple DSE
Etape Conception Quand ? QUEL DIAGRAMME? Et POURQUOI?
09/12/2019 DOUHA
22
Conception de la solution
Tous les diagrammes précédents : Afin de vérifier la cohérence des diagrammes et d’apporter des détails nécessaires à l’implémentation de la solution.
Diagramme de composants : Pour indiquer de quelle façon le logiciel sera construit. Un composant pouvant être un exécutable, un fichier, un module, une base de données, etc.
Diagramme de déploiement: Afin de montrer sur quel matériel chacun des composants devra être installé et pour indiquer les éventuels moyens de communication entre les parties.
Conception (Design)
09/12/2019 DOUHA
23
But de la conception :
Définir une architecture logicielle statique et comportementale orientée objet permettant d’écrire facilement le code source de l’application.
Attention : En phase de conception, on ne s’intéresse pas à l’écriture spécifique du code. Pour cela :
Architecture dynamique à l’aide de diagramme de Sequence.
Architecture statique à l’aide de diagramme de Classe et diagramme de Package.
Patrons de conception élémentaires pour les bases de la POO.
Conception (Design)
09/12/2019 DOUHA
24
La conception concerne le domaine de la solution on s’occupe des aspects liés à l’implémentation, définition correcte des hiérarchies de classes, ajout de packages logiques et de classes réutilisées, ajout de classes permettant une implémentation correcte de
certaines notions (collections, persistance, etc.).
Passage de l’analyse à la conception
le travail du concepteur de choisir comment les objets logiciels vont interagir entre eux pour réaliser telle ou telle opération. Jacobson a proposé le premier des stéréotypes de classes pour décrire la réalisation d’un cas d’utilisation.
remplacer le système vu comme une boîte noire (du point de vue de l’analyse) par des objets logiciels (du point de vue de la conception),
Passage de l’analyse à la conception
Passage de l’analyse à la conception
À l’intérieur du système, Jacobson distingue les trois stéréotypes suivants :
– <<boundary>> : classes qui servent à modéliser les interactions entre le système et ses acteurs ;
– <<control>> : classes utilisées pour représenter la coordination, l’enchaînement et le contrôle d’autres objets – elles sont en général reliées à un cas d’utilisation particulier ;
– <<entity>> : classes qui servent à modéliser des informations durables et souvent persistantes
Passage de l’analyse à la conception
Passage de l’analyse à la conception
Passage de l’analyse à la conception
Passage de l’analyse à la conception
Utilisation des diagrammes dans le processus de développement
09/12/2019 DOUHA
32
Analyse A. Identification des besoins : Cas d'utilisation B. Cas d'utilisation et Use Case Diagrams C. Modèles du domaine métier : Diagramme de Classes D. Processus métiers : Diagramme d’activités
Conception
A. Visualisation des concepts (UML : Class) B. Comportement dynamique (UML : Sequence,
Communication) C. Patrons de conception élémentaires (UML : Component) D. Visualisation des concepts,(UML : Class, Package) E. Diagrammes UML et code Java
Utilisation des diagrammes dans le processus de développement : Vue globale
09/12/2019 DOUHA
33
Analyse Conception Code
