Cas Soncas

d’abstraction. UML est fortement inspiré de l’approche 4+1 vues (logique, composants, processus, déploiement et cas d’utilisation) indépendantes définies par P. Kruchten pour exprimer les diverses perspectives de l’architecture d’un système informatique. UML se compose d’une part des éléments de modélisation qui représentent toutes les propriétés du langage et d’autre part des diagrammes (de cas d’utilisation, de classes, d’objets, d’états-transitions, d’activités, de séquence, de collaboration, de composants

...... 43 FIGURE 14 : MODELISATION DES DONNEES REALISEE AVEC DBDESIGNER ................................. 48 FIGURE 15 : MODELISATION DES DONNEES SIMPLIFIEE.............................................................. 49 FIGURE 16 : DIAGRAMME DES CAS D'UTILISATION REALISE AVEC ARGOUML ........................... 50 FIGURE 17 : ARCHITECTURE RETENUE POUR L’APPLICATION RENDEZ-VOUS ............................. 53 FIGURE 18 : ARCHITECTURE DE SPRING ..................................................

points de vue et diagrammes • cas d'utilisation, analyse, conception, implémentation 2) Le diagramme des cas d’utilisations • acteur • cas d'utilisation et scénario 3) Notion de classes et objets et leur diagramme • introduction aux classes, aux objets • notion de relation, de composition et d'héritage • recherche d'un diagramme de classes à partir du cahier des charges 4) Modèle dynamique • diagramme de séquences, de collaboration, d' et d' état activité • réalisation des cas d' utilisation par les diagrammes

extension a surtout été inspirée par les besoins des domaines des télécoms, qui doivent exprimer finement des protocoles. Guide de la modélisation UML 15  Les diagrammes de classes ont bénéficié de quelques extensions Dans une grande majorité de cas, ceux-ci restent inchangés par rapport à UML1.4. Lorsque des besoins de modélisation architecturale apparaissent, alors de nouvelles notions sont utilisées, comme par exemple les composants, les parts et les ports Guide de la modélisation UML

................................................................ 2 1.2UP est centré sur l'architecture...................................................................................................................... 2 1.3UP est piloté par les cas d'utilisation d'UML.................................................................................................. 2 2VIE DU PROCESSUS UNIFIÉ........................................................................................................

* Les diagrammes de flots de UML n'ont jamais été bien expliquée * La méthode est trop près du programme La méthode OOSE : Object Oriented Software Engineering * Une méthode pour l'analyse initiale des usages de logiciel, fondée sur les "Cas d'utilisation" (Use case) La méthode Objecteering: Une méthode orientée objet * Populaire car elle était associée à un outil de "design", capable de générer du code L’UML * Fusion de OOA / OOSE / OMT * Un standard de l' OMG * Couvre

COMPORTEMENT COMPORTEMENT ATTENDU Pour démontrer sa compétence, le stagiaire doit spécifier fonctionnellement une application selon les conditions, les critères et les précisions qui suivent. CONDITIONS D’EVALUATION • Epreuve écrite de type étude de cas CRITERES GENERAUX DE PERFORMANCE • Utilisation des commandes appropriées. • Respect du temps alloué. • Respect des règles d’utilisation du matériel et logiciel Informatique. 3 OBJECTIF OPERATIONNELS DE PREMIER NIVEAU DE COMPORTEMENT PRECISIONS

diagramme de cas d’utilisation (Use case diagram) – diagramme d’activités (Activity diagram) – diagramme d’états-transitions (State machine diagram) – Diagrammes d’interaction (Interaction diagram) – diagramme de séquence (Sequence diagram) – diagramme de communication (Communication diagram) – diagramme global d’interaction (Interaction overview diagram) – diagramme de temps (Timing diagram)  Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes : d’activités, de cas d’utilisation

Acteurs humains 34 Acteurs système 34 Le diagramme de cas d’utilisation « Réservation » 35 Description du cas d’utilisation « Réservation » 36 Bloc « Gestionnaire » 36 Le diagramme de cas d’utilisation « Gestionnaire » 36 Description du cas d’utilisation « Gestionnaire » 37 Bloc « Administrateur » 37 Le diagramme de cas d’utilisation « Administration » 37 Identification des rôles 38 Cas d’utilisation 39 Cas d’utilisation Global 39 Cas d’utilisation Détaillé 40 Diagramme de Classe d’Analyse :

acteurs Acteur interne (acteur du logiciel) agents chef de service DRH administrateur Acteur externe paye 1 Diagramme des cas d'utilisation Ce diagrame est un diagramme statique qui étudie le lien entre les acteurs (internes) et les actions Le cas de l'administrateur qui attribue les droits correspond à un cas de paramétrage et n'est pas traité dans ce diagramme 2 Description des Cas d'utilisation Nous présentons ici notre fonctionnement actuel assortie de critique car nous nous appuyons sur un logiciel