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

Démarche & méthode Mustapha EL FEDDI

Présentations similaires


Présentation au sujet: "Démarche & méthode Mustapha EL FEDDI"— Transcription de la présentation:

1 Démarche & méthode Mustapha EL FEDDI

2 Plan du cours Lanalyse système La conception Larchitecture logicielle

3 Lanalyse système Reformulation des besoins Modélisation objet

4 Lanalyse système Reformulation des besoins

5 La reformulation des besoins consiste à itérer sur sept activités principales : Production dun glossaire système Identification des acteurs et des cas d'utilisation Analyse dun cas d'utilisation Structuration du modèle des cas d'utilisation Description des besoins non fonctionnels Maquettage de linterface utilisateur Vérification du modèle des besoins

6 Production dun glossaire système Cette activité consiste à déterminer le vocabulaire système pour les termes spécifiques ou sujets à une mauvaise interprétation. Chaque entrée du glossaire comporte un nom de terme, sa définition (un texte) et un type. Le type est le nom du concept sous lequel est classifié le terme si cest le cas. Cette rubrique est donc optionnelle.

7 Identification des acteurs et des cas d'utilisation ActionObjectif Identifier les acteurs Identifier les acteurs en interaction avec le système. Ces acteurs peuvent représenter des systèmes fournisseurs de services, ou des systèmes utilisateurs de services Définir le contexte du système Représenter le système dans son environnement (interactions avec les acteurs selon des points de vue statique, dynamique et fonctionnel), afin de définir sans ambiguïté les frontières du système Identifier les cas d'utilisation du Système Identifier les fonctionnalités confiées au système, sous forme de cas d'utilisation. Ces fonctionnalités peuvent utiliser des services existants ou prévus. Elles peuvent aussi représenter ce que le système doit offrir ultérieurement, sous forme d'un ou de plusieurs services Décrire textuellement les acteurs Décrire, sous forme de texte, chaque acteur en interaction avec le système

