L ’approche structurée à l ’approche objet d ’une conduite de projet informatique :

L ’approche structurée à l ’approche objet d ’une conduite de projet informatique :

par Thierry LENGLET et Thierno BAH

Comment réussir la transition pour une entreprise ?

C.N.A.M UV B1 : présentation du 22 mars 2004

Vous êtes ici : Présentation du plan


Planification de la présentation

Partie I : L ’évolution des méthodologies au fil du temps





Partie II - Solution 1 : Rédiger un guide de conversion des modèles






Partie III - Solution 2 : Mener un projet pilote






Partie III - Solution 2 : Mener un projet pilote

Conclusion

Vous êtes ici : le fil rouge


Nous souhaitions répondre à la problématique de la transition en se situant dans un cas d ’entreprise.

Notre entreprise référente : CnamObjets.

Nous nous sommes intéressés au processus commercial de commande, et nous avons occulté volontairement l ’approche conduite de projet et management.

Période avant Merise

Naissance de Merise

Apparition des modèles Objets - Période avant U.M.L.

Création d'U.M.L.

Historique

Vous êtes ici : Partie I > Présentation du plan


Avant Merise [de 1960 à 1976]

LCS 19974 HIPO 1970 PETRI 1962 SD 1974

IDEF-0 1974 S.A.D.T. 1976 SREM 1976 E-R 1976

Règle 1une transition n’est franchissable que lorsque toutes les places en amont possèdent au moins un jeton.

Règle 2sur un franchissement, il y a retrait d’un jeton de toutes les places précédentes et ajout d’un jeton dans toutes les places suivantes.

Réseaux de Pétri

Vous êtes ici : Partie I > Période avant Merise


P4

●

a b b vérifié a

●

b

● Usinage

Retouche

Défaut

● ●●●

P1 P2

T1T4

P5

P3P6

P1 : Appel d’offre en coursP2 : Enregistrement propositionP3 : Examen propositionP4 : Proposition refusée

T1 : Début d’examenT2 : Critères satisfaits (condition)T3 : Critères non satisfaits (condition)T4 : Arrivée date limite (événement)

Ok

Exemples de réseaux de pétri



DescriptionC’est une méthode d’analyse et de conception de système qui fournie des outils pour résoudre des problèmes complexes, communiquer les résultats de l’analyse et de la conception etc… Les éléments du modèle S.A.D.T.Des actigrammes (diagrammes d’activité)Des datagrammes (diagrammes de données), des diagrammes PES (donnent des informations sur les actigrammes et les datagrammes)Des textes, une liste hiérarchique (schéma de la hiérarchie du système) Un glossaire des principaux termes utilisés

S.A.D.T. - 1976



Fabriquer les 2 parties du moule Percer

Ranger les éléments nécessaires

Fermer le moule moule

2 parties complètes

Demande de noyaux

Partie supérieur percée

Partie inférieure

Plaque modèle

Sable en excèsMoule brisé

Sable

Chassis vide

Exemple de modèle S.A.D.T.



Année 1977Vaste consultation lancée par le ministère de l’industrie Année 1978-1979Naissance Merise OrigineInadéquation des méthodes comme MINOS ou CORIG aux préoccupations actuelles et à la génération des traitements

Naissance de Merise

Merise version.1 Une couverture de tout le cycle de vie du logiciel schéma directeur, étude préalable , étude détaillée, étude technique, mise en œuvre, maintenance… Un cycle d’abstraction reposant sur trois niveauxConceptuel - Organisationnel ou Logique – Physique La séparation entre les modèles de données, analysés avec une approche entité-association, et les modèles de traitement.

Vous êtes ici : Partie I > Naissance de Merise

Merise version.2

1990 Lancement par Sema Group du projet Merise 2. But Améliorations liées aux évolutions organisationnelles et techniques.Résorber le problème de carences du Modèle Entité–Association ApportsUn Apport marqué par l’introduction des diagrammes de flots de données Un Modèle Conceptuel des Traitements Analytiques (M.C.T.A.)La notion de Cycle de Vie d’un Objet (C.V.O.) Apports au niveau organisationnelPrise en compte des structures, des moyens matériels et humains



Merise OOM

