2tup Spec Dev1

le :02/09/03 Projet : Plan Assurance Qualit Projet : Document : VERSION Objet Plan Assurance Qualit 2UP_SPEC_DEV1 1.
00 Ce document a pour objectif de dfinir la dmarche danalyse et de conception objet ainsi les activits lies.
Auteur Eric PAPET
Vrifi par: Dominique MASSON
Valid par: Socit: Fonction: Date: Signature
Guillaume FOURQUET IEP Grant, ingnieur informaticien
Liste de diffusion
Rfrence :C:\projets\dev1-0\paq\2TUP_SPEC_DEV1.doc Page 1 sur 14 DEV1.0 - Technopole Izarbel - 64210 BIDART SARL au Capital de 8000 - SIRET 432 897 056 00011 - APE 722Z e.papet@dev1-0.com
le :02/09/03 Projet : Plan Assurance Qualit
Gestion des modifications apportes au document

Auteur Date Modification Eric PAPET 12/12/2000 Descriptions Cration Version document 1.00
SOMMAIRE
GESTION DES MODIFICATIONS APPORTES AU DOCUMENT ........................................................... 2 SOMMAIRE.......................................................................................................................................................... 3 INTRODUCTION................................................................................................................................................. 4 LES NIVEAUX DABSTRACTION : ......................................................................................................................... 4 Le niveau contexte (activit de conceptualisation) ...................................................................................... 4 Le niveau domaine et application ............................................................................................................... 5 Le niveau implmentation ............................................................................................................................ 5 LA DEMARCHE .................................................................................................................................................. 6 1. ETUDE PRLIMINAIRE ................................................................................................................................ 6 1.1 Elaboration du cahier des charges ...................................................................................................... 6 1.2 Identifier les acteurs ................................................................................................................................ 6 1.3 Identifier les messages............................................................................................................................. 6 1.4 Modliser le contexte............................................................................................................................... 6 CAPTURE DES BESOINS FONCTIONNELS...................................................................................................... 7 2.1 Identifier les cas dutilisation .................................................................................................................. 7 2.2 Dcrire les cas dutilisation .................................................................................................................... 8 2.3 Organiser les cas dutilisation ................................................................................................................ 9 2.4 Identifier les classes candidates........................................................................................................... 9 2.5 Valider et consolider.......................................................................................................................... 10 CAPTURE DES BESOINS TECHNIQUES........................................................................................................ 11 3.1 Spcification technique du point de vue matriel .................................................................................. 11 3.2 Spcification darchitecture et influence sur le modle de dploiement................................................ 11 3.3 Elaboration du modle de spcification logicielle................................................................................. 11 3.4 Organisation du modle de spcification logicielle............................................................................... 11 3.5 Dveloppement des couches logicielles................................................................................................. 11 3.6 Dfinition des concepts techniques........................................................................................................ 11 3.7 Description des cas dutilisation technique........................................................................................... 11 DCOUPAGES EN CATGORIE ................................................................................................................... 12 4.1 Dcoupage en catgories....................................................................................................................... 12 DCOUPAGE EN INCRMENTS .................................................................................................................. 12 DVELOPPEMENT DU MODLE STATIQUE ( ANALYSE OBJET MTIER )...................................................... 13 6.1 Affiner les classes .................................................................................................................................. 13 6.2 Affiner les associations.......................................................................................................................... 13 6.3 Ajouter les attributs ............................................................................................................................... 13 6.4 Ajouter les oprations............................................................................................................................ 13 DVELOPPEMENT DU MODLE DYNAMIQUE ( ANALYSE OBJET MTIER ).................................................. 13 7.1 Modlisation des cycles de vie des entits importantes ......................................................................... 13 7.2 Diagramme de squence dappel entre les classes................................................................................ 13
2.
3.
4. 5. 6.
7.
CONCLUSION ................................................................................................................................................... 14
INTRODUCTION Les Niveaux dabstraction :

