Upload
aymeric-cottin
View
129
Download
2
Embed Size (px)
Citation preview
Plan du cours
Processus Unifié (Unified Process)
Le cycle en Y
Techniques d’analyse et de conception
Processus Unifié
Unified Process
Définition UP est un processus de type adaptatif, il est
Itératif et incrémental Guidé par les besoins (exigences) des
utilisateurs Centré sur l’architecture Piloté par les risques
On le représente selon l’axe statique et dynamique des processus de développement.
Phases et itérations
UP comporte les quatre phases suivantes: Pré étude: définition du cadre du projet Élaboration: établissement d’un plan de projet et d’une
architecture solide Construction: développement du système Transition: livraison du système aux utilisateurs finaux
Il existe un certain nombre d’itérations à l’intérieur de chaque phase.
Une itération représente un cycle de développement logiciel complet (analyse des besoins version exécutable)
Cycle de vie
Pré étude Élaboration Construction Transition
Modélisation métier
Exigences
Analyse et conception
Implémentation
Tests
Déploiement
Itération préliminaire Itér 1 Itér 2 Itér
nItér n+1
Itér n+2
Itér m
Itér m+1
Phases Pré étudePré étude : On définit le cadre du système et on
délimite la portée du projet. Ce cadre comprend: Les critères de réussite La mise en évidence des risques Les estimations des ressources nécessaires Un plan de phase qui contient un planning des
principaux jalons Un prototype exécutable validant le concept
ÉlaborationÉlaboration: consiste à Analyser le domaine du problème Établir une architecture solide Développer le plan du projet Éliminer les éléments à risques pour le projet
Phases ConstructionConstruction: On développe un produit complet et
prêt à transiter vers les utilisateurs, de manière itérative et incrémentale
TransitionTransition: au cours de cette phase on déploie le logiciel pour les utilisateurs, on réajuste le système en corrigeant les éventuels bugs ou on achève certains fonctionnalités qui avaient été remises à plus tard
Workflows et processusModélisation métier décrit la structure et la dynamique de l’entreprise
Exigences décrit la méthode basée sur les cas d’utilisation pour saisir et organiser les exigences
Analyse et conception décrit les différentes vues d’une architecture
Implémentation prend en compte le développement logiciel, les tests unitaires et l’intégration
Tests décrit les cas de test, les procédures et les métriques de recherche d’erreur
Déploiement couvre la configuration du système à livrer
Gestion de configuration
Contrôle les modification et maintient les artefacts d’un projet
Gestion de projet Décrit différents stratégies de travail avec un processus itératif
Environnement Couvre l’infrastructure nécessaire demandée pour développer un système
Workflows et artefactsWorkflows Artefacts
Expression des besoins Vision du projet
Spécifications Modèle des cas d’utilisation
Spécifications supplémentaires
Glossaire
Analyse Modèle du domaine
Conception Modèle de conception
Architecture logicielle
Modèle de données
Implémentation Modèle d’implémentation
Tests Modèle de tests
Déploiement Modèle de déploiement
Gestion de projets Plan de développement
Environnement Cas de développement
UP est Itératif et incrémental Le développement d’un logiciel nécessite qu’on le
découpe en plusieurs petits projets.
Chaque projet représente une itération qui donne lieu à un incrément.
Une itération désigne la succession des activités de développement
un incrément correspond aux stades de développement du produit
UP est piloté par les uses casesPour servir les attentes des utilisateurs, On centre le Pour servir les attentes des utilisateurs, On centre le processus de développement sur leurs besoins.processus de développement sur leurs besoins.
On fait apparaître ces besoins à l’aide de la technique des On fait apparaître ces besoins à l’aide de la technique des cas d’utilisation :cas d’utilisation :
en capturant les besoins fonctionnels d’un systèmeen capturant les besoins fonctionnels d’un système
en orientant le travail de chaque itérationen orientant le travail de chaque itération
vont guider le processus à travers l’utilisation des vont guider le processus à travers l’utilisation des différents modèles UML qui représentent le système.différents modèles UML qui représentent le système.
Modèle du domaine
Modèle de conception
Modèle d’implémentation
Modèle de tests
Modèle de déploiement
Conçus par
Réalisés par
Déployés par
Testés par
Diagramme des Uses Case
Analysés par
Cahier des charges
Modèle d’architecture
Structurés par
UP est centré sur l’architecturel’architecture doit prévoir la réalisation de tous les l’architecture doit prévoir la réalisation de tous les uses case et doit évoluer avec eux. uses case et doit évoluer avec eux.
Elle le fait en tenant compte de facteurs tels que:Elle le fait en tenant compte de facteurs tels que: La plateforme d’exécution La plateforme d’exécution
Matériel, système, BD, réseau,etc.Matériel, système, BD, réseau,etc. Les composants réutilisablesLes composants réutilisables
Librairies, caisse à outils, composants du commerce, Librairies, caisse à outils, composants du commerce, etc. etc.
Les considérations de déploiement et les besoins non Les considérations de déploiement et les besoins non fonctionnelsfonctionnels
La performance, la fiabilité, la robustesse, etc.La performance, la fiabilité, la robustesse, etc.
UP est piloté par les risques
Un risque est un événement redouté dont Un risque est un événement redouté dont l’occurrence est plus ou moins prévisible.l’occurrence est plus ou moins prévisible.
Le pilotage par les risques c’est:Le pilotage par les risques c’est: Analyser les risques potentiels au plus tôtAnalyser les risques potentiels au plus tôt Hiérarchiser les risquesHiérarchiser les risques Associer un ensemble de uses case à chaque Associer un ensemble de uses case à chaque
risquerisque Déclencher les itérations selon la criticité des uses Déclencher les itérations selon la criticité des uses
cases qu’elles regroupentcases qu’elles regroupent
UP propose une gestion des risques. Ce qui UP propose une gestion des risques. Ce qui constitue une avancée significative.constitue une avancée significative.
Les adaptations de UP
UP est un processus générique de UP est un processus générique de développement. Il doit être adaptée au développement. Il doit être adaptée au contexte du projet, de l’équipe et de contexte du projet, de l’équipe et de l’organisation concernée.l’organisation concernée.
Il existe donc des adaptations d’UP dont les Il existe donc des adaptations d’UP dont les plus connues sont:plus connues sont: Le Rational Unified Process (RUP)Le Rational Unified Process (RUP) L’eXtreme Programming (XP)L’eXtreme Programming (XP) Le Two Tracks Unified Process (2TUP)Le Two Tracks Unified Process (2TUP)
Cycle en Y
Two Track Unified Process
Définition 2TUP est un processus UP apportant une réponse
aux contraintes de changement continuel des SI: fonctionnel et technique
2 Track: processus suivant deux chemins Fonctionnel Architecture Technique
SIContraintesContraintesfonctionnellesfonctionnelles
ContraintesContraintestechniquestechniques
Exemples Une entreprise modifie son catalogue de produit en
imposant de nouvelles règles de tarification évolution fonctionnelle.
Cette même entreprise décide de rendre accessible son catalogue via le WEB évolution technique.
Cette entreprise décide finalement de fusionner son catalogue avec une autre entreprise du même secteur évolution fonctionnelles et techniques.
Cycle en Y
La réalisation du système consiste à fusionner les résultats des deux évolutions fonctionnelle et technique: ce qui conduit à un processus de développement en forme de Y
Cycle en YContraintesContraintesfonctionnellesfonctionnelles
ContraintesContraintestechniquestechniques
Branchefonctionnelle
Branchetechnique
Capture des besoins fonctionnels
Capture des besoins techniques
Analyse Conception générique
Recette
Conception préliminaire
Codage et tests
Conception détaillée
prototype
Cycle en Y
La branche gauche (fonctionnelle) du Y Capture des besoins fonctionnels
Produit un modèle des besoins focalisée sur le métier des utilisateurs
Qualifie au plus tôt le risque de produire un système inadapté
Permet à la maîtrise d’œuvre de consolider les spécifications et de vérifier la cohérence
L’analyse Précise ce que l’on va réaliser en termes métier Le résultat de l’analyse ne dépend d’aucune
technologie particulière
Cycle en YLa branche droite (architecture technique) du Y
Capture des besoins techniques Recense toutes les contraintes et les choix dimensionnant
la conception Identifie les outils et les matériels ainsi que les contraintes
d’intégration avec l’existant La conception générique
Définit les composants nécessaires à l’élaboration de l’architecture technique
Construit le squelette du système et élimine les risques au niveau technique
A pour objectif d’uniformiser et de réutiliser les mêmes mécanismes pour la plupart des systèmes
Est indépendante des aspects fonctionnels
Cycle en YLa branche du milieu
La conception préliminaire Intègre le modèle d’analyse dans l’architecture
technique Trace la cartographie des composants du
système à développer La conception détaillée
Étudie comment réaliser chaque composant Codage
Produit les composants et teste au fur et à mesure les unités de code réalisées
Recette Valide les fonctions du système développé
Cycle en Y Les branches du «Y» produisent des
modèles réutilisables La branche gauche capitalise la connaissance du
métier de l’entreprise: les fonctions du système d’information sont indépendantes des solutions techniques utilisées.
La branche droite capitalise le savoir faire technique: les techniques utilisées peuvent être réalisées indépendamment du besoin fonctionnel
La connaissance d’un langage de modélisation comme UMLLa mise en œuvre d’un processus de développement adaptatif
comme UPNe disent pas ce que doit faire le système ni comment le
modéliser !
Nous avons besoin de techniques pour le spécifier, l’analyser et le concevoir.
La modélisation du système
Modélisation
Techniques de spécification des besoins
Les cas d’utilisation Les cas d’utilisation sont une collection de
scénarios de réussite et/ou d’échec.
Ils décrivent la façon dont un acteur utilise un système pour atteindre un but.
Ils sont de type boîte noire et décrivent un système en terme de comportement.
Ce qu’il fera et non comment il le fera!
Un scénario est un chemin particulier pris lors de l’exécution d’un use case
NominalNominal - c’est le scénario typique de succès
AlternatifAlternatif – il correspond aux traitements alternatifs possibles
D’échecD’échec – il recensent les échecs dans le déroulement d’une étape de scénario
Les scénarios
Identification des uses cases Comment identifier les uses cases ?
Les Processus Métier Élémentaires servent à atteindre le but d’un utilisateur du système.
Ils sont de niveau Objectif utilisateur et sont analogues aux cas d’utilisation d’un système.
Recenser les PME, permet de découvrir l’ensemble des cas d’utilisation d’un système
Description des uses cases Seule la forme textuelle permet de décrire les cas
d’utilisation. UML n’en propose aucune.
Selon le niveau de précision, la rédaction d’un cas d’utilisation peut prendre deux formes: Résumée détaillée
Quelle que soit la forme utilisée, on doit toujours se concentrer sur les intentions de l’utilisateur les responsabilités du système
Use case: Résumé Le format résumé décrit brièvement, le
comportement du cas d’utilisation.
Il ne mentionne que l’activité et les échecs les plus significatifs.
On les élabore en étendant la liste des objectifs par acteur.
Use case: Détaillée Dans sa version étoffée:
Titre Description Acteurs Portée Niveau Parties prenantes et intérêts Pré conditions et déclencheurs Scénario nominal Scénarios alternatifs Scénarios d’erreur Post conditions (garantie de succès et d’échec) Variantes de données et de technologies Contraintes IHM Contraintes non fonctionnelles Questions en suspens
Modèle des cas d’utilisation UML représente les cas d’utilisation par
le diagramme de cas d’utilisation.
On y montre les acteurs en relation avec les cas d’utilisation.
Ce qui donne une vision spatiale et dynamique du système
Exemple: consulter une commande
Utilisateur
(from Acteurs)
Rechercher des commandes
Consulter des commandes
<<include>>
Consulter le detail d'une commande
<<extend>>
Consulter la synthèse d'une commande
(from UC Commun Commande)
Exemple: consulter une commande Titre
Consulter commande Description
Cette fonctionnalité permet à l'acteur ayant droit de consulter les commandes en cours ou archivés.
ActeursL'utilisateur
Pré conditionsL'acteur s'est authentifié sur le système. Il a choisit un contrat et un catalogue.
Post conditionsLes commandes sont consultées
DéclencheursL'acteur peut accéder à la consultation de commandes à partir du menu principal de la page d'accueil
Exemple: consulter une commande Description du traitement nominal
1. L'acteur sélectionne un client2. l'acteur recherche une commande à partir d'un critère <<include>> Rechercher des commandes.3. Le système affiche les commandes en cours et les commandes archivées associées au critère de recherche.4. L'acteur peut sélectionner une commande pour consulter les détails.5. Le système affiche les détails de la commande sélectionnée <<extend>> Consulter le détail d'une commande.
Complément d'exigences fonctionnellesfaut-il limiter la consultation uniquement aux services auxquels l'utilisateur à le droit ?La liste des commandes en cours est composée des éléments suivants :- la date de création de la commande (date d'enregistrement),- le numéro de la commande, lien vers la consultation détaillée d'une commande ,- le code et le libellé du service,- le statut de la commande (relatif au processus),- l'état de la commande (relatif au processus).
La liste des commandes archivée est composée des éléments suivants :- la date de création de la commande (date d'enregistrement),- le numéro de la commande, lien vers la consultation détaillée d'une commande ,- le code et le libellé du service.
Exemple: consulter une commande Description des exceptions
Sans objet.
Description des traitements alternatifsSans Objet
Contraintes IHMLes commandes sont affichées par des tranches de 20. Les commandes en cours sont affichées avant les commandes archivées.
Contraintes non fonctionnellesaccès en moins de 5 s au service.
Modélisation
Techniques d’analyse et conception
Les patterns Un pattern est une bonne pratique face à un problème
courant. Il est souvent traduit dans la littérature française par «modèle», «motif», «solution abstraite» ou «patron»
Un pattern est une capitalisation du savoir-faire et de l’expérience pour résoudre des problèmes récurrents intervenants dans les différents niveaux du processus: analyse (analysis pattern), architecture (architectural pattern) conception (design pattern) programmation (idiomes ou idiomatiques en français)
C’est un moyen de partager la connaissance de la résolution d’un type de problème sous une forme « conceptuelle », mais ce n’est pas une solution implémentée.
Pourquoi les patterns Tout d’abord, pour ne pas réinventer, mais aussi pour :
se concentrer sur de bons designs objets, apprendre en suivant de bons exemples, écrire du code facilement compréhensible par les autres
programmeurs.
Utiliser les DP apporte des avantages … Un vocabulaire commun, Une capitalisation de l’expérience Un niveau d’abstraction plus élevé qui permet d’élaborer des
constructions logicielles de meilleure qualité Une réduction de la complexité Un guide/catalogue de solutions,
… mais n’est pas sans inconvénients car cela nécessite Un effort de synthèse : reconnaître, abstraire… Un apprentissage à effectuer, une expérience.
Techniques d’analyse Objectifs
Analyser les besoins, c’est rechercher les objets du domaine, leurs propriétés et leurs relations.
Le diagramme de classe issu de cette activité
représente:
les classes conceptuelles ou les objets du domaine. les attributs de ces classes. les associations entre ces classes.
Techniques d’analyse Mode opératoire
Pour chaque cas d’utilisation, on déroule les étapes des scénarios que l’on analyse:
Pour identifier les classes du domaine. Pour rechercher les attributs de ces classes. Pour recherches les associations entre ces
classes. Pour typer ces associations.
Techniques d’analyse Identification des classes
Pour identifier les classes conceptuelles, plusieurs techniques existent:
l’analyse linguistique. les listes de catégories. les classes de spécifications. les types de données non primitifs. les patterns d’analyse
Techniques d’analyse Les attributs
Un attribut est la valeur d’une donnée logique d’un objet.
Une commande par exemple à un type, une description et une date qui doivent être connus.
La classe conceptuelle Commande doit donc avoir des attributs type, description et date
Techniques d’analyse Les associations
Une association est une relation significative entre des classes
On distingue plusieurs sortes d’associations : Les associations multiples La généralisation/spécialisation Les classes d’association L’agrégation L’association qualifiée L’association réflexive
Modélisation
Réalisation des cas d’utilisation
Réalisation des cas d’utilisation Les opérations système
Les opérations système gèrent les événements entrants
:Utilisateur :Système
consulterCommande()
Ces événements système entrants invoquent des opérations système.
L’événement système consulterCommande invoque une opération système appelée
consulterCommande () et ainsi de suite.
Consulter commande
Réalisation des cas d’utilisation
Pour chaque cas d’utilisation, on liste toutes les événements système que l’on modélise.
en analysant les opérations système
en identifiant les classes conceptuelles qui collaborent pour les réaliser
en affectant des responsabilités à chacune de ces classes
en matérialisant les choix d’affectation des responsabilités dans un diagramme d’interaction
Réalisation des cas d’utilisation Les diagrammes d’interactions
Quelque soit les problèmes de conception, on doit implémenter des méthodes pour les résoudre.
Pour réaliser ce travail, les diagrammes d’interaction sont indispensables.
Ils servent à représenter les actions réalisées par les objets en fonction de leurs responsabilités.
Ces diagrammes sont de deux types:
les diagrammes de séquence. les diagrammes de collaboration
Réalisation des cas d’utilisation Analyse:
Une ligne article doit être créée et associée à une spécification produit et à la vente en cours.
La quantité de la ligne article doit être renseignée.
Responsabilité:
qui doit créer la ligne article ? qui connaît la spécification d’article à associer
à la ligne article ? qui doit transmettre la quantité à la ligne
article ?
Techniques de conception L’activité de conception
La spécification et l’analyse des besoins ont permis de définir quel système construire.
L’activité de conception, s’intéresse à la façon de construire le système.
Elle vise à construire une solution qui conforme aux besoins du système
Techniques de conception La conception orienté objet
En conception, un système est vu comme une communauté d’objets qui collaborent entre eux.
Ce mode de réflexion permet:
d’identifier les objets qui contribuent à la réalisation d’un événement système.
de définir les actions pour qu’ils s’acquittent de leurs responsabilités.
Techniques de conception Les responsabilités sont affectées aux classes et sont de
deux types:
Les responsabilités de Faire comme:
Créer un objet ou faire un calcul. Déclencher une action sur un objet. Contrôler les activités d’un objet.
Les responsabilités de Savoir comme:
Connaître les données encapsulées. Connaître les objets connexes. Connaître les éléments à dériver ou à calculer
Techniques de conception Les classes de Jacobson
les classes de conception identifiées peuvent être classifiées selon trois catégories, correspondant aux trois classes d’analyse de Jacobson :
Les classes « boundary » jouent le rôle d’intermédiaires entres les acteurs externes au système et
le coeur du système. Il s’agit des classes de présentations, d’interfaces avec d’autres systèmes ou pilotes de périphériques. Généralement on retrouve au moins une classe « boundary » par paire (acteur, cas d’utilisation).
Les classes « entity » constituent l’abstraction du cas d’utilisation et correspondent plus ou
moins aux entités identifiées dans la phase d’analyse système. Elles se traduisent souvent par des composants persistants.
Les classes « control » permettent de découpler les deux types de classes précédentes. Elles
contiennent la logique applicative, la coordination, l’enchaînement de tâches dans les systèmes.
Techniques de conceptionQuelques règles sont à respecter pour la mise en place de ces classes
d’analyse :
Les acteurs ne peuvent interagir qu’avec les boundary
Les boundary peuvent interagir avec les control ou exceptionnellement avec d’autres boundary, mais jamais directement avec les entity
Les control peuvent interagir avec les boundary, les entity ou d’autres control
Les entity ne peuvent interagir qu’entre elles. (les control peuvent manipuler des entity, mais pas l’inverse)
Ces classes apparaîtront pendant la phase où on passe des diagrammes d’analyse système aux premiers diagrammes de conception (éclatement des diagrammes de séquence ou de collaboration).
Architecture
L’architecture logicielle et technique
ArchitectureL’architecture c’est « l’art de concevoir et de construire
un bâtiment selon un esthétisme et des règles techniques déterminées. »
Cette définition peut s’appliquer à la fabrication du logiciel.
A l’instar d’un bâtiment, un logiciel est:
structuré par un plan, illustré par une maquette, réalisé par des procédés et des outils adaptés.
ArchitectureL’architecture d’un système peut être vue selon deux
angles principaux.
La vue logique qui concerne l’organisation conceptuelle ou la structure du système.
La vue de déploiement qui concerne l’organisation physique du système:
Machines, OS, Réseaux, etc …
ArchitectureLa vue logique ou l’architecture logicielle décrit:
L’organisation générale d’un système. Les éléments qui le structurent et leurs interfaces. Les propriétés et les collaborations des éléments qui
le composent.
Elle contribue à une meilleure qualité du Logiciel en terme de:
maintenance, évolutivité, réutilisation, performance, etc.
Architecture L’architecture par couches
On l’applique aux applications munies d’une interface graphique et manipulant des données.
Elle a pour but de séparer les différentes logiques d’une application:
La présentation. La logique applicative. Le domaine métier. L’accès aux des données.
Architecture (déploiement) La vue par niveau ou Tiers donne la vision physique
d’un système.
Elle distribue les couches logiques d’un système sur ses éléments physiques.
Plusieurs de ces modèles ont vu le jour:
Le modèle 1 Tiers. Le modèle 2 Tiers ou Client/Serveur ou Thick client. Le modèle 3 Tiers aussi appelé N-Tiers ou Thin client.
Architecture 1/3 Les applications tournaient sur
des systèmes en temps partagé. Caractéristiques:
Gros systèmes mêlant interfaces, règles métiers et données
Terminaux passifs Avantages
Administration performance sécurité
Inconvénients Mode caractère peu convivial Ouverture vers d’autres
systèmes
Terminaux passifsTerminaux passifs Gros systèmeGros système
Architecture 2/3 L'architecture à deux niveaux (2-
tiers) caractérise les systèmes clients/serveurs.
Caractéristiques: Un SGBD et une application
Avantages Permet de répartir la puissance
machine sur les clients Mise en oeuvre du modèle de bases
de données relationnelles Intégration inter-systèmes au
niveau des données possibles Inconvénients
Déploiement Maintenance, gestion des versions Les règles métiers réparties sur les
deux composantes
clientsclients SGBDRSGBDR
Architecture 3/3Caractéristiques:
Les 3 niveaux: Le client: le demandeur de ressources Le serveur d'application (appelé aussi middleware) chargé de fournir la ressource mais faisant appel à un autre serveur Le serveur secondaire (généralement un serveur de base de données, fichiers XML, annuaire LDAP, ...), fournissant un service au premier serveur
Des normes de communication entre les niveaux
clientsclients Serveur Serveur d’applicationd’application RessourcesRessources
Architecture N/3 La requête d'un client peut-
être re-routée vers un autre serveur
Différents serveurs peuvent accéder à une même base de données ou à un même serveur de données.
Les différents serveurs peuvent être directement en communication (pour se synchroniser, se répartir les requêtes des clients, prendre la place d'un autre serveur défaillant, etc.).