La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Processus unifié: Modèle En Y Mustapha EL FEDDI

Présentations similaires


Présentation au sujet: "Processus unifié: Modèle En Y Mustapha EL FEDDI"— Transcription de la présentation:

1 Processus unifié: Modèle En Y Mustapha EL FEDDI

2 Plan du cours Processus Unifié (Unified Process) Le cycle en Y Techniques danalyse et de conception

3 Processus Unifié Unified Process

4 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 larchitecture Piloté par les risques On le représente selon laxe statique et dynamique des processus de développement.

5 Phases et itérations UP comporte les quatre phases suivantes: Pré étude: définition du cadre du projet Élaboration: établissement dun plan de projet et dune architecture solide Construction: développement du système Transition: livraison du système aux utilisateurs finaux Il existe un certain nombre ditérations à lintérieur de chaque phase. Une itération représente un cycle de développement logiciel complet (analyse des besoins version exécutable)

6 Cycle de vie Pré étudeÉlaborationConstructionTransition Modélisation métier Exigences Analyse et conception Implémentation Tests Déploiement Itération préliminaire Itér 1Itér 2 Itér n Itér n+1 Itér n+2 Itér m Itér m+1

7

8 Phases Pré étude Pré é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

9 Phases Construction Construction: On développe un produit complet et prêt à transiter vers les utilisateurs, de manière itérative et incrémentale Transition Transition: 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

10 Workflows et processus Modélisation métierdécrit la structure et la dynamique de lentreprise Exigencesdécrit la méthode basée sur les cas dutilisation pour saisir et organiser les exigences Analyse et conceptiondécrit les différentes vues dune architecture Implémentationprend en compte le développement logiciel, les tests unitaires et lintégration Testsdécrit les cas de test, les procédures et les métriques de recherche derreur Déploiementcouvre la configuration du système à livrer Gestion de configuration Contrôle les modification et maintient les artefacts dun projet Gestion de projetDécrit différents stratégies de travail avec un processus itératif EnvironnementCouvre linfrastructure nécessaire demandée pour développer un système

11 Workflows et artefacts WorkflowsArtefacts Expression des besoinsVision du projet SpécificationsModèle des cas dutilisation Spécifications supplémentaires Glossaire AnalyseModèle du domaine ConceptionModèle de conception Architecture logicielle Modèle de données ImplémentationModèle dimplémentation TestsModèle de tests DéploiementModèle de déploiement Gestion de projetsPlan de développement EnvironnementCas de développement

12 UP est Itératif et incrémental Le développement dun logiciel nécessite quon 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

13 UP est piloté par les uses cases Pour servir les attentes des utilisateurs, On centre le processus de développement sur leurs besoins. On fait apparaître ces besoins à laide de la technique des cas dutilisation : en capturant les besoins fonctionnels dun système en capturant les besoins fonctionnels dun système en orientant le travail de chaque itération en orientant le travail de chaque itération vont guider le processus à travers lutilisation des différents modèles UML qui représentent le système.

14 Modèle du domaine Modèle de conception Modèle dimplé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 darchitecture Structurés par

15 UP est centré sur larchitecture larchitecture doit prévoir la réalisation de tous les uses case et doit évoluer avec eux. larchitecture doit prévoir la réalisation de tous les 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 dexécution La plateforme dexécution Matériel, système, BD, réseau,etc. Matériel, système, BD, réseau,etc. Les composants réutilisables Les composants réutilisables Librairies, caisse à outils, composants du commerce, etc. Librairies, caisse à outils, composants du commerce, etc. Les considérations de déploiement et les besoins non fonctionnels Les considérations de déploiement et les besoins non fonctionnels La performance, la fiabilité, la robustesse, etc. La performance, la fiabilité, la robustesse, etc.

16 UP est piloté par les risques Un risque est un événement redouté dont loccurrence est plus ou moins prévisible. Le pilotage par les risques cest: Analyser les risques potentiels au plus tôt Analyser les risques potentiels au plus tôt Hiérarchiser les risques Hiérarchiser les risques Associer un ensemble de uses case à chaque risque Associer un ensemble de uses case à chaque risque Déclencher les itérations selon la criticité des uses cases quelles regroupent Déclencher les itérations selon la criticité des uses cases quelles regroupent UP propose une gestion des risques. Ce qui constitue une avancée significative.

