Une manière d’ordonnancer les différents modèles entre eux.

 

 

 

 

 

Objectif global d’une démarche d’analyse et de conception objet

 

 

L’intérêt de cette démarche est d’analyser et de concevoir un système d’information pour aboutir à une application objet. L’objectif est d’avoir une application qui puisse vivre (évolution de l’application dans le temps), et qui enrichisse la base de savoir-faire de l’entreprise (développement de nouveaux applicatifs en s’appuyant sur des objets métiers déjà développés). La réutilisabilité est un des soucis principaux pour pouvoir réduire le coût des logiciels et augmenter la puissance de développement des programmeurs dans leurs soucis d’ajuster le mieux possible le système d’information à l’application informatique.

 

Nous nous appuierons sur le workflow, c'est-à-dire les règles des processus métier de l’entité pour débusquer les uses cases, les acteurs. Dans l’analyse et la conception objet nous cherchons à construire une architecture en couche de la forme suivante :

 

Couche I.H.M. (Interface Homme Machine)	Présentation
Couche application (workflow)	Application
Couche objets métiers	Métier
Couche accès aux données (de services)	Accès aux données
Couche base de données	Base de données

 

Nous verrons que chaque couche définira un ou des contrôleurs pour la rendre indépendante des autres.

 

Des études montrent que dans certaines entreprises les règles de métiers pouvaient changer assez régulièrement. Il est donc facile alors de comprendre les raisons du découplage des objets métiers. Les objets ont tendance à être stables dans le temps, par contre les IHM et base de données peuvent également être changées sans que l’on touche au métier ni aux règles de l’entreprise.

 

Cette architecture ne s’appliquera pas à toutes les applications, elle est à prendre comme un exemple complet.

 

 

Les étapes de la démarche

 

Ce chapitre est un résumé du processus de développement d’une application. Il est difficile de comprendre ce résumé, sans avoir lu en détail et expérimenté chacun des chapitres auquel il fait référence. Par contre, il est conseillé de revenir souvent à ce résumé (textuel et graphique) pour bien se situer dans la démarche, avant l’étude de tout nouveau chapitre.

 

·        Lister l’ensemble des exigences du client issues du cahier des charges, ou issu d’une démarche préalable de collecte d’information (documents électroniques, notes de réunions, notes d’interviews…). Chaque exigence sera numérotée et ainsi pourra être tracée.

·        Deux solutions possibles :

o   Nous allons regrouper les exigences par intentions d’acteur complètes puis nous allons faire un diagramme de contexte (nous nous appuierons sur un diagramme de collaboration pour cela).

o   Si toutes les règles de processus métier sont définies, nous réaliserons un diagramme d’activité en colonnes (« swim lane ») où les colonnes sont les acteurs. Cela permet de dégager les responsabilités de chaque acteur, et ainsi de connaître les intentions des acteurs.

·        Définir les uses cases et construire le diagramme de uses cases.

·        Faire la description de haut niveau de chaque use case : chercher des scénarios de base.

·        Faire la description détaillée de chaque use case : donner les séquences nominales puis les séquences alternatives (Erreurs et exceptions, en limitant au maximum les exceptions). Cette description peut-être complétée par un diagramme d’activité qui montre le séquencement des différents scénarios.

Cette description détaillée comprend les scénarios, les pré-conditions, à partir de quoi se déroule le use case, comment se termine le use case, et enfin les post-conditions (règles métier assurée quand le use case est terminé).

·        Faire un diagramme de séquence par scénario (ici c’est un diagramme de séquence boîte noire, où la boîte noire correspond au système informatique à développer).

·        Faire un diagramme de classe par use case. Le diagramme de classe final sera la superposition de ces diagrammes de classe.

Les classes obtenues sont des classes du monde réel, nous ne mettons pas les opérations car nous ne connaissons pas l’intérieur du système informatique.

·        Un contrat est réalisé pour chaque opération du système. Ce contrat contient un nom, des responsabilités, les exigences auxquelles répond notre itération de cycle de vie, les pré-conditions, et les post-conditions (décrites sous la forme « has been ») et enfin les exceptions.

Ce contrat peut-être réalisé sous forme textuelle, ou plus souvent sous forme d’un diagramme de séquence boîte blanche où les objets échangent des messages pour rendre le service demandé.

·        A partir des diagrammes de classe et des contrats nous réaliserons les diagrammes de collaboration qui montrent comment les objets collaborent pour rendre le service demandé. Nous appliquerons les patterns de conception pour cela (GRASP Patterns).

·        En parallèle, nous réaliserons les diagrammes d’état des objets les plus complexes, ainsi nous détecterons des méthodes internes à ces objets.

·        Nous réaliserons enfin, le diagramme de classe de conception, en tenant compte à nouveau des GRASP Patterns. Ceci peut remettre en cause le diagramme de classe précédemment établi.

L’analyse

 