Né en 1992 Orientée objet- Comporte une dimension fonctionnelle.Diagramme de contexte - Diagrammes de flots de données.Modèle entité-association



Apparition des modèles Objets - Période avant U.M.L. HOOD 1987 SYS_P_O 1988 MASCOT-3 1986 SART 1987 OOD 1986 OOA 1989 ESML 1989 STATEMATEL 1987 HOOD 1987 SYS_P_O 1988 MASCOT-3 1986 SART 1987 OOD 1986

OOA 1989 ESML 1989 STATEMATEL 1987 OOSE OMT 1991 OOM 1993 OOA/OO4 1991 CLASSE-RELATION 1991 FUSION 1994 OBJ ECTORY 1993 SCHLAER ET MELLOR 1992 U.M.L. 1996

La méthode O.M.T. était bien adaptée à l’analyse mais peu à la conception

Guerre des notations

Vous êtes ici : Partie I > Apparition des modèles Objets


Modèle Dynamique

Modèle Fonctionnel

Modèle Objet

Modèle d’Héritage

Objet

Objet Objet

Etat

Etat N

Etat

Objet

Objet

Objet

Objet Objet

Objet A

Les quatre modèles de base de O.M.T.



Au contraire de la méthode Booch 1991, mieux adaptée à la conception qu’à l’analyse :

Etat

Etat

Diagramme de transition d’état

EvénementEtat1 Etat2

Diagramme de transition d’état

Regroupement de classes et objets en modules

Diagramme de transition

Nom

Nom

Diagramme de tempsObjet 1Objet 2Objet N Cycle de vie

des objets

Diagramme des classes

Nom

Nom

Les modèles de BOOCH

Quant à la méthode de Jacobson, elle était bien taillée pour l’analyse des comportements, mais peu pour les autres domaines.



Création d'U.M.L.

La genèse d’U.M.L.

U.M.L

Fusion

Booch

Jacobson

Mayer

Harel

Wirfs-BrockEmbly

Odell

Shlaer-Mellor

Gamma et al.

Rumbaugh

Vous êtes ici : Partie I > La création d ’U.M.L.


Vous êtes ici : Partie II > Introduction


SOLUTION 1Rédiger un guide de traduction voir de conversion des modèles

Votre mission si vous l ’acceptez, reprendre certains principes et

concepts de modélisation du métier Merisiens, et les comparer

avec U.M.L.

Vous êtes ici : Partie II > Plan


Les principes Merisiens

La modélisation du métier

* l ’approche systémique* les cycles du processus* l ’approche fonctionnelle* l ’approche données / traitements* l ’approche par les messages

* Niveau conceptuel (M.C.D., Etats / Transitions, M.C.T.)* Niveau organisationnel (M.O.T.).

Quel menu alléchant, n ’est-ce pas camarades

auditeurs !!!

Vous êtes ici : Partie II > Approche systémique


Merise propose d'aborder tout problème d'automatisation, d'analyse, selon une approche qui considère l'entreprise comme un système vivant dans un environnement.

En ce sens, Merise est une méthode orientée systémique.


Gestion d'une nouvelle commande

Suppression d'une commande

Gestion commandes en attentecommercialClient

Scenario 1 : CLIENT EXISTANT

Scenario 2 : CLIENT NOUVEAU

Diagrammes de séquence

1_1 en cours ok et articles disponibles

1_2 en cours ok et rupture de stock

1_3 en cours dépassé

2_1 articles disponibles

2_2 rupture de stocks

Suppression commande


Cas d ’utilisation de la gestion commerciale et scénarios associés


L ’approche par les cas d ’utilisation constitue une approche systémique.


Ce qu ’il faut retenir...

Vous êtes ici : Partie II > Les cycles du processus

Cycle d'abstractionTraitements Données

Opérationnel / Physique

Organisationnel / Logique

Conceptuel

Maintenance

Mise en oeuvre

Intégration

Production

Etude détaillée

Etude préalable

Schéma directeur

Cycle de vieMort

Maturité

Naissance

Gestation

Cycle de décision

ContenuDéveloppement

Technique

Organisation

Découpage en lots

Affectation des ressources

GestionPlanning

Identification


Les cycles de Merise


Cycle de vie :

Vue logique

Vue des composants

Vue des processus

