La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Comment réussir la transition pour une entreprise ?

Présentations similaires


Présentation au sujet: "Comment réussir la transition pour une entreprise ?"— Transcription de la présentation:

1 Comment réussir la transition pour une entreprise ?
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

2 Vous êtes ici : Présentation du plan
Planification de la présentation Partie I : L ’évolution des méthodologies au fil du temps C.N.A.M UV B1 : présentation du 22 mars 2004

3 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 C.N.A.M UV B1 : présentation du 22 mars 2004

4 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 C.N.A.M UV B1 : présentation du 22 mars 2004

5 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 Conclusion C.N.A.M UV B1 : présentation du 22 mars 2004

6 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. C.N.A.M UV B1 : présentation du 22 mars 2004

7 Vous êtes ici : Partie I > Présentation du plan
Historique  Période avant Merise  Naissance de Merise  Apparition des modèles Objets - Période avant U.M.L.  Création d'U.M.L. C.N.A.M UV B1 : présentation du 22 mars 2004

8 Vous êtes ici : Partie I > Période avant Merise
Avant Merise [de 1960 à 1976] Réseaux de Pétri  Règle 1 une transition n’est franchissable que lorsque toutes les places en amont possèdent au moins un jeton.  Règle 2 sur 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. C.N.A.M UV B1 : présentation du 22 mars 2004

9 Exemples de réseaux de pétri
Vous êtes ici : Partie I > Période avant Merise Exemples de réseaux de pétri a b b vérifié  a b Ok Défaut Usinage Retouche P1 ●●● P2 P1 : Appel d’offre en cours P2 : Enregistrement proposition P3 : Examen proposition P4 : Proposition refusée T1 : Début d’examen T2 : Critères satisfaits (condition) T3 : Critères non satisfaits (condition) T4 : Arrivée date limite (événement) T4 T1 P6 P3 P4 P5 C.N.A.M UV B1 : présentation du 22 mars 2004

10 Vous êtes ici : Partie I > Période avant Merise
S.A.D.T  Description C’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 C.N.A.M UV B1 : présentation du 22 mars 2004

11 Vous êtes ici : Partie I > Période avant Merise
Sable en excès Sable Fabriquer les 2 parties du moule Moule brisé Partie supérieur percée Percer Demande de noyaux Chassis vide Plaque modèle Ranger les éléments nécessaires Fermer le moule moule Partie inférieure 2 parties complètes Exemple de modèle S.A.D.T. C.N.A.M UV B1 : présentation du 22 mars 2004

12 Vous êtes ici : Partie I > Naissance de Merise
 Année 1977 Vaste consultation lancée par le ministère de l’industrie  Année Naissance Merise  Origine Inadéquation des méthodes comme MINOS ou CORIG aux préoccupations actuelles et à la génération des traitements 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 niveaux Conceptuel - 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. 

13 Merise version.2 Vous êtes ici : Partie I > Naissance de Merise
 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  Apports Un 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 organisationnel Prise en compte des structures, des moyens matériels et humains C.N.A.M UV B1 : présentation du 22 mars 2004

14 Merise OOM Vous êtes ici : Partie I > Naissance de Merise
Né en 1992 Orientée objet- Comporte une dimension fonctionnelle. Diagramme de contexte - Diagrammes de flots de données. Modèle entité-association C.N.A.M UV B1 : présentation du 22 mars 2004

15 Vous êtes ici : Partie I > Apparition des modèles Objets
Apparition des modèles Objets - Période avant U.M.L. Guerre des notations La méthode O.M.T. était bien adaptée à l’analyse mais peu à la conception C.N.A.M UV B1 : présentation du 22 mars 2004

16 Les quatre modèles de base de O.M.T.
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 Etat Etat N Objet A Les quatre modèles de base de O.M.T. C.N.A.M UV B1 : présentation du 22 mars 2004

17 Vous êtes ici : Partie I > Apparition des modèles Objets
Au contraire de la méthode Booch 1991, mieux adaptée à la conception qu’à l’analyse : Diagramme de transition Nom Diagramme des classes Nom Diagramme de temps Objet 1 Objet 2 Objet N Cycle de vie des objets Etat Diagramme de transition d’état Evénement Etat1 Etat2 Diagramme de transition d’état Regroupement de classes et objets en modules 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. C.N.A.M UV B1 : présentation du 22 mars 2004

