Please enable JavaScript.
Coggle requires JavaScript to display documents.
Méthodologie développement (ex: Processus Unifié) Exam 1 (Définition…
Méthodologie développement
(ex: Processus Unifié)
Exam 1
Repose sur
Conception (design)
orienté objet
Concevoir une solution informatique
Tracer des plans (plus ou moins détaillés) sous la forme de documents et diagrammes (ex: UML)
Assignation des responsabilités aux classes
Identification des classes
Organisation et communication entre les classes
Analyse orientée objet
Décrire la situation à l’aide de documents et diagrammes (ex: UML)
Comprendre le problème dans une perspective de classes et d'objets tirés du domaine de l'application
Programmation orientée objet
Mettre en oeuvre la solution à l’aide d’un langage (ex: Java)
UML
:warning: :forbidden: Ne jamais modéliser la solution en tenant compte du langage de programmation qui sera utilisé
Types de diagrammes
Diagram
Structure Diagram
Component Diagram
Deployment Diagram
Composite Structure Diagram
Object Diagram
Class Diagram
Package Diagram
Profile Diagram
Behaviour Diagram
Use Case Diagram
State Machine Diagram
Activity Diagram
Interaction Diagram
Communication Diagram
Interaction Overview Diagram
Sequence Diagram
Timing Diagram
Définition
:star: Processus de développement itératif reposant sur UML
:star: Le processus original (UP) peut être vu comme un tronc commun à plusieurs méthodes itératives
Méthodologie / processus de développement logiciel
:star: Décrit notamment quand et comment procéder à l’analyse, à la conception, à la programmation, etc..
:star: Spécifie les activités à réaliser et les livrables («artefacts») à produire
Comprend
2)Processus de construction des modèles
3)Outils facilitant la construction et la description des modèles
1)Notation permettant de décrire les modèles (ex:UML)
Approches de développement logiciel
Méthode séquentielle
Waterfall ('En cascade')
:star: Formée d’étapes successives -> Analyse, Conception, Implantation, Integration, Test, Transition
:check: Applicable avec succès pour de petits projets
:red_cross: Très rigide et exige que toutes les spécifications soient complètes avant que la conception et l’implantation commencent
:red_cross: Mène à des échecs cuisants sur des projets d’envergure s’étalant sur de longues périodes de temps
Méthodes itératives
Spirale
:star: Approche classique visant à réduire les impacts négatifs de la méthode Waterfall en lui ajoutant des étapes de prototypage
Unified Process (UP)
:star: Processus de développement itératif reposant sur UML
Méthodes agiles
:star: Courtes itérations (ex: deux semaines) incluant toutes les étapes de développement logiciel -> Requirements, design, implantation, intégration, test et acceptation par le client
:check: Favorise la participation étroitedu client au développement du produit
:check: Favorisele travail en équipeen mettantl’accentsurla collaboration entre les membres de l’équipe plutôt que sur la documentation
:check: Développer une architecture robuste
–Évaluation rapide de l’architecture: amélioration, correction possible
:check: Favorisela participation étroitedu client au développement du produit
:check: Gérer des besoins évolutifs (et de façon évolutive)
–Les utilisateurs (le client) donne une rétroaction constante
–Répondre à ces rétroactions nécessite un changement incrémental (plutôt qu’une refonte totale du système)
:check: Permettre le (les) changement(s)
–Adapter le système aux problèmes, aux besoins, aux requis
:check: Apprendre tôt dans le processus de développement
–Tout le monde obtient une compréhension du domaine (des processus relatif au domaine) tôt
Les vues lors du design
Modèle static
UML Class Diagram
Modèle dynamic
UML Static Diagram
Organisation du travail / itérations en phases
Les 4 phases (Voir le tableau des phases de la couverture du manuel)
Élaboration
:star: Planifier le projet, développer les fonctionnalités et l’architecture de base
Construction
:star: Terminer le développent du produit
Conceptualisation/Inception
:star: Définir la portée du projet
Buts
Établir la faisabilité
Décider si on doit pousser plus loin (décider si on va réaliser le projet)
Établir une définition du projet, les objectifs
Transition
:star: Transférer le produit à sa communauté d’utilisateurs
:star: Les artefacts sont les livrables produits
:star: Dans chaque itération, on réalise du travail associé à plusieurs activités / disciplines
:star: Chaque phase est composée d’itération S
Activités (Disciplines)
Design / Conception
:gift: Modèle de conception / Design model
Diagrammes d’interaction
:star: Servent à montrer comment les objets d’un système collaborent pour réaliser une fonctionnalité du système
:star: Montre comment les objets s’échangent des messages(i.e. comment un objet, le client, invoquent une opération sur un autre objet, le serveur). Ces échanges sont appelés interactions
Types de diagrammes d’interaction
Diagramme de séquences
:star: Notation UML plus expressive
:star: Plus facile de voir la séquence des appels dans le temps
2 utilisations
Diagramme de séquence système (DSS)
:star: Se concentre sur la description de l’interaction, souvent dans des termes proches de l’utilisateur et sans entrer dans les détails de la synchronisation
Diagramme de séquence (de conception)
:star: Permet la représentation précise des interactions entre objets, autrement dit le séquencement des flots de contrôle
Diagramme de communication
:star: Met l’accent sur les relations entre les objets
:star: Permet édition dans un espace limité(ex: tableau blanc)
:star: Plus facile à modifier si on travaille à la main
Voir pdf 9 diapos 41 à 46
Tout autre diagramme UML pertinent selon le contexte
Diagramme d'état
:star: Permet de représenter, pour un objet, un système, un sous-système, ou un acteur
Les changements d’états possibles (transitions) en réaction à des événements
Son comportement (action) face à un événement selon l’état dans lequel il se trouve
Les états que peut prendre cet objet
:star: Autrement dit, on représente le cycle de vie de l’objet
:warning: Pas obligatoire
:star: Peut servir à clarifier différents aspects liés à n’importe quel modèle (ça dépend du projet)
Types d'états
Mono-état (également appelé état-indépendants / state-independant)
:star: Ils réagissent toujours de la même façon suite à un événement
Multi-états / état-dépendant / state-dependant
:star: Leur comportement varie selon l’état /mode dans lequel ils se trouvent
État
Possède un nom
Représenté par un rectangle dont les coins sont arrondis
Généralement dans un état donné pour un certain temps
Généralement durable et stable
Représente une situation bien définie durant la vie de l’objet
Voir pdf 13 diapos 11 à 27
Diagrammes de classes de conception (DCC)
:star: Décrit le système en termes de ses classeset des relationsentre celles-ci (s'inspire du diagramme de classes conceptuelles)
Plusieurs classes vont disparaître, d’autres vont apparaître par rapport au diagramme de classes conceptuelles
Vision plus logiciel des classes, relations et attributs
Représentation des classes en UML
le compartiment des attributs
le compartiment des opérations
le compartiment du nom
Voir pdf 7 diapos 13 à 34
Architecture logique
Séparation en packages
Architecture en couche
Architecture Modèle-Vue
Séparer la logique applicative et l’interface utilisateur
Améliore la ré utilisabilité
Implémentation
:gift: Code
Analyse
Modélisation domaine d’affaires / Business modeling
:gift: Modèle du domaine
Diagramme de classe «conceptuel»
Ex pdf 6 diapos 8 à 10 et 35 à 44
Identifier les attributs
:star: Types de données simples
•Ex: nombre, chaîne de caractères
Identifier les classes conceptuelles
:star: Décrire «la vraie vie vraie» :
Identifier les relations
Identifier les relations pour lesquelles
La connaissance du lien entre les classes est importante à un certain moment; et/ou
Il y a concordance entre la relation et la liste de relations communes (voir Larman)
Parfois un diagramme d’activités
:star: Représentation visuelle des classes conceptuelles (des objets du monde réel) pour un domaine d’application / domaine d’affaires
Analyse des besoins / Exigences/ Requirements
:gift: Énoncé de vision
:star: Description de haut niveau du projet, des objectifs, etc..
:gift: Modèle de cas d’utilisation / Use-case model
Texte des cas d’utilisation
:star: Ce texte peut décrire un ou plusieurs «scénarios» associés à ce use case.
–Un scénario principal/primaire
–Des scénarios alternatifs
Abrégé
Détaillé
Détaillé en version deux colonnes
Diagramme de séquence système (DSS)
Pour un scénario précis d'un cas d'utilisation
Montre
Les opérations qu’elles déclenchent
Les données échangées
Les événements générés par l’utilisateur
:star: Représente graphiquement les échanges entre les acteurs et le système (on ne rentre généralement pas à l’intérieur du système) à la manière d’une conversation :
Diagramme des cas d’utilisation
:star: Identifie les cas d’utilisation et les place dans un contexte
Acteurs
Acteurs secondaires
Qui est intéressé par les résultats retournés par le système ?
Systèmes externes
Quels sont les moyens physiques dont le système a besoin pour faire les traitements ?(systèmes externes)
Acteurs primaires
Qui va utiliser la fonctionnalité principale du système ?
Cas d’utilisation / use-case
Une fonctionnalité complète telle que perçue par un acteur
:star: Chaque bulle dans le diagramme identifie/nomme/réfère à un cas d’utilisation
Relations
«include»
Le cas qui est inclus peut aussi être exécuté de manière autonome
«extend»
Le cas «étendant» ne peut généralement pas être exécuté de manière autonome
Héritage
Définir une version modifiée d’un cas d’utilisation
:gift: Spécifications supplémentaires
:star: Autres besoins (non fonctionnels)
Plan sommaire du projet
Plan détailléde la prochaineitération(première itérationde la phase d’élaboration)
Principaux facteurs de risque et stratégies de gestion du risque
Prototypes / preuve de concept (si nécessaire)
:gift: Glossaire
:star: Définition de la terminologie de base du domaine
Les grands principes (GRASP)
Caractéristiques recherchées
Modularité
Faible couplage
Problème
Comment réduire l’impact des modifications futures?
Solution
Affecter les responsabilités aux classes de manière à éviter tout couplage inutile entre les classes
Forte cohésion
Problème
Comment s’assurer que les objets restent compréhensibles et faciles à gérer, et qu’ils contribuent au faible couplage?
Solution
Affecter les responsabilités de manière à ce que la cohésion demeure élevée
:warning: Va parfois à l’encontre d’autres principes
:star: La modularité est la propriété d’un système qui est décomposé en un ensemble de modules cohésifs et faiblement couplés
Protection contre les variations
Recettes
Fabrication pure
Contrôleur
Problème
Quel est le premier objet au-delà de la couche présentation qui reçoit les «messages» de l’utilisateur et contrôle l’accès aux objets de la couche du domaine?
Solution
Généralement: un objet qui représente le «système global» ou un «objet racine»
:star: Le contrôleur délègue les tâches aux autres objets. Il ne fait normalement pas faire grand-chose par lui-même
:star: Larman: il est acceptable de «lire» directement les informations de la couche application pour rafraichir l’affichage
:star: Le contrôleur peut retourner un objet permettant la lecture seule
Indirection
Expert en information
Problème
À quel classe affecter une certaine responsabilité (méthode) ?
Solution
À la classe qui possède les informations nécessaires pour s’en acquitter
Créateur
Problème
Qui devrait créer les instances de la classe A?
Solution
La classe qui…
•Contient ou agrège les A
•Enregistre les A
•Utilise étroitement les A
•Possède les données pour initialiser des objets A
Polymorphisme