Vue de déploiement

Vue des cas d'utilisation


Approche 4+1 vues d ’U.M.L.

U.M.L. ne définit pas de cycle de vie. Il est implicite et correspond à un cycle itératif et incrémental guidé par les cas d ’utilisation, et centré sur les vues :


Cycle d ’abstraction :


Pour Merise, trois niveaux sont retenus :

* Conceptuel avec les Règles de Gestion et le QUOI Faire,

* Logique avec les Règles d'Organisation et le QUI Fait, le OU on fait et QUAND on fait,

* Physique avec les Règles de Production et le COMMENT faire.

On peut donc étudier le système progressivement en allant du général au particulier.



Cycle d ’abstraction :

U.M.L. permet de modéliser les différents niveaux du Système d'Information (Conceptuel, Organisationnel et Physique).

Pour cette partie, U.M.L. propose différents modèles (cas d’utilisation, paquetages, classes, composants).

Vous êtes ici : Partie II > L ’approche fonctionnelle


* Merise propose une approche où le système est découpé en activités, elles-mêmes regroupées en fonctions.

* Dans U.M.L., les fonctions cèdent le pas aux cas d ’utilisation et aux scénarios associés. A chaque scénario, vont correspondrent des diagrammes d ’interactions (séquence et collaboration) entre les objets et non pas entre les fonctions.

L ’approche fonctionnelle est une spécificité Merisienne dont U.M.L se démarque


système

Cas 1

Cas 2

Cas 3Fonction

Fonction

Fonction FonctionFonction

F

Cas 2

B

D

C

E

H

I

J

Cas 1

A

G

Gestion d'une nouvelle commande (CAS 1)

Suppression d'une commande (CAS 3)

Gestion commandes en attente (CAS 2)commercialClient


Représentation du virage vers l ’objet après l ’étude des uses cases


Nous avons affaire ici à la véritable différence (culturelle et conceptuelle) entre Merise et U.M.L.Cette différence impose que l ’informaticien « pense » autrement



Vous êtes ici : Partie II > L ’approche données / traitements


* Merise propose de considérer le système selon 2 points de vues. Cela permet d ’avoir 2 vues différentes à valider :

- un point de vue statique : les Données- un point de vue dynamique : les Traitements

* L ’approche objet associe les informations et les traitements :

il s ’agit là d ’un point clé de différence

Vous êtes ici : Partie II > L ’approche par les messages


avis entrée stock

CLIENT

demande approvisionnement

statistiques ventes

marketing

confirmation

commande à livrer

logistique

commande à facturer

administration

GESTION COMMERCIAUX

GESTION ARTICLES

PRODUCTION STATISTIQUES

GESTION LITIGES

GESTION DES COMMANDES

prise en compte commandegestion commande en attente

Domaine COMMERCIAL

L'ENTREPRISEACHATS

commande

Diagramme de flux : Les processus du domaine commercial



[refus] [rupture stock]

[Ok ET stock disponible]

Commander

COMMANDE[passée]

Prendre en compte la commande

COMMANDE[rejetée]

COMMANDE[en attente] Réapprovisionner

COMMANDE[confirmée]

COMMANDE[à l ivrer]

COMMANDE[à facturer]

Diagramme d ’activités : Gestion globale des commandes



: Vérification client()

commande refusée

commercial

: EnCours commandes()

en cours dépassé

un client : Client commandes en cours : Commande

Diagramme de séquencesCas d ’utilisation : Gestion d ’une nouvelle commande

Scénario : Client existant et commande en cours dépassée


Il est possible de rapprocher le diagramme de flux au :- diagramme d ’activités- diagramme de séquence



Vous êtes ici : Partie II > Modélisation du métier


On vous propose au menu la modélisation du métier :

* Niveau conceptuel (M.C.D., Etats / Transitions, M.C.T.)

* Niveau organisationnel (M.O.T.).

Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.


1,1

COMMANDE

no commande N(4)date de commande D(10)date de livraison D(10)prise de commande A(20)livraison A(20)facturation A(20)

0,nDEPOT

code dépôtadresser

Exemple 1 :



Exemple 1 :

1,1

COMMANDE


0,nDEPOT


10..*adresser