8 Analyse dun cas d'utilisation ActionObjectif Décrire textuellement un cas d'utilisation Décrire précisément un cas d'utilisation, en langage naturel, selon un modèle structuré comportant des clauses et en apportant des informations sur son comportement dynamique. Décrire textuellement un scénario Décrire de façon détaillée en langage naturel, et selon un modèle structuré comportant des clauses, le déroulement dun scénario représentatif du cas d'utilisation concerné Décrire la dynamique d'un cas d'utilisation Modéliser l'enchaînement des tâches et des flots dévénements et dinformations mis en oeuvre lors de l'exécution dun cas d'utilisation Identifier les règles de gestion Identifier et définir précisément les règles de gestion qui doivent être satisfaites lors du déroulement du cas d'utilisation. Une règle de gestion est une propriété (portant dans ce cas sur le déclenchement des tâches du cas d'utilisation) qui relève du métier et qui doit toujours être vérifiée

9 Analyse dun cas d'utilisation: Description textuelle d'un cas d'utilisation ClauseDescription Identifiant Contient un nom qui identifie de manière non ambiguë le cas d'utilisation dans le modèle danalyse Résumé est une description succincte en quelques lignes qui résume l'objectif du cas d'utilisation Acteurs contient une énumération des identifiants des acteurs qui interagissent avec le système Contexte de déclenchement décrit lévénement déclencheur du cas dutilisation, qui peut être un stimulus émis par un acteur, un événement conditionnel ou un événement temporel Pré conditions contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités manipulées par le système et son environnement pour pouvoir déclencher le cas d'utilisation Description doit indiquer, dans le texte qui la constitue, le séquencement des tâches du cas d'utilisation, les services utilisés, les entités manipulées, sous forme de concepts et dinformations, et les conditions de déclenchement des exceptions Post conditions contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités manipulées par le système et son environnement à la fin de l'exécution du cas d'utilisation Exceptions est un texte qui décrit, pour chaque exception citée dans la clause Description, le traitement (local, ou délégué à un autre cas d'utilisation) de cette exception Contraintes non fonctionnelles est un texte décrivant les contraintes non fonctionnelles spécifiques au cas d'utilisation

10 Analyse dun cas d'utilisation: Description textuelle d'un scénario ClauseDescription Identifiant Contient un nom qui identifie de manière non ambiguë le scénario dans le modèle danalyse Résumé est une description succincte en quelques lignes qui résume l'objectif du scénario Acteurs contient une énumération des identifiants des acteurs qui interagissent avec le système dans le cadre du scénario Contexte de déclenchement décrit lévénement déclencheur du scénario, qui peut être un stimulus émis par un acteur, un événement conditionnel ou un événement temporel Pré conditions contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités manipulées par le système et son environnement pour pouvoir déclencher le scénario Description doit indiquer, dans le texte qui la constitue, le séquencement des tâches du scénario, les services utilisés, les entités manipulées, sous forme de concepts et dinformations Post conditions contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités manipulées par le système et son environnement à la fin de l'exécution du scénario

11 Analyse dun cas d'utilisation: Représentation dynamique La représentation dynamique dun cas d'utilisation exprime de manière plus formelle le contenu de sa description (clause Description). En effet, la description textuelle dun cas d'utilisation fait apparaître le cas nominal, les scénarios dalternatives et les cas dexception du comportement du cas d'utilisation. Si le nombre de scénarios est important ou le cas d'utilisation complexe à décrire, il est donc intéressant de compléter cette description textuelle par une modélisation de la cinématique des tâches qui composent le cas d'utilisation. Par rapport à la description textuelle du cas d'utilisation et au modèle de cas d'utilisation, la représentation dynamique comporte les informations suivantes, formalisées : L'ordre de séquencement des tâches (qui peuvent correspondre à des appels de services) qui composent le cas d'utilisation ainsi que les parallélisations possibles ; Des indications sur les entités produites et/ou utilisées et sur leur état ; Les acteurs interagissant avec le système ; Les événements reçus et produits par le cas d'utilisation. En UML, la représentation de ces informations est possible à laide du diagramme dactivités.

12 Structuration du modèle des cas d'utilisation ActionObjectif Identifier des fonctionnalités partagées entre cas d'utilisation Distinguer, en identifiant de nouveaux cas d'utilisation, les comportements communs à plusieurs cas d'utilisation, et donc réutilisables Identifier des fonctionnalités optionnelles pour un cas d'utilisation Distinguer, en identifiant de nouveaux cas d'utilisation, les comportements optionnels pour un cas d'utilisation Identifier des cas d'utilisation génériques Identification de cas d'utilisation généralisant d'autres cas d'utilisation Structurer le modèle des acteurs Faire apparaître déventuelles généralisations dacteurs Définir les catégories de cas d'utilisation et leurs dépendances Partitionner le modèle de cas d'utilisation en les regroupant en catégories, et en identifiant les dépendances entre ces catégories

13 Description des besoins non fonctionnels Cette activité produit une description textuelle des besoins non fonctionnels, quils soient spécifiques à un cas d'utilisation ou non Les besoins non fonctionnels décrivent des caractéristiques du système ou de son environnement : Facilité dutilisation, Fiabilité, Performances, Contraintes de développement et de mise en production, Contraintes dinterfaçage avec des systèmes physiques ou informatiques externes, Contraintes de conception (fonctionnement multi-utilisateurs, volumétrie des données, fréquence de déroulement des séquences dinteractions utilisateur/système, etc.), Contraintes dimplémentation (standards, langages, politique dintégrité de base de données, limite de ressources, environnement dexécution, lignes directrices, etc.)

14 Maquettage de linterface utilisateur Cette activité produit les maquettes dinterface utilisateur, sous forme papier ou exécutable. Ce maquettage est itératif jusqu'à la stabilisation des exigences de la MOA et des utilisateurs.

15 Vérification du modèle des besoins Cette activité vérifie le modèle des besoins à chaque incrément de la reformulation des besoins. Elle ne comporte pas d'actions particulières. Elle utilise tous les produits du travail qui sont le résultat de la reformulation des besoins, mais ne les modifie pas et n'en crée pas de nouveaux (la correction éventuelle d'un produit du travail est du ressort de l'activité qui l'a produit)

16 Vérification du modèle des besoins (suite) Les règles suivantes doivent être vérifiées lors de cette activité : Chaque acteur identifié doit être réellement externe au système. Tous les acteurs identifiés doivent être facilement compréhensibles des différents intervenants du projet. Il doit exister au moins un diagramme de contexte pour représenter lenvironnement du système. Tous les acteurs identifiés doivent apparaître sur au moins un diagramme de contexte. Si différents types de diagrammes de contexte sont utilisés pour représenter le système dans son environnement, ils doivent être cohérents. Chaque acteur doit être émetteur ou récepteur dévénements ou dinformations par rapport au système. Tous les acteurs identifiés doivent communiquer avec au moins un cas d'utilisation. Le modèle de description textuelle de cas d'utilisation doit être respecté. Les clauses obligatoires doivent être renseignées. Le vocabulaire employé dans les descriptions textuelles des cas dutilisation et des scénarios doit être simple, précis et compréhensible des correspondants Maîtrise dOuvrage et des utilisateurs qui les liront et les valideront. Le déclenchement et la terminaison de chaque cas d'utilisation doivent être précisés. Pour chaque scénario réalisé pour une condition, le scénario correspondant à la négation de la condition doit être décrit. Toutes les relations entre cas d'utilisation doivent être justifiées. Les fonctionnalités communes à plusieurs cas d'utilisation doivent être factorisées. Les fonctionnalités optionnelles dun cas d'utilisation doivent être dissociées.

17 Analyse système Modélisation objet

18 La macro-activité Modélisation objet du système consiste à itérer sur cinq activités principales: Description dun cas d'utilisation Structuration du modèle du système Description dune classe Description dune association Vérification du modèle du système

19 Description dun cas d'utilisation ActionObjectif Identifier les entités participant à un cas d'utilisation Identifier les entités participant au déroulement du cas d'utilisation, leurs associations et attributs concernés. Certaines de ces entités peuvent correspondent à des concepts spécialisés déjà identifiés Modéliser les scénarios d'un cas d'utilisation Préciser au moyen de diagrammes d'interaction la description textuelle des scénarios représentatifs, en faisant ainsi apparaître les interactions entre objets (acteurs, entités, cas d'utilisation inclus) participant au cas d'utilisation. Une interaction peut correspondre à un appel de service émis vers un système externe

20 Structuration du modèle du système ActionObjectif Définir les catégories dentités et leurs dépendances Partitionner le modèle objet des entités en regroupant les entités en catégories, et représenter leurs Dépendances Définir les dépendances entre catégories de cas d'utilisation et dentités Définir les dépendances des catégories de cas d'utilisation vis à vis des catégories dentités Construire des vues Cas d'utilisation, Entité ou Acteur Réaliser des vues partielles du modèle objet, centrées soit sur les classes de type Cas Utilisation, soit sur les classes de type Entité, soit sur les classes de type Acteur, afin de pouvoir faire des analyses dimpact en mettant en relief un élément du modèle

21 Description dune classe ActionObjectif Définir lentité et ses responsabilités Décrire le concept représenté par lentité, et les responsabilités de lentité (ce qu'elle sait faire ou interpréter) afin de mieux cerner son rôle dans le système Décrire les attributs de lentité Décrire précisément chaque attribut au niveau analyse de lentité: son rôle, son type, etc. Décrire le cycle de vie de lentité Lorsque lentité a un cycle de vie significatif, décrire les principaux états de lentité et les transitions possibles entre ces états Identifier les règles de gestion Identifier les règles de gestion qui s'appliquent à l'entité, et donner à ces règles de gestion une définition précise. Une règle de gestion est une propriété (portant dans ce cas sur l'entité, ses attributs, ses états) qui relève du métier et qui doit toujours être vérifiée

22 Description dune association Cette activité enrichit le modèle statique du système. Cette activité ne se décompose pas en actions particulières

23 Vérification du modèle du système Les règles suivantes doivent être vérifiées lors de cette activité : « Jouer » les scénarios sur le modèle statique afin de vérifier que toutes les entités, les relations et tous les attributs nécessaires à un scénario sont présents dans le modèle statique. Vérifier que chaque événement possède un objet émetteur et un objet récepteur qui peuvent être le même objet. Vérifier que tous les attributs d'une entité sont référencés au moins une fois dans le modèle dynamique (référencés par des conditions gardées, manipulés dans des actions ou activités,….) Vérifier que le partitionnement du modèle objet du système en catégories dentités est cohérent, à savoir : Pas de dépendance circulaire entre catégories, Pas dentité isolée dans une catégorie, Les entités liées par une composition doivent appartenir à la même catégorie. Vérifier que les dépendances entre catégories de cas dutilisation et dentités sont cohérentes : une catégorie de cas dutilisation peut dépendre dune ou plusieurs catégories dentités, mais une catégorie d'entités ne peut pas dépendre d'une catégorie de cas d'utilisation. Vérifier que les interactions entre scénarios de cas dutilisation dans la vue dynamique sont cohérentes avec les relations entre cas dutilisation exprimées dans le modèle de cas dutilisation.

24 Vérification du modèle du système (suite) Vérifier la cohérence entre les responsabilités des entités décrites au niveau de chaque entité et leur mise en oeuvre effective dans les diagrammes de la vue dynamique. Vérifier que les diagrammes dinteractions sont lisibles. Vérifier que toutes les associations du modèle statique sont utilisées dans le sous ensemble du modèle dynamique concernant lune des entités participant à lassociation. Vérifier que toutes les relations de composition entre entités sont justifiées, c-à-d pour les classes les représentant : La classe composant est réellement une «partie» de la classe composée. Le cycle de vie de la classe composant doit être lié à celui de la classe composée. Vérifier que toute entité est justifiée, c-à-d quelle nest pas : Redondante : elle exprime le même concept quune autre entité, Floue : sa sémantique nest pas clairement définie, Abusive : elle correspond en fait à un attribut, Au mauvais niveau : classe relevant dun choix de conception.

25 Vérification du modèle du système (suite) Vérifier que tout attribut est justifié, cest-à-dire quil ne représente pas un concept mais bien une propriété que lon peut valoriser. Vérifier que toute entité ayant un comportement dynamique significatif dans le fonctionnement du système présente une description de son cycle de vie. Vérifier que tous les événements concernant une entité apparaissent dans le diagramme montrant son cycle de vie. Vérifier que chaque diagramme représentant le cycle de vie dune entité est un automate déterministe. Vérifier que le cycle de vie dune entité soit lisible. Vérifier que chaque élément du modèle statique du système est commenté.

26 Exemple: consulter une commande

27 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

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

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

30 Conception Techniques danalyse et conception

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

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

33 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

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

35 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

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

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

38 Architecture Larchitecture logicielle et technique

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

40 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 …

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

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

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

44 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

45 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

46 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

47 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 "Démarche & méthode Mustapha EL FEDDI"

Présentations similaires


Annonces Google