Après une première ébauche des besoins des clients, il va falloir approfondir ses besoins, examiner les différents scénarios des uses cases (éventuellement avec un diagramme d’activité pour exprimer ces différents scénarios), tenir compte des traitements exceptionnels et des cas d’erreur. Il va être nécessaire de regarder le séquencement des opérations d’un point de vue fonctionnel, pour voir comment les différents acteurs interagissent avec le logiciel, à l’aide des diagrammes de séquence boîte noire (la boîte noire, c’est le système informatique à développer). Il est alors nécessaire de distinguer les différents objets qui collaborent dans notre système informatique (avec un diagramme de classe). Enfin, nous allons détailler le rôle des opérations en définissant des contrats d’opérations (soit sous forme textuelle, soit sous forme de diagramme de séquence). Nous aurons alors tous les éléments pour passer à la conception.

 

Nous n’avons ici comme souci que de détailler les besoins du client pour s’en imprégner, afin de pouvoir le formaliser et le préciser.

 

Cinquième étape : Use case description de bas niveau

 

La description détaillée d’un use case permet de bien décrire les enchaînements des services rendus par le logiciel pour un usage précis. N’oublions pas que nous restons au niveau essentiel, c'est-à-dire que nous ne donnerons pas de solution au problème, nous ne faisons que préciser sa description. Nous sommes toujours dans l’espace du problème, pas dans celui de la solution.

 

Une description détaillée de use case comprend :

·        Nom de Use Case :

·        Acteur principal :

·        Acteurs secondaires :

·        Evénement déclencheur du Use Case :

·        Rôle du Use Case :

·        Terminaison du Use Case :

·        Les références croisées des exigences :

·        Les pré-conditions nécessaires au fonctionnement du use case :

·        Description complète du use case, avec les différents scénarios : Cette description intègre les cas d’erreur (traités par le use case) et les exceptions (forçant la sortie du use case).

·        Contraintes d’IHM (optionnel) : Attention de ne pas décrire l’interface ici, mais bien de préciser des éléments à prendre en compte lors de la réalisation des interfaces.

·        Contraintes non fonctionnelles (optionnel) : Ici nous prendrons en compte les dimensionnements, les performances attendues,… Ceci permettra de mieux évaluer les contraintes techniques.

 

La description complète du use case donne la priorité aux choses que les acteurs perçoivent. Nous décrivons les actions des acteurs en commençant par l’acteur principal qui initie le use case, puis nous donnerons les réponses du système (vu comme une boîte noire). Les cas d’erreur (avec correction et reprise) et les exceptions (avec abandon du use case) sont traités ensuite.

 

Le formalisme est textuel et prend la forme suivante :

 

Actions des acteurs 1.    L’acteur principal fait… 3.  L’acteur principal calcule… 4.  L’acteur secondaire traite…

Réponses du système 2.     Le système lui envoie…   5.  Le système envoie le compte rendu

 

Traitement des cas d’erreur et d’exception :

A l’étape 2 si le code de … alors le système renvoie un message et l’acteur principal refait…

A l’étape 4 si… alors le système affiche … et le use case s’arrête.

 

En premier lieu nous voyons les échanges entre le système et les acteurs, ainsi que la chronologie et l’enchaînement des actions, dans le cas nominal.

Dans un deuxième temps, nous listons les cas d’erreur (avec traitement de récupération) et les traitements d’exception avec arrêt du use case.

Nous restons bien fonctionnel car nous ne décrivons pas comment est réalisé le système, mais comment sont réalisés les services qu’il rend.

 

Notion de scénario : un use case est un regroupement d’actions plus élémentaires qui permet de traiter une intention d’acteur assez générale. Un scénario est une réalisation du use case donc une « intention élémentaire ». Par exemple, pour une gestion de compte client dans une banque, nous avons un use case gérer les comptes. Nous avons plusieurs scénarios : créer un compte, consulter un compte, modifier un compte…

Pour chacun des scénarios il va falloir faire une description détaillée de use case (avec traitement d’erreur et d’exception pour chacun). Un diagramme d’activité va permettre de montrer l’ensemble d’un use case, en regroupant l’ensemble des scénarios de ce use case.

 

Exemple de description d’un use case (effectuer un achat) :

·        Nom de Use Case :                                                                     Effectuer un achat

·        Acteur principal :                                                                        Client

·        Acteurs secondaires :                                                                 Caissier

·        Evénement déclencheur du Use Case :                                  Un client arrive à la caisse avec ses achats.

·        Rôle du Use Case :                                                                     Le caissier passe tous les articles, fait

la note et encaisse le paiement.

·        Terminaison du Use Case :                                                       Le client a payé et pris ses articles.

·        Les références croisées des exigences :                                R2,R3,R4,R6,R7,R15

·        Les pré-conditions nécessaires au fonctionnement du use case :  La caisse est allumée et initialisée. Un caissier est connecté à la caisse.

·        Description complète du use case, avec les différents scénarios :

 

Ici il n’y a qu’un scénario possible. Nous verrons dans l’exemple suivant un use case avec plusieurs scénarios pour mettre en évidence le diagramme d’activité. Car les différentes exigences se suivent et ne se distinguent pas l’une de l’autre.