+ COMMANDE+ no commande+ date de commande+ date de livraison+ prise de commande+ livraison+ facturation+ EnCousCommande()+ Create()+ Suppression()

+ DEPOT+ code dépôt



1,1

COMMANDE


0,nDEPOT


10..*adresser



Le jeu des comparaisons,

çà vous dit !

Exemple 1 :



1,1

COMMANDE


0,nDEPOT


10..*adresser



Une entité = Une classe

Exemple 1 :



1,1

COMMANDE


0,nDEPOT


10..*adresser



Propriétés des entités =

Attributs des classes

Exemple 1 :



1,1

COMMANDE


0,nDEPOT


10..*adresser



Identifiant d ’entité = Attribut identifiant (ou

clé) de la classe

Exemple 1 :



1,1

COMMANDE


0,nDEPOT


10..*adresser



Relation entre entités =

Association entre classes

Exemple 1 :



0,n

FOURNISSEUR

code fournisseur

0,n 0,nsubstitué

0,nsubstituant

ARTICLE

code articledésignation articletariftype article (S)

disposer

délai

substituer

Exemple 2 :



Exemple 2 :

0,n

FOURNISSEUR

code fournisseur

0,n

0,nsubstituant

0,nsubstitué

ARTICLE


disposer

délai

substituer

0..*0..*

disposer

0..*substitué

0..*

substituant

substituer

+ ARTICLE+ code article+ désignation article+ tarif

+ prix unitaire+ prix moyen d'achat

+ type article (S)+ Disponibilité()

+ FOURNISSEUR+ code fournisseur

+ disposer

+ délai



Exemple 2 :

0,n

FOURNISSEUR

code fournisseur

0,n

0,nsubstituant

0,nsubstitué

ARTICLE


disposer

délai

substituer

Le jeu des comparaisons, on continue !

0..*0..*

disposer

0..*substitué

0..*

substituant

substituer





+ disposer

+ délai



Exemple 2 :

0,n

FOURNISSEUR

code fournisseur

0,n

0,nsubstituant

0,nsubstitué

ARTICLE


disposer

délai

substituer

Une relation porteuse

d ’informations = classe

association

0..*0..*

disposer

0..*substitué

0..*

substituant

substituer





+ disposer

+ délai



Exemple 2 :

0,n

FOURNISSEUR

code fournisseur

0,n

0,nsubstituant

0,nsubstitué

ARTICLE


disposer

délai

substituer

Avec U.M.L., le nommage des

rôles est possible pour toutes les

relations

0..*0..*

disposer

0..*substitué

0..*

substituant

substituer





+ disposer

+ délai



ARTICLE


XT

PIECE RECHANGE

mesuresMATERIEL ELECTRIQUE

puissance

Exemple 3 :



Exemple 3 :

ARTICLE


XT

PIECE RECHANGE


puissance




+ MATERIEL ELECTRIQUE+ puissance

+ PIECE RECHANGE+ mesures

<< Partition >>{ }



Exemple 3 :ARTICLE


XT

PIECE RECHANGE


puissance

Le jeu des comparaisons,

C ’est bientôt fini, snif !






<< Partition >>{ }



Exemple 3 :ARTICLE


XT

PIECE RECHANGE


puissance

L ’héritage est transformé en généralisation, qui va mener

à la constitution d ’une hiérarchie de classes.






<< Partition >>{ }


Les règles de validation du Modèle Conceptuel des Données apparaissent comme un point fort du modèle entité-relation Merisien.

Ces règles peuvent être mises en œuvre dans U.M.L. pour éviter des erreurs lourdes de modélisation et assurer les bases du système informatique.




Le diagramme de classes ressemble à première vue au M.C.D.En fait, il s ’en distingue par : * L ’introduction des méthodes dans les classes. Il s ’agit là d ’un point clé fondamental.* Le diagramme de classes est utilisé tout au long du cycle de développement pour modéliser d ’autres aspects (classes de nature physique ou liées aux outils techniques employés).



Vous êtes ici : Partie II > Niveau Conceptuel > Etats/Transitions


Dans Merise/2 est apparu la notion de cycle de vie d ’une entité. Le cycle de vie traduit les différents états que peut prendre l ’entité et les événements qui déclenchent le passage d ’un état à l ’autre.