Le niveau contexte (activit de conceptualisation) Correspond une vision bote noire du systme, lexception de lbauche du modle objet que reprsente les diagrammes dobjets participants. Comprendre le besoin du client : Complter, reformuler les besoins Dterminer la frontire du systme Prparer lAnalyse Trouver les principales classes Dcouper en catgorie ; Estimer les cots et les dlais ;
Entres : cahiers des charges ( analyse textuelle du cahiers des charges) Sorties : Dossiers dexpression des besoins ( tude prliminaire) Documents dexpression des besoins client.. Diagramme de contexte, ensemble des Uses Cases Modle dobjet initial ( objets participants) Dictionnaire de donnes ( permet de stocker des complments textuels importants qui apportent des informations que les graphiques ne peuvent supporter.) Objectif : ( Comprendre ce que veut le client, premire dcoupe en package pour estimer des cots et des dlais) Description des acteurs Diagrammes de contexte Uses Cases : Diagrammes de Uses Cases Description textuelle Diagrammes de dObjets participant
Le niveau domaine et application Permet de spcifier graduellement les caractristiques des classes danalyse (activit analyse objet). Entres : Dossiers dexpression des besoins Documents dexpression des besoins client.. Diagramme de contexte, ensemble des Uses Cases Modle dobjet initial Dictionnaire des donnes* Sorties : Dossiers de spcification Diagrammes de classes Diagrammes dynamiques Dictionnaire complt Objectif : Spcification graduelle des classes danalyse Dcoupage en catgorie Diagrammes de classe. Le niveau implmentation Correspond au modle de conception complet, et comprend toutes les classes techniques. Cest la solution dimplmentation, qui sera ralise.
LA DEMARCHE 1. Etude prliminaire

Etude prliminaire ou (pr-tude) est la toute premire tape de notre processus de dveloppement. Elle survient la suite dune dcision de dmarrage de projet , et consiste effectuer un premier reprage des besoins fonctionnels et oprationnels, en considrant le systme comme une boite noire, afin dtudier sa place dans le systme mtier plus global de lentreprise. Aprs avoir identifi les acteurs qui interagirons avec le systme, il sera dvelopp un premier modle UML de niveau contexte, pour pouvoir tablir prcisment les frontires fonctionnelles du systme. 1.1 Elaboration du cahier des charges Cette activit se est de la responsabilit de la matrise douvrage. 1.2 Identifier les acteurs Un acteur reprsente labstraction dun rle jou par des entits externes (utilisateur, dispositif matriel ou autre systme) qui interagissent directement avec le systme tudi. 1.3 Identifier les messages Un message reprsente la spcification dune communication entre objets qui transporte de linformation avec intention de dclencher une activit chez le rcepteur. La rception dun message est normalement considre comme un vnement. Cette notion de message est utilis pour dcrire les interactions de plus haut niveau entre les acteurs et le systme. 1.4 Modliser le contexte Tous les messages ( systme <-> acteurs) identifis prcdemment peuvent tre reprsents de faon synthtique sur un diagramme de contexte dynamique. On utilise un diagramme de collaboration UML. Le systme utilis est reprsent par un objet central. Cet objet central est entour par dautre objets symbolisant les diffrent acteurs ; Des liens relient le systme chacun des acteurs. Sur chaque lien sont montrs les messages en entre et en sortie du systme, sans numrotation.
2. Capture des besoins fonctionnels