18 Création d'U.M.L. Vous êtes ici : Partie I > La création d ’U.M.L.
La genèse d’U.M.L. Booch Harel Rumbaugh Odell U.M.L Jacobson Shlaer-Mellor Gamma et al. Mayer Embly Fusion Wirfs-Brock C.N.A.M UV B1 : présentation du 22 mars 2004

19 Vous êtes ici : Partie II > Introduction
SOLUTION 1 Ré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. C.N.A.M UV B1 : présentation du 22 mars 2004

20 Quel menu alléchant, n ’est-ce pas camarades auditeurs !!!
Vous êtes ici : Partie II > Plan Les principes Merisiens * l ’approche systémique * les cycles du processus * l ’approche fonctionnelle * l ’approche données / traitements * l ’approche par les messages La modélisation du métier * 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 !!! C.N.A.M UV B1 : présentation du 22 mars 2004

21 En ce sens, Merise est une méthode orientée systémique.
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. C.N.A.M UV B1 : présentation du 22 mars 2004

22 Vous êtes ici : Partie II > Approche systémique
Cas d ’utilisation de la gestion commerciale et scénarios associés C.N.A.M UV B1 : présentation du 22 mars 2004

23 Vous êtes ici : Partie II > Approche systémique
Ce qu ’il faut retenir... L ’approche par les cas d ’utilisation constitue une approche systémique. C.N.A.M UV B1 : présentation du 22 mars 2004

24 Vous êtes ici : Partie II > Les cycles du processus
Cycle d'abstraction Traitements 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 vie Mort Maturité Naissance Gestation Cycle de décision Contenu Développement Technique Organisation Découpage en lots Affectation des ressources Gestion Planning Identification Les cycles de Merise C.N.A.M UV B1 : présentation du 22 mars 2004

25 Vue des cas d'utilisation
Vous êtes ici : Partie II > Les cycles du processus Cycle de vie : 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 : 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. C.N.A.M UV B1 : présentation du 22 mars 2004

26 Vous êtes ici : Partie II > Les cycles du processus
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. C.N.A.M UV B1 : présentation du 22 mars 2004

27 Vous êtes ici : Partie II > Les cycles du processus
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). C.N.A.M UV B1 : présentation du 22 mars 2004

28 L ’approche fonctionnelle est une spécificité Merisienne
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 C.N.A.M UV B1 : présentation du 22 mars 2004

29 Vous êtes ici : Partie II > L ’approche fonctionnelle
Représentation du virage vers l ’objet après l ’étude des uses cases système Cas 1 Cas 2 Cas 3 Fonction F Cas 2 B D C E H I J Cas 1 A G C.N.A.M UV B1 : présentation du 22 mars 2004

30 Cette différence impose que l ’informaticien « pense » autrement
Vous êtes ici : Partie II > L ’approche fonctionnelle Ce qu ’il faut retenir... 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

31 il s ’agit là d ’un point clé de différence
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 C.N.A.M UV B1 : présentation du 22 mars 2004

32 Vous êtes ici : Partie II > L ’approche par les messages
Diagramme de flux : Les processus du domaine commercial C.N.A.M UV B1 : présentation du 22 mars 2004

33 Vous êtes ici : Partie II > L ’approche par les messages
Diagramme d ’activités : Gestion globale des commandes C.N.A.M UV B1 : présentation du 22 mars 2004

34 Vous êtes ici : Partie II > L ’approche par les messages
Diagramme de séquences Cas d ’utilisation : Gestion d ’une nouvelle commande Scénario : Client existant et commande en cours dépassée C.N.A.M UV B1 : présentation du 22 mars 2004

35 Il est possible de rapprocher le diagramme de flux au :
Vous êtes ici : Partie II > L ’approche par les messages Ce qu ’il faut retenir... 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

36 On vous propose au menu la modélisation du métier :
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.). C.N.A.M UV B1 : présentation du 22 mars 2004

37 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Exemple 1 : C.N.A.M UV B1 : présentation du 22 mars 2004

38 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Exemple 1 : C.N.A.M UV B1 : présentation du 22 mars 2004

39 Le jeu des comparaisons, çà vous dit !
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Exemple 1 : Le jeu des comparaisons, çà vous dit ! C.N.A.M UV B1 : présentation du 22 mars 2004