Prise de commandeC.V.O COMMANDEacceptation commande

commande rejetée ok

vérification stock

dispo rupture

traitement commande en attente

avis entrée stock

COMMANDEprise de commande

enregistrée


confirmée


en attenteCOMMANDE

prise de commande

rejetée

commande

Cycle de vie de l ’entité commande


C.N.A.M UV B1 : présentation du 22 mars 2004Diagramme d ’Etats/Transitions - Prise de commande

[Véri fier stock (disponible)][Vérifier stock (rupture)]

fin attente

[COMMANDE] Enregistrée

[COMMANDE] Rejetée

do / Rejet ()

[COMMANDE] Analysée

[COMMANDE] Confirmée [COMMANDE] En attente

entry / Avis d'entrée stockdo / traitement commande en attente

Début

Fin


Il s ’agit de modèles très proches tant par leur formalisme que par les concepts manipulés.



Vous êtes ici : Partie II > Niveau Conceptuel > M.C.T.


Composant du M.C.T. : EVENEMENTS

Composant du M.C.T. : SYNCHRONISATION

Composant du M.C.T. : OPERATIONS

Dans U.M.L., les événements vont apparaître au niveau des diagrammes de séquences et d ’activités.

Dans U.M.L., les synchronisations vont apparaître dans les diagrammes d ’activités et d ’états/transitions.

Dans U.M.L., les opérations vont être représentées dans les diagrammes d ’activités.

Vous êtes ici : Partie II > Niveau Organisationnel > M.O.T.

Période

Immédiat

Immédiat

Immédiat

Client Secretariat commercial Type

Manuel

Manuel

Manuel

Commande ET

Nouveau Trouvé

Identifier client Saisir nom client Accéder au compte

Création compte

(A)

Description du client

ET

Client OK Client à pb

Vérifier client en cours Contrôler compte

A ou B

OK

Enregistrer la commande Saisir les quantités

Validation demandée

(B)

Saisir les articles M.O.T. Organisation de la prise de commande (extract)


Client Secrétaire commercial

[Nouveau] [Trouvé]

[Client à pb]

[Compte OK]

Commander COMMANDE [passée]

Identifier client

Créer client

Verifier client

Enregistrer la commande

COMMANDE [rejetée]

COMPTE [créé]

COMMANDE [enregistrée]

COMMANDE [validée]

Diagramme d'activités Prise en compte de la commande (extract)


Le diagramme d ’activités, vu sous l ’angle de l ’enchaînement des tâches effectuées, est une représentation très proche du M.O.T.



Vous êtes ici : Partie II > Synthèse


Modèles MeriseNiveaux d'abstraction Conc. Orga. Conc. Orga. Conc. Orga. Conc. Orga.Diagrammes U.M.L.Cas d'utilisationDiagrammede classesDiagrammed'objetsDiagrammede séquenceDiagrammed’états/transitionsDiagrammed'activités

flux Traitements Données Etats/Trans

Vous êtes ici : Partie II > Synthèse


Modèles MeriseNiveaux d'abstraction Conc. Orga. Conc. Orga. Conc. Orga. Conc. Orga.Diagrammes U.M.L.Cas d'utilisationDiagrammede classesDiagrammed'objetsDiagrammede séquenceDiagrammed’états/transitionsDiagrammed'activités

flux Traitements Données Etats/Trans

ATTENTIONcomparaison <> équivalence

Vous êtes ici : Partie II > Conclusion


La transition de Merise à U.M.L. ne peut se résumer à la rédaction d'un guide de traduction / conversion des modèles.

Pourquoi ?Réponse : il ne faut pas dissocier U.M.L et l ’approche objet

Vous êtes ici : Partie II > Vers l ’ébauche d ’une nouvelle solution


Vision du systèmeDans l ’approche objet, un système est vu comme un ensemble d ’objets (regroupant données et traitements) qui coopèrent grâce à l ’envoi de messages.

C ’est une différence majeure avec l ’approche structurée

Mode de développementDans l ’approche objet, le développement est itératif, incrémental, centré sur l ’architecture et guidé par les cas d ’utilisations.

C ’est un facteur important de changement

Vous êtes ici : Partie II > Mise en place d ’une nouvelle solution


