Mustapha EL FEDDI mustapha.elfeddi@sofrecom.com Démarche & méthode Mustapha EL FEDDI mustapha.elfeddi@sofrecom.com

Plan du cours L’analyse système La conception L’architecture logicielle

Reformulation des besoins Modélisation objet L’analyse système Reformulation des besoins Modélisation objet

Reformulation des besoins L’analyse système Reformulation des besoins

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

Production d’un 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 c’est le cas. Cette rubrique est donc optionnelle.

Identification des acteurs et des cas d'utilisation Action Objectif 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

Analyse d’un cas d'utilisation Action Objectif 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 d’un 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 d’informations mis en oeuvre lors de l'exécution d’un 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

Analyse d’un cas d'utilisation: Description textuelle d'un cas d'utilisation Clause Description Identifiant Contient un nom qui identifie de manière non ambiguë le cas d'utilisation dans le modèle d’analyse 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 d’utilisation, 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 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 d’informations, 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

Analyse d’un cas d'utilisation: Description textuelle d'un scénario Clause Description Identifiant Contient un nom qui identifie de manière non ambiguë le scénario dans le modèle d’analyse 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 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 d’informations 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

Analyse d’un cas d'utilisation: Représentation dynamique La représentation dynamique d’un cas d'utilisation exprime de manière plus formelle le contenu de sa description (clause Description). En effet, la description textuelle d’un cas d'utilisation fait apparaître le cas nominal, les scénarios d’alternatives et les cas d’exception 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 à l’aide du diagramme d’activités.

Structuration du modèle des cas d'utilisation Action Objectif 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 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 d’acteurs 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

Description des besoins non fonctionnels Cette activité produit une description textuelle des besoins non fonctionnels, qu’ils 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é d’utilisation, Fiabilité, Performances, Contraintes de développement et de mise en production, Contraintes d’interfaç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 d’interactions utilisateur/système, etc.), Contraintes d’implémentation (standards, langages, politique d’intégrité de base de données, limite de ressources, environnement d’exécution, lignes directrices, etc.)

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

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)

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 l’environnement 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 d’informations 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 d’utilisation et des scénarios doit être simple, précis et compréhensible des correspondants Maîtrise d’Ouvrage 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 d’un cas d'utilisation doivent être dissociées.

Analyse système Modélisation objet

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

Description d’un cas d'utilisation Action Objectif 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

Structuration du modèle du système Action Objectif Définir les catégories d’entité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 d’entités Définir les dépendances des catégories de cas d'utilisation vis à vis des catégories d’entité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 d’impact en mettant en relief un élément du modèle

Description d’une classe Action Objectif Définir l’entité et ses responsabilités Décrire le concept représenté par l’entité, et les responsabilités de l’entité (ce qu'elle sait faire ou interpréter) afin de mieux cerner son rôle dans le système Décrire les attributs de l’entité Décrire précisément chaque attribut au niveau analyse de l’entité: son rôle, son type, etc. Décrire le cycle de vie de l’entité Lorsque l’entité a un cycle de vie significatif, décrire les principaux états de l’entité 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

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

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 d’entités est cohérent, à savoir : Pas de dépendance circulaire entre catégories, Pas d’entité 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 d’utilisation et d’entités sont cohérentes : une catégorie de cas d’utilisation peut dépendre d’une ou plusieurs catégories d’entité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 d’utilisation dans la vue dynamique sont cohérentes avec les relations entre cas d’utilisation exprimées dans le modèle de cas d’utilisation.

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 d’interactions sont lisibles. Vérifier que toutes les associations du modèle statique sont utilisées dans le sous ensemble du modèle dynamique concernant l’une des entités participant à l’association. 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 qu’elle n’est pas : Redondante : elle exprime le même concept qu’une autre entité, Floue : sa sémantique n’est pas clairement définie, Abusive : elle correspond en fait à un attribut, Au mauvais niveau : classe relevant d’un choix de conception.

Vérification du modèle du système (suite) Vérifier que tout attribut est justifié, c’est-à-dire qu’il ne représente pas un concept mais bien une propriété que l’on 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 d’une entité est un automate déterministe. Vérifier que le cycle de vie d’une entité soit lisible. Vérifier que chaque élément du modèle statique du système est commenté.

Exemple: consulter une 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. 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

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

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.

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 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 conception Quelques 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).

L’architecture logicielle et technique

Architecture L’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.

Architecture L’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 …

Architecture La 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 La présentation. 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 passifs Gros 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 clients SGBDR

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 clients Serveur d’application Ressources

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