40 Exemple 1 : Une entité = Une classe
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Exemple 1 : Une entité = Une classe C.N.A.M UV B1 : présentation du 22 mars 2004

41 Propriétés des entités = Attributs des classes
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Exemple 1 : Propriétés des entités = Attributs des classes C.N.A.M UV B1 : présentation du 22 mars 2004

42 Identifiant d ’entité = Attribut identifiant (ou clé) de la classe
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Exemple 1 : Identifiant d ’entité = Attribut identifiant (ou clé) de la classe C.N.A.M UV B1 : présentation du 22 mars 2004

43 Relation entre entités = Association entre classes
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Exemple 1 : Relation entre entités = Association entre classes C.N.A.M UV B1 : présentation du 22 mars 2004

44 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Exemple 2 : C.N.A.M UV B1 : présentation du 22 mars 2004

45 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Exemple 2 : C.N.A.M UV B1 : présentation du 22 mars 2004

46 Le jeu des comparaisons, on continue !
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Exemple 2 : Le jeu des comparaisons, on continue ! C.N.A.M UV B1 : présentation du 22 mars 2004

47 Une relation porteuse d ’informations = classe association
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Exemple 2 : Une relation porteuse d ’informations = classe association C.N.A.M UV B1 : présentation du 22 mars 2004

48 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Exemple 2 : Avec U.M.L., le nommage des rôles est possible pour toutes les relations C.N.A.M UV B1 : présentation du 22 mars 2004

49 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Exemple 3 : C.N.A.M UV B1 : présentation du 22 mars 2004

50 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Exemple 3 : C.N.A.M UV B1 : présentation du 22 mars 2004

51 Le jeu des comparaisons, C ’est bientôt fini, snif !
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Exemple 3 : Le jeu des comparaisons, C ’est bientôt fini, snif ! C.N.A.M UV B1 : présentation du 22 mars 2004

52 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Exemple 3 : L ’héritage est transformé en généralisation, qui va mener à la constitution d ’une hiérarchie de classes. C.N.A.M UV B1 : présentation du 22 mars 2004

53 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D.
Ce qu ’il faut retenir... 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

54 Le diagramme de classes ressemble à première vue au M.C.D.
Vous êtes ici : Partie II > Niveau Conceptuel > M.C.D. Ce qu ’il faut retenir... 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

55 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. Cycle de vie de l ’entité commande C.N.A.M UV B1 : présentation du 22 mars 2004

56 Vous êtes ici : Partie II > Niveau Conceptuel > Etats/Transitions
Diagramme d ’Etats/Transitions - Prise de commande C.N.A.M UV B1 : présentation du 22 mars 2004

57 C.N.A.M UV B1 : présentation du 22 mars 2004
Vous êtes ici : Partie II > Niveau Conceptuel > Etats/Transitions Ce qu ’il faut retenir... 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

58 Vous êtes ici : Partie II > Niveau Conceptuel > M.C.T.
Composant du M.C.T. : EVENEMENTS Dans U.M.L., les événements vont apparaître au niveau des diagrammes de séquences et d ’activités. Composant du M.C.T. : SYNCHRONISATION Dans U.M.L., les synchronisations vont apparaître dans les diagrammes d ’activités et d ’états/transitions. Composant du M.C.T. : OPERATIONS Dans U.M.L., les opérations vont être représentées dans les diagrammes d ’activités. C.N.A.M UV B1 : présentation du 22 mars 2004

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

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

61 Vous êtes ici : Partie II > Niveau Organisationnel > M.O.T.
Ce qu ’il faut retenir... 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

62 Vous êtes ici : Partie II > Synthèse
C.N.A.M UV B1 : présentation du 22 mars 2004

63 comparaison <> équivalence
Vous êtes ici : Partie II > Synthèse ATTENTION comparaison <> équivalence C.N.A.M UV B1 : présentation du 22 mars 2004

64 Réponse : il ne faut pas dissocier U.M.L et l ’approche objet
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 C.N.A.M UV B1 : présentation du 22 mars 2004

65 C ’est un facteur important de changement
Vous êtes ici : Partie II > Vers l ’ébauche d ’une nouvelle solution Vision du système Dans 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éveloppement Dans 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 C.N.A.M UV B1 : présentation du 22 mars 2004