Migration vers l ’objet : scénario dit de TRANSITION PROGRESSIVE

Formation

Mise en place d ’un projet PILOTE

Description du projet pilote

Choix du processus de développement

Modélisation métier et analyse des besoins

Analyse et Conception

Implémentation, Tests et Déploiement

Conclusion

PROJET PILOTE

Vous êtes ici : Partie III > Plan


Application WEB mobile

Application Gestion Commerciale

Liste Clients Ajout Nouveau Client Liste Commandes Ajout Nouvelle Commande

PORTAIL INTRANET

Autres applications de l’intranet

Vous êtes ici : Partie III > Description du projet PILOTE


Chaque client est identifié par un numéro unique qui permet de le sélectionner et de consulter par la suite ses commandes.

Le numéro du client est généré automatiquement une fois que l’option « ajout nouveau client » est activée.

Lorsque l'on consulte la liste des clients, le nouveau client ajouté doit s’y trouver.

Il est possible de consulter la liste des commandes. Une commande a un identifiant unique qui permet d’en visualiser le détail. Elle est référencée par un produit, un prix unitaire et une quantité.

Lorsque l'on consulte la liste des clients, le nouveau client et/ou la nouvelle commande doivent s’y trouver.

Un certain nombre d’informations sont gérées automatiquement telles que « le type de commande, la date de prise de commande, le montant de la commande , la région où la commande a été passée ».

On peut consulter la liste des commandes par client, la liste des clients, la liste de l’ensemble des commandes.

Règles de Gestion

Vous êtes ici : Partie III > Description du projet PILOTE

Phases

Enchaînement du processus Etude d’opportunité Elaboration Construction Transition

1 Modélisation métier

2 Besoin

3 Analyse et Conception

4 I mplémentation

5 Tests

6 Déploiement

Enchaînement du soutien

1 Gestion de la configuration

2 Direction du projet

3 Environnement

I térations

Vous êtes ici : Partie III > Choix du processus de développement (Processus Unifié de Rational « RUP »)

Sous-Système Gestion Commerciale Acteurs primaires : Commercial

Client

Sous-Système Application Web Mobile Acteur primaire: CommercialActeur secondaire: Technicien

Vous êtes ici : Partie III > Modélisation métier et analyse des besoins


COMMANDE

CLIENT

Commercial

FOURNISSEUR

Client

Fournisseur

Gestion Commandes en AttenteGestion Nouvelle Commande

Ajout Nouvelle Commande

Suppression Commande

Comptabilisation Commandes

Facturation Commandes

Gestion Nouveau Client

Gestion Clients Existants ou Reguliers

Ajout Nouveau Client

Comptabilisation Clients

Gestion ApprovisionnementGestion Fournisseurs

Gestion Commande

Gestion Client

Approvisionnement Magasin

<<include>>

<<extend>>

<<include>><<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<extend>>

<<include>>

Diagramme des cas d’utilisation de la gestion commerciale


FONCTIONNEMENT

Commercial

DEBOGAGE ROBUSTESSE

Technicien

Gestion des Connexions

Ajoût Nouvelle Commande

Gestion des Outils

Ajoût Nouveau Client Lister Commande

Choix d'Options de Gestion Commerciale

Lister ClientsConnexion en Mode Connecté

Connexion en Mode Déconnecté

Allumage Portabilité

Gestion des Erreurs Rapidité d'execution des requêtes

Sécurité

Resolution des beugs

Gestion Automatisée des erreurs

<<include>>

<<include>>

<<include>>

<<include>>



<<extend>>

<<include>>

Diagramme des cas d’utilisation du système "application mobile"



Analyse Disponibilité Commande

Facturation Livraison

Réapprovisionnement

Relance Comptabilisation Reglement

Saisie Nouvelle Commande Saisie Nouveau Client

Analyse solvabilité Client

Gestion Commande Gestion Client

Mise en attente commande

<<description>>Le reglement est-il effectué ?

<<description>>La commande est-elle disponible ?

<<description>>La livraison a t'elle été effectuée ?

<<description>>Le client est - il solvable ?

Annulation Commande[Oui][Non]

[Non]

[Oui]

[Non]

[Non]

[Oui]

[Oui]

Diagramme des activités de la gestion commerciale