17 Les adaptations de UP UP est un processus générique de développement. Il doit être adaptée au contexte du projet, de léquipe et de lorganisation concernée. Il existe donc des adaptations dUP dont les plus connues sont: Le Rational Unified Process (RUP) Le Rational Unified Process (RUP) LeXtreme Programming (XP) LeXtreme Programming (XP) Le Two Tracks Unified Process (2TUP) Le Two Tracks Unified Process (2TUP)

18 Cycle en Y Two Track Unified Process

19 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 SIContraintesfonctionnelles Contraintestechniques

20 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.

21 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

22 Cycle en YContraintesfonctionnelles Contraintestechniques Branche fonctionnelle Branche technique Capture des besoins fonctionnels Capture des besoins techniques AnalyseConception générique Recette Conception préliminaire Codage et tests Conception détaillée prototype

23 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 Lanalyse Précise ce que lon va réaliser en termes métier Le résultat de lanalyse ne dépend daucune technologie particulière

24 Cycle en Y La 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 dintégration avec lexistant La conception générique Définit les composants nécessaires à lélaboration de larchitecture technique Construit le squelette du système et élimine les risques au niveau technique A pour objectif duniformiser et de réutiliser les mêmes mécanismes pour la plupart des systèmes Est indépendante des aspects fonctionnels

25 Cycle en Y La branche du milieu La conception préliminaire Intègre le modèle danalyse dans larchitecture 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é

26 Cycle en Y Les branches du «Y» produisent des modèles réutilisables La branche gauche capitalise la connaissance du métier de lentreprise: les fonctions du système dinformation 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

27 La connaissance dun langage de modélisation comme UML La mise en œuvre dun processus de développement adaptatif comme UP Ne disent pas ce que doit faire le système ni comment le modéliser ! Nous avons besoin de techniques pour le spécifier, lanalyser et le concevoir. La modélisation du système

28 Modélisation Techniques de spécification des besoins

29 Les cas dutilisation Les cas dutilisation 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 quil fera et non comment il le fera!

30 Un scénario est un chemin particulier pris lors de lexécution dun use case Nominal Nominal - cest le scénario typique de succès Alternatif Alternatif – il correspond aux traitements alternatifs possibles Déchec Déchec – il recensent les échecs dans le déroulement dune étape de scénario Les scénarios

31 Identification des uses cases Comment identifier les uses cases ? Les Processus Métier Élémentaires servent à atteindre le but dun utilisateur du système. Ils sont de niveau Objectif utilisateur et sont analogues aux cas dutilisation dun système. Recenser les PME, permet de découvrir lensemble des cas dutilisation dun système

32 Description des uses cases Seule la forme textuelle permet de décrire les cas dutilisation. UML nen propose aucune. Selon le niveau de précision, la rédaction dun cas dutilisation 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 lutilisateur les responsabilités du système

33 Use case: Résumé Le format résumé décrit brièvement, le comportement du cas dutilisation. Il ne mentionne que lactivité et les échecs les plus significatifs. On les élabore en étendant la liste des objectifs par acteur.

34 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 derreur Post conditions (garantie de succès et déchec) Variantes de données et de technologies Contraintes IHM Contraintes non fonctionnelles Questions en suspens

35 Modèle des cas dutilisation UML représente les cas dutilisation par le diagramme de cas dutilisation. On y montre les acteurs en relation avec les cas dutilisation. Ce qui donne une vision spatiale et dynamique du système

36 Exemple: consulter une commande

37 Titre Consulter commande Description Cette fonctionnalité permet à l'acteur ayant droit de consulter les commandes en cours ou archivés. Acteurs L'utilisateur Pré conditions L'acteur s'est authentifié sur le système. Il a choisit un contrat et un catalogue. Post conditions Les commandes sont consultées Déclencheurs L'acteur peut accéder à la consultation de commandes à partir du menu principal de la page d'accueil

38 Exemple: consulter une commande Description du traitement nominal 1. L'acteur sélectionne un client 2. l'acteur recherche une commande à partir d'un critère > 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 > Consulter le détail d'une commande. Complément d'exigences fonctionnelles faut-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.

39 Exemple: consulter une commande Description des exceptions Sans objet. Description des traitements alternatifs Sans Objet Contraintes IHM Les commandes sont affichées par des tranches de 20. Les commandes en cours sont affichées avant les commandes archivées. Contraintes non fonctionnelles accès en moins de 5 s au service.

40 Modélisation Techniques danalyse et conception

41 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 lexpé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) Cest un moyen de partager la connaissance de la résolution dun type de problème sous une forme « conceptuelle », mais ce nest pas une solution implémentée.

