l ’approche structurée à l ’approche objet d ’une conduite de projet informatique :
Post on 18-Mar-2016
28 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
C.N.A.M UV B1 : présentation du 22 mars 2004
Planification de la présentation
Partie I : L ’évolution des méthodologies au fil du temps
Vous êtes ici : Présentation du plan
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Présentation du plan
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Présentation du plan
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Conclusion
Vous êtes ici : le fil rouge
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Partie I > Période avant Merise
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Partie I > Période avant Merise
C.N.A.M UV B1 : présentation du 22 mars 2004
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.
Vous êtes ici : Partie I > Période avant Merise
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Partie I > Naissance de Merise
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Partie I > Naissance de Merise
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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.
Vous êtes ici : Partie I > Apparition des modèles Objets
C.N.A.M UV B1 : présentation du 22 mars 2004
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.
Vous êtes ici : Partie I > Apparition des modèles Objets
C.N.A.M UV B1 : présentation du 22 mars 2004
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.
C.N.A.M UV B1 : présentation du 22 mars 2004
Vous êtes ici : Partie II > Introduction
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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.
Vous êtes ici : Partie II > Approche 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
C.N.A.M UV B1 : présentation du 22 mars 2004
Cas d ’utilisation de la gestion commerciale et scénarios associés
Vous êtes ici : Partie II > Approche systémique
L ’approche par les cas d ’utilisation constitue une approche systémique.
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
Les cycles de Merise
Vous êtes ici : Partie II > Les cycles du processus
Cycle de vie :
Vue logique
Vue des composants
Vue des processus
Vue de déploiement
Vue des cas d'utilisation
C.N.A.M UV B1 : présentation du 22 mars 2004
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 :
Vous êtes ici : Partie II > Les cycles du processus
Cycle d ’abstraction :
C.N.A.M UV B1 : présentation du 22 mars 2004
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.
Vous êtes ici : Partie II > Les cycles du processus
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
* 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
Vous êtes ici : Partie II > L ’approche fonctionnelle
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
C.N.A.M UV B1 : présentation du 22 mars 2004
Représentation du virage vers l ’objet après l ’étude des uses cases
Vous êtes ici : Partie II > L ’approche fonctionnelle
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
C.N.A.M UV B1 : présentation du 22 mars 2004
Ce qu ’il faut retenir...
Vous êtes ici : Partie II > L ’approche données / traitements
C.N.A.M UV B1 : présentation du 22 mars 2004
* 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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Partie II > L ’approche par les messages
C.N.A.M UV B1 : présentation du 22 mars 2004
[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
Vous êtes ici : Partie II > L ’approche par les messages
C.N.A.M UV B1 : présentation du 22 mars 2004
: 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
Vous êtes ici : Partie II > L ’approche par les messages
Il est possible de rapprocher le diagramme de flux au :- diagramme d ’activités- diagramme de séquence
C.N.A.M UV B1 : présentation du 22 mars 2004
Ce qu ’il faut retenir...
Vous êtes ici : Partie II > Modélisation du métier
C.N.A.M UV B1 : présentation du 22 mars 2004
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.
C.N.A.M UV B1 : présentation du 22 mars 2004
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 :
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
Exemple 1 :
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
10..*adresser
+ COMMANDE+ no commande+ date de commande+ date de livraison+ prise de commande+ livraison+ facturation+ EnCousCommande()+ Create()+ Suppression()
+ DEPOT+ code dépôt
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
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
10..*adresser
+ COMMANDE+ no commande+ date de commande+ date de livraison+ prise de commande+ livraison+ facturation+ EnCousCommande()+ Create()+ Suppression()
+ DEPOT+ code dépôt
Le jeu des comparaisons,
çà vous dit !
Exemple 1 :
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
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
10..*adresser
+ COMMANDE+ no commande+ date de commande+ date de livraison+ prise de commande+ livraison+ facturation+ EnCousCommande()+ Create()+ Suppression()
+ DEPOT+ code dépôt
Une entité = Une classe
Exemple 1 :
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
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
10..*adresser
+ COMMANDE+ no commande+ date de commande+ date de livraison+ prise de commande+ livraison+ facturation+ EnCousCommande()+ Create()+ Suppression()
+ DEPOT+ code dépôt
Propriétés des entités =
Attributs des classes
Exemple 1 :
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
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
10..*adresser
+ COMMANDE+ no commande+ date de commande+ date de livraison+ prise de commande+ livraison+ facturation+ EnCousCommande()+ Create()+ Suppression()
+ DEPOT+ code dépôt
Identifiant d ’entité = Attribut identifiant (ou
clé) de la classe
Exemple 1 :
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
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
10..*adresser
+ COMMANDE+ no commande+ date de commande+ date de livraison+ prise de commande+ livraison+ facturation+ EnCousCommande()+ Create()+ Suppression()
+ DEPOT+ code dépôt
Relation entre entités =
Association entre classes
Exemple 1 :
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
0,n
FOURNISSEUR
code fournisseur
0,n 0,nsubstitué
0,nsubstituant
ARTICLE
code articledésignation articletariftype article (S)
disposer
délai
substituer
Exemple 2 :
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
Exemple 2 :
0,n
FOURNISSEUR
code fournisseur
0,n
0,nsubstituant
0,nsubstitué
ARTICLE
code articledésignation articletariftype article (S)
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
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
Exemple 2 :
0,n
FOURNISSEUR
code fournisseur
0,n
0,nsubstituant
0,nsubstitué
ARTICLE
code articledésignation articletariftype article (S)
disposer
délai
substituer
Le jeu des comparaisons, on continue !
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
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
Exemple 2 :
0,n
FOURNISSEUR
code fournisseur
0,n
0,nsubstituant
0,nsubstitué
ARTICLE
code articledésignation articletariftype article (S)
disposer
délai
substituer
Une relation porteuse
d ’informations = classe
association
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
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
Exemple 2 :
0,n
FOURNISSEUR
code fournisseur
0,n
0,nsubstituant
0,nsubstitué
ARTICLE
code articledésignation articletariftype article (S)
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
+ ARTICLE+ code article+ désignation article+ tarif
+ prix unitaire+ prix moyen d'achat
+ type article (S)+ Disponibilité()
+ FOURNISSEUR+ code fournisseur
+ disposer
+ délai
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
ARTICLE
code articledésignation articletariftype article (S)
XT
PIECE RECHANGE
mesuresMATERIEL ELECTRIQUE
puissance
Exemple 3 :
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
Exemple 3 :
ARTICLE
code articledésignation articletariftype article (S)
XT
PIECE RECHANGE
mesuresMATERIEL ELECTRIQUE
puissance
+ ARTICLE+ code article+ désignation article+ tarif
+ prix unitaire+ prix moyen d'achat
+ type article (S)+ Disponibilité()
+ MATERIEL ELECTRIQUE+ puissance
+ PIECE RECHANGE+ mesures
<< Partition >>{ }
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
Exemple 3 :ARTICLE
code articledésignation articletariftype article (S)
XT
PIECE RECHANGE
mesuresMATERIEL ELECTRIQUE
puissance
Le jeu des comparaisons,
C ’est bientôt fini, snif !
+ ARTICLE+ code article+ désignation article+ tarif
+ prix unitaire+ prix moyen d'achat
+ type article (S)+ Disponibilité()
+ MATERIEL ELECTRIQUE+ puissance
+ PIECE RECHANGE+ mesures
<< Partition >>{ }
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
C.N.A.M UV B1 : présentation du 22 mars 2004
Exemple 3 :ARTICLE
code articledésignation articletariftype article (S)
XT
PIECE RECHANGE
mesuresMATERIEL ELECTRIQUE
puissance
L ’héritage est transformé en généralisation, qui va mener
à la constitution d ’une hiérarchie de classes.
+ ARTICLE+ code article+ désignation article+ tarif
+ prix unitaire+ prix moyen d'achat
+ type article (S)+ Disponibilité()
+ MATERIEL ELECTRIQUE+ puissance
+ PIECE RECHANGE+ mesures
<< Partition >>{ }
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
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.
C.N.A.M UV B1 : présentation du 22 mars 2004
Ce qu ’il faut retenir...
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
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).
C.N.A.M UV B1 : présentation du 22 mars 2004
Ce qu ’il faut retenir...
Vous êtes ici : Partie II > Niveau Conceptuel > Etats/Transitions
C.N.A.M UV B1 : présentation du 22 mars 2004
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
COMMANDEprise de commande
confirmée
COMMANDEprise de commande
en attenteCOMMANDE
prise de commande
rejetée
commande
Cycle de vie de l ’entité commande
Vous êtes ici : Partie II > Niveau Conceptuel > Etats/Transitions
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
Vous êtes ici : Partie II > Niveau Conceptuel > Etats/Transitions
Il s ’agit de modèles très proches tant par leur formalisme que par les concepts manipulés.
C.N.A.M UV B1 : présentation du 22 mars 2004
Ce qu ’il faut retenir...
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.T.
C.N.A.M UV B1 : présentation du 22 mars 2004
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)
Vous êtes ici : Partie II > Niveau Organisationnel > M.O.T.
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)
Vous êtes ici : Partie II > Niveau Organisationnel > M.O.T.
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.
C.N.A.M UV B1 : présentation du 22 mars 2004
Ce qu ’il faut retenir...
Vous êtes ici : Partie II > Synthèse
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Partie III > Modélisation métier et analyse des besoins
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>>
<<include>><<include>>
<<include>><<include>>
<<extend>>
<<include>>
Diagramme des cas d’utilisation du système "application mobile"
Vous êtes ici : Partie III > Modélisation métier et analyse des besoins
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Partie III > Modélisation métier et analyse des besoins
C.N.A.M UV B1 : présentation du 22 mars 2004
Identification des classes et des objets COMMERCIALCOMMANDE
CLIENTLIGNE DE COMMANDE
FOURNISSEURPRODUIT
Vous êtes ici : Partie III > Analyse et Conception
C.N.A.M UV B1 : présentation du 22 mars 2004
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 »
Vous êtes ici : Partie III > Analyse et Conception
C.N.A.M UV B1 : présentation du 22 mars 2004
Vous êtes ici : Partie III > Analyse et Conception
C.N.A.M UV B1 : présentation du 22 mars 2004
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 »
Vous êtes ici : Partie III > Analyse et Conception
C.N.A.M UV B1 : présentation du 22 mars 2004
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 »
Vous êtes ici : Partie III > Analyse et Conception
C.N.A.M UV B1 : présentation du 22 mars 2004
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 »
Vous êtes ici : Partie III > Analyse et Conception
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
Vous êtes ici : Partie III > Implémentation, Tests et Déploiement
C.N.A.M UV B1 : présentation du 22 mars 2004
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 > Implémentation, Tests et Déploiement
C.N.A.M UV B1 : présentation du 22 mars 2004
Vous êtes ici : Partie III > Conclusion
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
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
C.N.A.M UV B1 : présentation du 22 mars 2004
Avez-vous des questionscamarades auditeurs ?
top related