Identification des classes et des objets COMMERCIALCOMMANDE

CLIENTLIGNE DE COMMANDE

FOURNISSEURPRODUIT

Vous êtes ici : Partie III > Analyse et Conception


Commercial/:Commercial

Une Commande/:COMMANDE

Lignes Commandes/:LIGNE DE COMMANDE

Bases De Données/:OUTIL DE GESTIONProduitsCommandés/:PRODUIT

Client/:Client

un client/:CLIENT

verificationDisponibilitéCommande()

commande disponible

SaisieCommande()

saisie ok

SaisieLignesDeCommande()

saisie ok

EnregistrementDonnées()

ok

Envoi d'une commande

verificationSolvabilitéClient()

client solvable

date de livraison

avis de traitement

Diagramme de séquences des « commandes disponibles »





Application Mobile/:APPLICATION M OBILE Bases Info Connexion/:BASE DE DONNEES Bases De Données Mobile/:BASE DE DONNEES

Commercial/:Commercial

Saisie des Données d'Authentification

verificationIdentitéCommercial()

ok

Choix Options Gestion Commerciale

Requetage Clients Commandes

Affichage des Resultats des Commandes

Diagramme de séquences « Gestion en mode déconnecté »

Client/:ClientCommerciale/:Commercial

Un client/:CLIENT Produits Commandés/:PRODUITUne Commande/:COMMANDE

Lignes Commandes/:LIGNE DE COMMANDE

Bases de données/:OUTIL DE GESTION

Un Fournisseur/:FOURNISSEUR

4: verificationDisponibiliteProduit

B: Demande Approvisionnement

1:Envoi Commande

2:verificationSolvabilitéClient

8: EnregistrementDonnées

5: Ok // A: Non OK3: Ok // I: Non OK

II: Impossibilité de Traiter la Commande

6: SaisieCommande

7: SaisieLignesCommandes

Diagramme de collaboration pour la « Gestion commerciale »



Commande TraitéeCommande en attente

Commande Nouvelle

Facture émise

Facture reglée Facture AnnuléeFacture en attente de reglement

Commande annuléeDo/contact client

Do/reception commande

Entry/examen commandeExit/fin examen

Do/envoyer la facture

Do/avis de reception de reglement Do/desenregitrement factureEntry/inscription listeExit/reglement effectué

Do/envoi d'avis d'annulation

Examen commande et livraisonExamen commande et indisponibilité

Insolvabilité

Livraison du client

Somme créditéeSomme non reglée

Erreur d'émission

Diagramme d'états-transitions global de la « Gestion commerciale »



Diagramme d'états-transitions global de « l ’application mobile »

Application en Mode Connecté Application en Mode Déconnecté

Connexion Reseau interne

Deconnexion de l'application

Application synchronisée avec le serveur

Nouvelle Commande Saisie Nouveau Client SaisieRequetage actif : Listage Client-Commande

Portail Intranet Affiché

Fin Requetage

Client Débranché du Réseau PDA Mode Autonome

Do/^PortailIntranet.Connexion()Do/^PortailIntranet.Connexion()

Entry/^commande.saisie()Exit/[compteur=NBcommandes]

Do/Initialisation

Do/branchement

Entry/ecrire requeteExit/fermer l'interface requetage

Entry/^Serveur.synchronisation()Exit/fin mis à jour des données

Entry/^Client.saisieClient()Exit/compteurClient=NBnouveauxClients

Connexion au serveur

[appel du portail]

[compteur=0]requetage

tranfert de données sur le client Alimentation PDA

Choix du Mode Connecté Choix du Mode Deconnecté

Alimenter PDA[compteur=0]

FOURNISSEUR

COMMANDECOMMERCIAL

SOCIETE

LIGNE DE COMMANDE

PRODUIT

PDA POCKET PC

OUTIL DE GESTIONCLIENT

DEPOT

stocker produits

Interface Commande Interface Ligne de commande

Marque : string

GererCommande()

Id_Commercial : integerNom : stringPrenom : stringAdresse : stringCode Postal : integerVille : string

RemunerationCommerciaux()

Marque : stringPrix : real

Marque : stringPrix : real

Allumer()GererCommande()HorsTension()

Prix : real