La technique des cas dutilisation complte la capture des besoins fonctionnels de ltude prliminaire en dcrivant les diffrentes faon quauront les acteurs dutiliser le systme. La capture des besoins fonctionnels est la premire tape de la branche gauche du cycle en Y. Elle formalise et dtaille ce qui a t bauch au cours de ltude prliminaire. Les lments mis en jeu : Messages, acteurs, modle de contexte dynamique. Acteurs principal, acteur secondaire. Cas dutilisation. Fiche de description textuelle dun cas dutilisation. Scnario, enchanement, diagramme dactivits. Inclusion, extension et gnralisation de cas dutilisation. Package de cas dutilisation. Classes candidates, responsabilits, diagrammes de classes participantes. Traabilit des cas dutilisation avec les besoins fonctionnels. 2.1 Identifier les cas dutilisation Quest ce quun cas dutilisation ? Un cas dutilisation modlise un service rendu par le systme. Il exprime les interaction acteurs / systme et apporte une valeur ajoute notable lacteur concern. Il permet de dcrire ce que le futur systme devra faire, sans spcifier comment il le fera. On exprimera donc des actions effectues dans le cadre du mtier de lutilisateur, par opposition des manipulations de lapplication ou des comportements technique. Par exemple on ne dveloppe pas la manipulation dun IHM (cran), cela fera lobjet dune tude dergonomie. Lobjectif est le suivant : lensemble des cas dutilisations doit dcrire exhaustivement les exigences fonctionnelles du systme. Chaque cas dutilisation correspond donc une fonction mtier du systme, selon le point de vue dun des acteurs. Pour chaque acteur identifi durant ltude prliminaire, il convient de : Rechercher les diffrentes intention mtier avec lesquelles il utilise le systme. Dterminer dans le cahier des charges les services fonctionnels attendus du systme. On se servira des changes de messages identifis dans le modle de contexte statique. Vrifier que chaque cas dutilisation fournit une valeur ajoute REMARQUE : UN CAS DUTILISATION NEST NI UNE TRANSACTION, NI UNE FONCTION ! DISTINGUEZ LACTEUR PRINCIPAL DES ACTEURS SECONDAIRES.
2.2 Dcrire les cas dutilisation La technique recommande pour identifier les cas dutilisation partir du modle de contexte : considrez lintention fonctionnelle de lacteur par rapport au systme dans le cadre de lmission et de la rception de chaque message. Exemple de tableau initiale : CAS dutilisation Acteur principal, acteurs Message(s) mis / reus par secondaires les acteurs Gestion des commandes Rceptionniste Emet : cration, modification, annulation commande Reoit : condition commande client Emet : cration client
Etablissez une premire description textuelle succincte de chaque cas dutilisation candidat. Chaque cas dutilisation doit faire lobjet dune dfinition a priori qui dcrit lintention de lacteur lorsquil utilise le systme et les quelques squences dactions quil est susceptible deffectuer. Ces dfinitions servent fixer les ides lors de lidentification des cas dutilisation et nont aucun caractre exhaustif. Conseil : Limiter 20 le nombre de vos cas dutilisation . Ne mlanger pas lIHM et le fonctionnel Comment structurer les fiches de cas dutilisation ? La fiche de description textuelle dun cas dutilisation nest pas normalise par UML. Nous prconisions pour notre part la structuration suivante : Sommaire didentification (obligatoire) : inclut titre, but, rsum, dates, version, responsables, acteurs. Description des enchanements (obligatoire) : Dcrit les enchanements nominaux, les enchanements exceptionnels, les exceptions, mais aussi les pr conditions et les postpositions. Besoins en IHM (optionnel) : Ajoute ventuellement les contraintes homme machine. Contraintes non fonctionnelles (optionnel) : frquence, volumtrie, disponibilit, fiabilit, intgrit, confidentialit, performances, concurrence, ect .. Compltez les description textuelles des cas dutilisation par des diagrammes UML simples : Diagrammes dactivits Diagramme dtats Diagramme de squences.
le :02/09/03 Projet : Plan Assurance Qualit 2.3 Organiser les cas dutilisation UML 1.3 dfinie trois types de relations standardises entre cas dutilisation : Une relation dinclusion, formalise par une dpendance strotype : include Exemple : le cas dutilisation authentification est inclut par tous les autres cas dutilisations. Une relation dextension, formalise par une dpendance strotype extend Exemple le cas dutilisation gestion des client extend gestion des commandes Une relation de gnralisation / spcialisation. Quest ce quun packages : Un packages en UML reprsente un espace de nomage qui peut contenir des lments dun modle, Des diagrammes qui reprsentent les lments du modle, Dautres packages. 2.4 Identifier les classes candidates Comme nous lavons dj mentionn, la dfinition des cas dutilisation ne doit pas tre une fin en soi ! La technique mise au point par Ivar Jacobson comporte deux objectifs principaux : Dialoguer avec le client sur son expression prliminaire des besoins, grce une description fonctionnelles de son niveau dabstraction. Prparer la modlisation oriente objet en aidant trouver les classes principales du futur modle statique danalyse. Les premires classes candidates identifies dans cette phase doivent tre des concepts connus des utilisateurs du systme, ce quon appelle couramment des objets mtier. ( Client, Commandes, Mission, Agence ect..). Lanalyse ajoutera dans un second temps des concepts applicatifs , lis linformatisation( Profils utilisateurs, code barres ect..). Quest ce quune responsabilit : Cest une sorte de contrat ou dobligation pour une classe, si une classes comporte plus de 5 responsabilits, elle doit tre dcompose en plusieurs autres classes.
2.5 Valider et consolider La rvision des cas dutilisation doit absolument inclure une phase de prsentation aux futurs utilisateurs et poser les questions-cls ci-prs : Les frontires du systme sont elles bien dfinies ? Les acteurs sont-ils tous pris en compte ? Chaque cas dutilisation est il dclench par un acteur ? Le niveau dabstraction des cas dutilisation est il homogne ? Toutes les fonctionnalits du systmes sont elles traites ?
3. Capture des besoins techniques