66 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 C.N.A.M UV B1 : présentation du 22 mars 2004

67 PROJET PILOTE  Description du projet pilote
Vous êtes ici : Partie III > Plan 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 C.N.A.M UV B1 : présentation du 22 mars 2004

68 Application WEB mobile
Vous êtes ici : Partie III > Description du projet PILOTE Application WEB mobile Application Gestion Commerciale Liste Clients Ajout Nouveau Client Liste Commandes Ajout Nouvelle Commande PORTAIL INTRANET Autres applications de l’intranet C.N.A.M UV B1 : présentation du 22 mars 2004

69 Vous êtes ici : Partie III > Description du projet PILOTE
Règles de Gestion  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.

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

71 Sous-Système Gestion Commerciale Sous-Système Application Web Mobile
Vous êtes ici : Partie III > Modélisation métier et analyse des besoins Sous-Système Gestion Commerciale Acteurs primaires : Commercial Client Sous-Système Application Web Mobile Acteur primaire: Commercial Acteur secondaire: Technicien C.N.A.M UV B1 : présentation du 22 mars 2004

72 Diagramme des cas d’utilisation de la gestion commerciale
Vous êtes ici : Partie III > Modélisation métier et analyse des besoins Diagramme des cas d’utilisation de la gestion commerciale

73 Diagramme des cas d’utilisation du système "application mobile"
Vous êtes ici : Partie III > Modélisation métier et analyse des besoins Diagramme des cas d’utilisation du système "application mobile" C.N.A.M UV B1 : présentation du 22 mars 2004

74 Diagramme des activités de la gestion commerciale
Vous êtes ici : Partie III > Modélisation métier et analyse des besoins Diagramme des activités de la gestion commerciale C.N.A.M UV B1 : présentation du 22 mars 2004

75 Identification des classes et des objets COMMERCIAL COMMANDE CLIENT
Vous êtes ici : Partie III > Analyse et Conception Identification des classes et des objets COMMERCIAL COMMANDE CLIENT LIGNE DE COMMANDE FOURNISSEUR PRODUIT C.N.A.M UV B1 : présentation du 22 mars 2004

76 Vous êtes ici : Partie III > Analyse et Conception
Diagramme de séquences des « commandes disponibles » C.N.A.M UV B1 : présentation du 22 mars 2004

77 Vous êtes ici : Partie III > Analyse et Conception
Diagramme de séquences « Gestion en mode déconnecté » C.N.A.M UV B1 : présentation du 22 mars 2004

78 Vous êtes ici : Partie III > Analyse et Conception
Diagramme de collaboration pour la « Gestion commerciale » C.N.A.M UV B1 : présentation du 22 mars 2004

79 Vous êtes ici : Partie III > Analyse et Conception
Diagramme d'états-transitions global de la « Gestion commerciale » C.N.A.M UV B1 : présentation du 22 mars 2004

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

81 Vous êtes ici : Partie III > Analyse et Conception
Diagramme de classes du système « Gestion Commerciale » C.N.A.M UV B1 : présentation du 22 mars 2004

82 Vous êtes ici : Partie III > Implémentation, Tests et Déploiement
Diagramme des composants du système C.N.A.M UV B1 : présentation du 22 mars 2004

83 Vous êtes ici : Partie III > Implémentation, Tests et Déploiement
Diagramme de déploiement du système C.N.A.M UV B1 : présentation du 22 mars 2004

84 Commande.java Client.java
Vous êtes ici : Partie III > Implémentation, Tests et Déploiement 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 ; 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(){ Commande.java Client.java C.N.A.M UV B1 : présentation du 22 mars 2004

85 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. C.N.A.M UV B1 : présentation du 22 mars 2004

86 Vous êtes ici : Conclusion générale
Changement de vision du système Mise en œuvre d ’un processus de développement Plan de formation Stratégie de migration technique Mise en place d ’un projet PILOTE Et après ? C.N.A.M UV B1 : présentation du 22 mars 2004

87 Avez-vous des questions
Vous êtes ici : Questions Avez-vous des questions camarades auditeurs ? C.N.A.M UV B1 : présentation du 22 mars 2004


Télécharger ppt "Comment réussir la transition pour une entreprise ?"

Présentations similaires


Annonces Google