Allumer()

Eteindre()

*

1..*

utiliser

N°LigneCommande : integerMontant : integerCommandeEffectuée : integerCommandeLivrée : integer

CalculTotauxCommande()

quantité reservée : real*

Siren : stringTelephone : integer

AggregationPrefixLIGNE DE COMMANDEN°Commande : integerInfo_Livraison : stringDate_Livraison : stringInfo_Facturation : stringDate_Facturation : stringDate_Commande : string

SaisieCommande()

CalculQuantiteCommande()CalculMontantCommande()ListeCommandes()

ID_Client : integer

CodePostal : integer

verificationDisponibilitéCommande()

SupprimerCommande()

*

*

Enregister-Valider

1

1..*

1..*1

Ville : string

Nom : stringPrenom : stringAdresse : string

*

Négocier Contrat Avec

CodeNaf : integer

passer commande

1

Adresse : string

N°Fournisseur : integerNom : string

CodePostal : integerVille : stringPays : stringTelephone : integerEmail : stringFax : string

CommandesFounisseurs()ListeFournisseurs()CalculRemuneration()

concerner*

Designation : stringCode : integer

Type : string

QuantitéProduits()ListeProduits()

Prix : real

11

Livrer Par

quantité stockée : real*

*

*

1

Forme Juridique : stringCapital Social : real

Email : string

VerificationSolvabilitéClient()SaisieClient()ListeClients()

Code depot : integer

TotauxProduits()

Diagramme de classes du système « Gestion Commerciale »



Commande.java

<<executable>>Client.class

<<executable>>Fournisseur.class

<<executable>>Produit.class

<<executable>>Commande.class

Fournisseur.java Produit.java Client.java

<<description>>compilation

<<description>>fichiers

Diagramme des composants du système

Vous êtes ici : Partie III > Implémentation, Tests et Déploiement


PC Portable Client

Serveur Base de données

PDA ou PC Pocket Intranet de la société

<<description>>commande.classclient.classproduit.class

<<description>>commande.classclient.classproduit.class

<<description>>portail.htmlcommande.classclient.classproduit.class

*

1

*

1

*

1

Diagramme de déploiement du système



Commande.java

public class Commande { private int N°Commande; private String Info_Livraison; private String Info_Facturation; private String Date_Livraison; private String Date_Commande; /** variable à caster du format date au format string* pour des besoins techniques*/ public Commande() { //initialisation } public void saisieCommande(){ } public void supprimerCommande(){ } public void listeCommande(){ } public float CalculQuantiteCommande(){ }public float CalculMontantCommande(){ }}

public class Client { private int ID_Client; private String Nom; private String Prenom; private String Adresse; private String Ville; private String Email; private String Ville; private Double Telephone; /** variable à caster du format date au format string * pour des besoins techniques*/ public Commande() { //initialisation } public void verificationSolvabiliteClient(){ } public void SaisieClient(){ } public void ListeClients(){ }}

Client.java



Vous êtes ici : Partie III > Conclusion


L’architecture d’un logiciel est constituée de plusieurs vues concurrentes, respectivement :- la vue logique- la vue d’implémentation- la vue des composants- et la vue de déploiement

Des scénarios viennent compléter la vue des cas d’utilisation. Les diagrammes des composants décrivent les éléments qui constituent l’implémentation physique du système et les diagrammes de déploiement, quant-à eux, représentent la configuration matérielle sur laquelle sera exécuté le système.

Le projet PILOTE présenté dans cette troisième partie a immiscer la dynamique de la transition pour l'entreprise CnamObjets.

Celle-ci dispose désormais d'un projet réel mené selon une approche objet (processus RUP) et une modélisation U.M.L.

Celui-ci sera dorénavant le référent pour les projets à mener à l'avenir.

Vous êtes ici : Conclusion générale


Changement de vision du système

Mise en œuvre d ’un processus de développement

Mise en place d ’un projet PILOTE

Plan de formation

Stratégie de migration technique

Et après ?

Vous êtes ici : Questions


Avez-vous des questionscamarades auditeurs ?

L ’approche structurée à l ’approche objet d ’une conduite de projet informatique :

Documents

Transcript of L ’approche structurée à l ’approche objet d ’une conduite de projet informatique :