42 Pourquoi les patterns Tout dabord, 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 lexpérience Un niveau dabstraction plus élevé qui permet délaborer des constructions logicielles de meilleure qualité Une réduction de la complexité Un guide/catalogue de solutions, … mais nest pas sans inconvénients car cela nécessite Un effort de synthèse : reconnaître, abstraire… Un apprentissage à effectuer, une expérience.

43 Techniques danalyse Objectifs Analyser les besoins, cest 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.

44 Techniques danalyse Mode opératoire Pour chaque cas dutilisation, on déroule les étapes des scénarios que lon 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.

45 Techniques danalyse Identification des classes Pour identifier les classes conceptuelles, plusieurs techniques existent: lanalyse linguistique. les listes de catégories. les classes de spécifications. les types de données non primitifs. les patterns danalyse

46 Techniques danalyse Les attributs Un attribut est la valeur dune donnée logique dun 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

47 Techniques danalyse Les associations Une association est une relation significative entre des classes On distingue plusieurs sortes dassociations : Les associations multiples La généralisation/spécialisation Les classes dassociation Lagrégation Lassociation qualifiée Lassociation réflexive

48 Modélisation Réalisation des cas dutilisation

49 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

50 Réalisation des cas dutilisation Pour chaque cas dutilisation, on liste toutes les événements système que lon 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 daffectation des responsabilités dans un diagramme dinteraction

51 Réalisation des cas dutilisation Les diagrammes dinteractions 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 dinteraction 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

52 Réalisation des cas dutilisation 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 darticle à associer à la ligne article ? qui doit transmettre la quantité à la ligne article ?

53 Techniques de conception Lactivité de conception La spécification et lanalyse des besoins ont permis de définir quel système construire. Lactivité de conception, sintéresse à la façon de construire le système. Elle vise à construire une solution qui conforme aux besoins du système

54 Techniques de conception La conception orienté objet En conception, un système est vu comme une communauté dobjets qui collaborent entre eux. Ce mode de réflexion permet: didentifier les objets qui contribuent à la réalisation dun événement système. de définir les actions pour quils sacquittent de leurs responsabilités.

55 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 dun 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

56 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 danalyse de Jacobson : Les classes « boundary » jouent le rôle dintermédiaires entres les acteurs externes au système et le coeur du système. Il sagit des classes de présentations, dinterfaces avec dautres systèmes ou pilotes de périphériques. Généralement on retrouve au moins une classe « boundary » par paire (acteur, cas dutilisation). Les classes « entity » constituent labstraction du cas dutilisation et correspondent plus ou moins aux entités identifiées dans la phase danalyse 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, lenchaînement de tâches dans les systèmes.

57 Techniques de conception Quelques règles sont à respecter pour la mise en place de ces classes danalyse : Les acteurs ne peuvent interagir quavec les boundary Les boundary peuvent interagir avec les control ou exceptionnellement avec dautres boundary, mais jamais directement avec les entity Les control peuvent interagir avec les boundary, les entity ou dautres control Les entity ne peuvent interagir quentre elles. (les control peuvent manipuler des entity, mais pas linverse) Ces classes apparaîtront pendant la phase où on passe des diagrammes danalyse système aux premiers diagrammes de conception (éclatement des diagrammes de séquence ou de collaboration).

58 Architecture Larchitecture logicielle et technique

59 Architecture Larchitecture cest « lart de concevoir et de construire un bâtiment selon un esthétisme et des règles techniques déterminées. » Cette définition peut sappliquer à la fabrication du logiciel. A linstar dun 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.

60 Architecture Larchitecture dun système peut être vue selon deux angles principaux. La vue logique qui concerne lorganisation conceptuelle ou la structure du système. La vue de déploiement qui concerne lorganisation physique du système: Machines, OS, Réseaux, etc …

61 Architecture La vue logique ou larchitecture logicielle décrit: Lorganisation générale dun 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.

62 Architecture Larchitecture par couches On lapplique aux applications munies dune interface graphique et manipulant des données. Elle a pour but de séparer les différentes logiques dune application: La présentation. La logique applicative. Le domaine métier. Laccès aux des données.

63 Architecture (déploiement) La vue par niveau ou Tiers donne la vision physique dun système. Elle distribue les couches logiques dun 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.

64 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 dautres systèmes Terminaux passifs Gros système

65 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 composantesclientsSGBDR

66 Architecture 3/3 Caracté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 clientsServeurdapplicationRessources

67 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.).


Télécharger ppt "Processus unifié: Modèle En Y Mustapha EL FEDDI"

Présentations similaires


Annonces Google