3.1 Spcification technique du point de vue matriel 3.2 Spcification darchitecture et influence sur le modle de dploiement 3.3 Elaboration du modle de spcification logicielle 3.4 Organisation du modle de spcification logicielle 3.5 Dveloppement des couches logicielles 3.6 Dfinition des concepts techniques 3.7 Description des cas dutilisation technique REMARQUE : Cette tape dbouche sur les activits de : conception gnrique ; conception prliminaire conception dtaille La dernire activit est le codage et lexcution des tests.
4. Dcoupages en catgorie
Ce chapitre traite du dmarrage de lanalyse objet du systme raliser. En fin danalyse des besoins, nous obtenons un dcoupage fonctionnel exprim travers des cas dutilisation organiss dans le modle de spcification fonctionnelle. Pour passer lanalyse, nous allons changer radicalement lorganisation du modle et nous fonder sur les principes de lapproche oriente objet, notamment sur celui dencapsulation. A cet effet, nous allons passer dune structuration fonctionnelle via les cas dutilisation et les packages de cas dutilisation, une structuration objet via les classes et les catgories. 4.1 Dcoupage en catgories On regroupe les objets mtiers par lien smantique. Dpendances entre catgories On dcrit les dpendances entre les catgories.
5. Dcoupage en incrments
Lanalyse globale est finie. Nous allons maintenant dcouper le systme raliser en incrment Chaque incrment reprsente une unit du systme raliser. Chaque incrment va rentrer dans un cycle dactivit itratif : Analyse objet mtier ( spcifications dtailles) ; Conception gnrique ; Conception prliminaire ; Conception dtaille ; Ralisation ; Tests .
6. Dveloppement du modle statique ( analyse objet mtier )

6.1 Affiner les classes 6.2 Affiner les associations 6.3 Ajouter les attributs 6.4 Ajouter les oprations
7. Dveloppement du modle dynamique ( analyse objet mtier )

7.1 Modlisation des cycles de vie des entits importantes 7.2 Diagramme de squence dappel entre les classes
CONCLUSION
Dans ce document nous avons dcrit la de ralisation de systme informatique avec une dmarche objet. Nous avons abord la partie fonctionnelle ( analyse ), la partie de conception nest pas compltement dcrit dans ce document. Cette conception technique est importante dans la dmarche objet, car elle permet de traiter la couche technique sparment du modle mtier, dans un objectif de la rendre rutilisable sur dautre concept mtier. Lanalyse globale permet de dlimiter le systme raliser, de le dcouper en incrment, qui permet de limiter les risques sur le projet.

2tup Spec Dev1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

2tup Spec Dev1

Transféré par

Droits d'auteur :

Formats disponibles

le :02/09/03 Projet : Plan Assurance Qualit Projet : Document : VERSION Objet Plan Assurance Qualit 2UP_SPEC_DEV1 1.

Auteur Eric PAPET

Vrifi par: Dominique MASSON

Valid par: Socit: Fonction: Date: Signature

Guillaume FOURQUET IEP Grant, ingnieur informaticien

le :02/09/03 Projet : Plan Assurance Qualit

Gestion des modifications apportes au document

le :02/09/03 Projet : Plan Assurance Qualit

le :02/09/03 Projet : Plan Assurance Qualit

INTRODUCTION Les Niveaux dabstraction :

le :02/09/03 Projet : Plan Assurance Qualit

le :02/09/03 Projet : Plan Assurance Qualit

LA DEMARCHE 1. Etude prliminaire

le :02/09/03 Projet : Plan Assurance Qualit

2. Capture des besoins fonctionnels

le :02/09/03 Projet : Plan Assurance Qualit

le :02/09/03 Projet : Plan Assurance Qualit

le :02/09/03 Projet : Plan Assurance Qualit

3. Capture des besoins techniques

le :02/09/03 Projet : Plan Assurance Qualit

le :02/09/03 Projet : Plan Assurance Qualit

6. Dveloppement du modle statique ( analyse objet mtier )

7. Dveloppement du modle dynamique ( analyse objet mtier )

le :02/09/03 Projet : Plan Assurance Qualit

Vous aimerez peut-être aussi