formation industrialisation as france uml - conception fonctionnelle

Formation Industrialisation AS France

UML - Conception fonctionnelle

Formation Industrialisation AS France Title

Introduction

A la fin de la session je dois être capable de :

Traduire un cahier des charges en concepts UML

Utiliser : • les diagrammes de cas d’utilisation• les diagrammes de séquence• les diagrammes d’activité• les diagrammes d’état-transition• les diagrammes de classe

Utiliser l’outil Magic Draw

Présentation du formateur

FOR INTERNAL USE ONLY. © 2010 Capgemini. All rights reserved. 2

Objectifs de la formation

Formation Industrialisation AS France Title

Présentation des participants

Vos attentes ?

3FOR INTERNAL USE ONLY. © 2010 Capgemini. All rights reserved.

Formation Industrialisation TS FranceTitle

Quiz - UML c’est : ? Un langage de programmation

Une aide pour modéliser

Un nom d’avion motorisé ultraléger

Un guide pour faire des petits dessins

ü

ü


Quiz - Utiliser UML c’est garantir : ? Une meilleure structuration de l’information

Moins de problèmes de barrière de langue

Que le logiciel correspond aux besoins du client

üü

Des intégrations régulières


Quiz - RUP c’est : ? Une inscription dans les cimetières anglophones qui signifie « Rest Under Peace »

Une méthode de conception

Un logiciel de modélisation

ü

Une implémentation de UPü


Déroulement de la formation

Première demi-journée• Introduction• Vue d’ensemble• Le génie logiciel• Recueil des besoins• Analyse

Deuxième demi-journée• Compléments• Synthèse• Cas pratique

Troisième demi-journée• Cas pratique (Suite)• Clôture


Vue d’ensemble

Le génie logiciel

Recueil des besoins

Analyse

Compléments

Synthèse

Sommaire


- Le modèle est pérenne, et les notations aussi.- La vision du système est partagée grâce au fait :

- Que tout le monde voit la même spécification- Que tout le monde contribue à faire évoluer le modèle en introduisant sa propre vision

- UML est une notation de plus en plus répandue (connue, enseignée, supportée par les outils…).- UML permet de répartir simplement le travail de spécification sur de nombreuses personnes.- Il n’est pas nécessaire d’avoir des compétences

métier pour manipuler des diagrammesUML : fonctionnels et développeurs ontun langage commun.

- Même les plus gros projets peuvent êtrespécifiés et maintenus en UML.

- Formaliser en UML permet - De préciser sa pensée,- De pousser les intervenants à communiquer

et à partager leurs connaissances,- D’éviter d’instaurer des gourous.

Avantages de la modélisation avec UML


Vue d’ensemble

Le génie logiciel

Recueil des besoins

Analyse

Compléments

Synthèse

Sommaire


Les différents cycles de vie

Des cycles linéaires et des cycles itératifs Des ‘cycles longs’ et des ‘cycles courts’ Ne pas hésiter à faire évoluer le cycle et à les combiner

Cycleslongs

Linéaires

Cyclescourts

Itératifs

Cascade

V Y

RAD

XP

Itératif

Rapid prototyping(Robert Balzer)

Scrum


Activité

Test unitaires

Exg.

Spec.

Conc.

Code

DTV

DTU

Doc

Composant

Logiciel

Produit

Chronologie

E/S

Spec.log.

Intégration

Validation

Analyse log.

Conception

DDI

Cycle de vie linéaire Capgemini : le cycle en V de l'AFCIQ

DTV : Dossier de tests de validationDTU : Dossier de tests de unitairesDDI : Dossier de définition d’interface


Cycle de vie en V : B’s

–Modèle éprouvé car calqué sur la production industrielle classique :· permet l'organisation du travail et des équipes => prédiction (Cocomo) et

contrôle des coûts facilités· favorise la décomposition hiérarchique fonctionnelle· propose des étapes clés (documentation, revues) => bon suivi du projet· permet de garantir une certaine qualité (plan assurance qualité)· existence de standards (MIL-STD-498, GAM-T17(V2), Do 178 B, STAN-CS 055,

ESA, ...)· adapté à de grands projets

–Beaucoup d'outils support.


Cycle de vie en V : C’s

–Hypothèses peu fondées : séquentialité des phases non conforme à la réalité– Incapacité à prendre en compte des évolutions du cahier des charges durant la

construction du système–Absence de vérification et validation à la fin de chaque étape–Absence d'une continuité des outils – Inadapté aux systèmes non fonctionnels–La production de documents ne limite pas beaucoup l’effet tunnel–Peu ou pas de possibilité de maquettage et/ou de prototypage.

Définitions (Boehm 76):

- Validation: « Am I building the right system? »

- Verification: « Am I building the system right? »


Vue opérationnelle

Pilo

tage

Developpement

Fonctionnel

Méthodes

Architecture physique

Architecture conceptuelle

Architecture logique

Collecte d’exigences

Analyse

Codage et tests unitaires

Recette

Déploiement

Exploitation Maintenance

Intégration

Conception applicative générale

Architecture

Conception technique détaillée

Assurer la convergence des branches

Maîtriser la profondeur des documents

Assurer la compréhension des utilisateurs

Retranscrire fidèlement le besoin

Assurer la pérennité des solutions

Analyser les éléments structurants du dimensionnement de l’architecture

Ajustement


Cycle de vie en Y

Sépare les analyses fonctionnelles et techniquesB’s

• Mis en œuvre chez Capgemini• Détecte les conflits technique / fonctionnels au plus tôt• Peut s’intégrer dans les autres cycles de vie• Particulièrement adapté aux nouvelles technologies et à l’utilisation

de COTS• Utilise toutes les compétences métiers dès le démarrage du projet

C’s• Impose de définir la totalité des besoins dès le départ• L’organisation du projet doit être adaptée• Rarement appliqué en l’état


Les méthodes agiles (RAD, XP, Scrum…)

Basé sur le principe qu’il vaut mieux adapter que prédire

Personnes et interactions Procédures et outils

Applications fonctionnelles Documentation pléthorique

Collaboration avec le client Négociation de contrat

Acceptation du changement Planification

Faire vite et simple plutôt que beau et hi-tech Implication permanente du client Communication directe maximale (client, équipes…) Motivation des individus Respect des règles de qualité (code clair et robuste)

Ne pas confondre agilité et bricolage : ces méthodes nécessitent beaucoup de compétence, de rigueur et de motivation sans quoi elles mènent droit dans le mur!

A privilégier A éviter


Les méthodes agiles (RAD, XP, Scrum…)

B’s :• Plus d’effet tunnel (présence du client et livraisons fréquentes)• Forte capacité à s’adapter aux changements de spécification

C’s :• Faiblesse de la documentation (difficulté de transfert du projet à une autre

équipe)• Fortes capacités relationnelles exigées des développeurs (entre eux et avec le

client)• Souvent inadapté aux gros projets• Formation et rigueur imposée aux acteurs• Planification et estimations de charge difficiles


Cycle de vie itératif de Capgemini : Unified Process La vie d’un projet UP se décompose en une série de cycles. A un cycle correspond une

livraison. Une livraison contient le résultat des activités menées pendant le cycle Ces activités sont de différentes sortes :

• Modèles métier, • Requirements, • ….

Comment segmenter les itérations Débuter petit. Une itération trop grosse diminue la visibilité du CdP et les possibilités

d’adaptation (l’adaptation en cours d’itération n’est pas souhaitable) Partir des exigences stables. Le client doit sélectionner les exigences les plus abouties. Ne pas commencer par l’IHM principale mais par les systèmes tiers (communications

avec les SGBD / autres systèmes informatiques). l’IHM principale impose en général de produire de nombreuses briques élémentaires et constitue un des les plus lourds (sans être forcément la plus stable).

Un cycle RUP est-il constitué de N cycles en V?


Cycle de vie itératif de Capgemini : Unified Process-suiteSpécificités de UP Itératif et incrémental

• Un projet est divisé en itérations : une itération est constituée des mêmes étapes

• Une itération prend en compte un ou plusieurs cas d’utilisation • Pour concevoir les itérations le critère de choix c’est d’abord l’élimination

des risques• On essaie de faire en sorte que les itérations finissent par être des additifs

Piloté par les cas d’utilisation• Un cas d’utilisation est une fonctionnalité du système offrant un résultat

tangible pour l’utilisateur• L’utilisateur peut être un être humain, mais un système externe • Les modèles décrivent la réalisation d’un cas d’utilisation

Centré sur l’architecture• L’architecture doit permettre de réaliser les cas d’utilisation• L’architecture et les cas d’utilisation doivent évoluer de concert (on retrouve

les deux branches du Y du cycle en Y) • L’architecte doit avoir une compréhension globale des cas d’utilisation

S’appuie sur UML

RUP est uneInstanciation d’UPpar Rational / IBM


Les activités

Les phases

Temps

UML et le processus

A la fin de l’iteration E1, on livre des documents/constructions concernant : Le business modeling requirements analysis and design Implementation Tests Le déploiement La gestion de configuration La gestion de projet Environnment


Architecture RUP : Le modèle 4+1 vues

Vue processus

Vue de déploiement

Vue logique Vue d’implémentation

Développeurs Management logiciel

Performance‘Scalability’, Concurrence, Bande passante, Parallélisme…

Intégrateurs systèmeTopology du système

Delivery, installationCommunication

Ingénieurs système

Vue des cas d’utilisation

Structure

Analystes/Concepteurs Utilisateur

Fonctions

Une Vue est une description complète (une abstraction) d’un système dans une perspective ou un point de vue particulier – présentant des considérations et en omettant d’autres qui ne sont pas pertinentes pour cette perspective.Différentes ‘vues’ d’intervenants différents => des objectifs différents.Un Modèle est une représentation complète. Les modèles sont constitués de vues.

Functional requirements

Vue logique ViewExigences fonctionnelles

Traite la conception, paquetages, sous- systèmes, classes, couches, …

Vued’implémentationTraite surtoutl’organisation et laprogrammation desmodules statiques etdes tests unitaires


Synthèse des cycles de vie Il faut adapter les cycles de vie au projet

• Un projet peut mixer ou paralléliser plusieurs cycles de vie :o Sur le projet ODS, un prototype a été réalisé dans l’esprit ‘méthodes agiles’ tandis que le reste des livraisons

s’appuient sur un panachage ‘cycle en V’/’itératif’o Attention par contre à ne pas changer de cycle en cours de réalisation (entraine une perte de visibilité du chef

de projet, une confusion du client…)

Analyse/conception• RUP ne distingue pas clairement analyse et conception• En anglais “design” a une connotation plus technique. Sa traduction, "conception", doit donc

désigner uniquement la conception technique.• Une convention commune mais pas universelle

o Analyse se limite à la conception des éléments essentielso Conception effectue des choix d’implémentation

• Pas universelo On peut faire de la conception fonctionnelle (exemple domain-driven design)

Retenons :• Cahier des charges ou de besoins = spécification externe• Analyse = modèle des objets du domaine :dossier de cadrage et spécifications internes• Conception = terme réservé à l’implémentation


Vue d’ensemble

Le génie logiciel

Recueil des besoins

Analyse

Compléments

Synthèse

Sommaire


Gestion des exigences

Fonctionnelles

Non fonctionnelles

• Maîtrise des risques

• Maîtrise des coûts

Matrice de traçabilité

Exemple étude de cas


Propriétés communes aux exigences

Selon la norme IEEE 830, un référentiel d’exigences doit être :

• Correct• Non ambiguë• Complet• Cohérent• Catégorisé• Vérifiable • Modifiable• Traçable


Facteurs qualité externes du logiciel (B. Meyer)

Validité : aptitude d'un produit logiciel à réaliser exactement les tâches définies par sa spécification

Robustesse : aptitude d'un logiciel à fonctionner même dans des conditions anormales Extensibilité : facilité d'adaptation d'un logiciel aux changements de spécification Réutilisabilité : aptitude d'un logiciel à être réutilisé en tout ou partie Compatibilité : aptitude des logiciels à pouvoir être combinés les uns aux autres Efficacité : aptitude d'un logiciel à bien utiliser les ressources matérielles telles la mémoire,

la puissance du CPU, etc. Portabilité : facilité à être porté sur de nouveaux environnements matériels et/ou logiciels Traçabilité : capacité à identifier et/ou suivre un élément du cahier des charges avec un

composant d'un logiciel Vérifiabilité : facilité de préparation des procédures de recette et de certification Intégrité : aptitude d'un logiciel à protéger ses différents composants contre des accès ou

des modifications non autorisés Facilité d'utilisation : ...


Exercice

Déduisez des exigences de ces besoins :

• L’IHM du logiciel doit aller vite.• Le logiciel devra interagir avec des personnes en situation de handicap.• Les résultats semestriels ne sont accessibles qu’aux responsables de centre.• Notre voiture doit avoir un régulateur de vitesse robuste.• La gestion de mémoire de notre système d’exploitation doit être plus efficace

que celle de Windows.• Ce nouveau logiciel de paye doit être aussi complet que le précédent mais

coûter moins cher.

INES


Principes de traçabilité au cours du projet

OU

REPONSES NIV1

c

Exigences

Matrice de couverture

Matrice de couverture

Demande

Modification Propale

Cahier

des

Charges Spec . B

Spec . A Dossier

Conc .

Gen . Spec . D

Spec . C Dossier

Conc .

Det. .

NIVEAU 0 : EXIGENCES NIVEAU 1 : CONCEPTION GEN. NIVEAU 2: CONCEPTION DET.

REPONSES NIV2

c

Exigences

Plan de

Tests

Matrice decouverture


Principe de la traçabilitéDocument d’exigences

Document de réponses


Règles appliquées aux identifiants

L’identifiant de tout type d’exigences doit répondre aux règles suivantes:• Utilisation du style Req_ID • Nommenclature précise décrite ci-dessous:

R07289-CDC-BPR-010_11

[..] Champ optionel

[<IdProjetDoc>]-<TypeDoc>-<Decoupage>-< Reference>

Groupe Description Format

[<RefDoc>] Identifiant du document Optionel: ensemble de chiffres et/ou de caractères (non limité en nombre)

<TypeDoc> Type de documentEnsemble de chiffres et/ou de caractères (non limité en nombre)

<Decoupage>Ensemble de chiffres et/ou de caractères (non limité en nombre)

<Reference> Nombre à plusieurs chiffres initialiement numéroté de 10 en 10. Possibilité d’ajouter un second groupe de chiffres

Ensemble de chiffres et/ou de caractères (non limité en nombre)Possibilité de suffixer par – ou _

Peut être relatif à un domaine, une fonction…

Pour approfondir les sujets liés à la traçabilité, reportez vous à la formation :Gestion des exigences - Reqtify


La méthode

Si nécessaire, un diagramme d’activité peut précéder cette méthode pour situer la demande du client dans son processus métier global.


Principes de présentation des notations UML

Définition des conceptsPrésentation des notations

• point de vue syntaxique• point de vue sémantique

Règles de Vérification et Validation (V&V)Commentaires sur un exemple


Remarques sur les diagrammes d’activités

Niveau global (modélisation du métier du client)• donne une vue macroscopique de l’enchaînement des fonctionnalités• correspond à la traditionnelle décomposition hiérarchique fonctionnelle

Niveau simple (modélisation technique d’une méthode)• permet, pour un objet donné, d’exprimer graphiquement une activité du

diagramme d’état en un algorithme• traduction directe possible dans un langage de programmation OO (Java, C++,

…)• l’outil Rapsodhy d’iLogix permet cela


Diagrammes d’activité : vue globale


Diagrammes d’activités : les actions et le contexte

Stéréotype • aucun pour l’action,• « localPrecondition » et « localPostcondition » pour le

contexteRôle

• représente la réalisation d’une action métier du processus métier du client

• les pré et post conditions sont optionnelles

Règle de V&V • les actions doivent être validées par le client• au plus une pré condition et un post

condition par action

Sélectionnerla boisson

Sélectionner la boisson

<<localPrecondition>>Machine en attentede commande

<<localPostcondition>>Boisson sélectionnée

Envoyer stock machine

Recevoir prix à appliquer


Diagrammes d’activités : transitions et nœuds

Stéréotype • aucun

Rôle • une transition représente un passage d’un action à la suivante.• l’état initial est le point de départ de la lecture du diagramme, un point

final identifie sa fin• le point d’arrêt de flux correspond, dans un diagramme parallélisé, à la

fin d’un des traitements parallélisé mais pas sans terminer le processus ‘père’

• un nœud conditionnel permet de définir plusieurs possibilités de fonctionnement

Règle de V&V • un flux connecte toujours deux éléments du diagramme• toujours un état initial et au moins un état final par diagramme• chaque flux partant d’un nœud décisionnel doit porter des conditions

qui doivent décrire l’intégralité de l’espace des solutions

Sélectionner la boisson

[fini]

[autres process en cours]


Diagrammes d’activités : synchronisation, couloirs d’activités

Stéréotype • aucun

Rôle • Synchronisation : permet la

parallélisation des traitements• Couloirs : permet l’affectation

des traitementsà des responsables différents

• Les deux concepts sont indépendants

Règle de V&V • ne pas lier deux activités qui

ont été parallélisées

Machine à caféServeur

Préparer un verre

Doser le sucre Doser le café

Verser les ingrédients

Lancer la machine à café

Préparer les croissants


Dia

gram

me

d’ac

tivité

sim

ple

set up order

assign seats

assign seats

awardbonus

debit account

chargecredit...

mail packet

Que veut-il dire?


Présentation générale de MagicDraw


Exercice : modélisation d’un téléphone portable

Un fabricant de téléphone portable souhaite réécrire ses spécifications en utilisant UML. Traduisez le texte suivant en diagramme d’activité.

Pour utiliser le téléphone il faut d’abord le sortir de sa housse puis l’ouvrir. L’utilisateur compose ensuite le numéro. Lorsque son correspondant décroche il peut engager la conversation. Si le forfait arrive à expiration, la communication est coupée. Sinon l’utilisateur raccroche en fin de communication.


BPMN (Business Process Modeling Notation)

Standardisé par l’OMG et très proche des diagrammes d’activité UML. UML = très complet et orienté objet => rejet de certains clients. BPMN = expression plus simple de la dynamique des processus => mieux

accepté. Plus d’informations disponibles sur :

• http://www.bpmn.org/Documents/Introduction%20to%20BPMN.pdf

http://www.bpmn.org/Documents/Introduction%20to%20BPMN.pdf

http://www.omg.org/bpmn-logo/


Vue d’ensemble

Le génie logiciel

Recueil des besoins

Analyse

Compléments

Synthèse

Sommaire


Les diagrammes de cas d'utilisation - Généralités

Composent les itérations des cycles UP Permet de représenter le comportement d'un système vu du côté utilisateur Très utile en phase d'analyse des besoins car structure les besoins des

utilisateurs finals Traduit une spécification d'utilisation du système Correspond partiellement à une décomposition fonctionnelle du système Met en évidence les dialogues avec le système Permet de concevoir un système robuste Permet de répartir les fonctionnalités de l’application aux différents

membres de l’équipe de production et de déterminer ainsi « Qui fait quoi »


Diagrammes de cas d’utilisation : vue globale


Cas d'utilisation – les Concepts

Les acteurs Les cas d'utilisationLes relations entre acteurs et cas d'utilisationLes relations entre acteursLes relations entre cas d'utilisationLes paquetagesPérimètre du système


Les acteurs Stéréotype

• <<acteur>>

Rôle • élément extérieur au système ET interagissant avec le système

Peut être un humain ou un système ou une réglementation ou ….• acteur principal (ex. client)• acteur secondaire (ex. agent de maintenance)• matériel externe (ex. dispositifs indispensables au fonctionnement

du système)• système externe (ex. SGBD ou BD)

Nécessite une description précise et concise Règle de V&V

• tout acteur doit communiquer avec le système

NB : la présence d'acteurs ne communiquant pas avec le système est tolérée si cela facilite la lisibilité !


Cas d'utilisation (Use case : UC)

Stéréotype• aucun

Rôle• représente un (ensemble de) service(s) rendu(s) par le

système• est assimilé à une fonction (macroscopique ou

microscopique)• intervient tout au long du cycle de vie

Règle de V&V • un cas d'utilisation est toujours en relation soit avec un

acteur soit avec un autre cas d'utilisation• un UC en tant que fonction est traduit par un verbe

d'action correspondant à une notion de traitement

NB : une fonctionnalité (UC) isolée traduit une erreur de conception !


Règle de base:Le recueil de besoins doit lever toute ambiguïté sur l’analyse et la conception.

Le niveau de détail doit être aussi poussé que nécessaire, d’un point de vue métier Comment gérer ce niveau de détail:

• Ne pas nuire à la clarté en parsemant la description de détails• Mettre en commun les règles de gestion générales, avec détails nécessaires• Créer un glossaire des concepts communs, avec détails nécessaires• Établir un modèle objet préliminaire (orienté données)

Cas d’utilisation : quel niveau de détail?

Utiliser la voiture Démarrer la voiture

Tourner la clé de contactAlimenter le démarreur


Relation entre acteurs et cas d'utilisation

Stéréotype• <<communicate>>

Rôle• représente une communication (signal et données) entre

acteur et UC • directionnelle ou pas• représente l'ensemble de TOUS les dialogues possibles et

imaginables entre l'acteur et le cas d’utilisation, i.e. représente l’ENSEMBLE de tous les scénarios nominaux ET non nominaux

Règle de V&V• doit traduire un dialogue

NB : les scénarios permettent de déterminer a priori la robustesse du système


Relation entre acteurs ou cas d’utilisations

Rôle• la généralisation/spécialisation

représente une notion d’héritage : tout ce que sait faire le père, le fils sait aussi le faire

• ici, pour valider le moyen de paiement, on a trois procédures possibles : vérification de chèque, vérification de carte bleue, vérification de faux billet

Règle de V&V • B est un cas particulier de A

NB : à l’extérieur du périmètre du système (entre acteurs) seules les relations d’héritage sont possibles


Relations entre Cas d'Utilisation – include

Stéréotype• <<include>>

Rôle• relation d'inclusion traduisant une obligation et

indiquant la réutilisation d’une autre fonctionnalité• D contient l’ensemble du comportement de C. • Quand on fait une commande sur la Redoute.fr on

doit valider le moyen de paiement (contrôle carte bleue).

Règle de V&V • tout cas d'utilisation doit avoir au moins une relation

avec une autre cas d'utilisation ou avec un acteur

NB : les relations entre UC correspondent à des demandes de service mais il n'y a pas d'ordre comme dans un graphe d'appels de fonction


Relations entre Cas d'Utilisation – extend Stéréotype

• <<extend>> Rôle

• il s’agit d’une relation d’extension non obligatoire : B n’intervient dans le fonctionnement de A que sous certaines conditions.

• Les deux use cases nécessitent d’être loggé mais on ne se logge que si on n’est pas déjà loggé.

• L’ « extension point » décrit la condition d’inclusion.

Règle de V&V • tout cas d'utilisation doit avoir au moins une

relation avec une autre cas d'utilisation ou avec un acteur

• l’utilisateur est connecté au moins avec le cas d’utilisation étendu


Paquetage Stéréotype

• aucun Rôle

• sert à délimiter le système et ses sous-systèmes

• Permet de déterminer les frontières du système

Règle de V&V• aucun paquetage vide !• nombre de relations intra-paquetage

plus important que les relations inter-paquetage (notion de cohésion forte des use cases d’un paquetage)

NB : tous les éléments ne faisant pas partie d'un paquetage sont externes au système ou sous-système considéré


Exercice - suite : modélisation d’un téléphone portable

Notre fabricant souhaite maintenant convertir le texte suivant en diagramme de cas

d’utilisation.

La principale utilisation du téléphone portable est la communication via le réseau

GSM. Cette communication s’obtient en composant un numéro. Il est possible de

stocker ce numéro dans le répertoire et de consulter la liste des derniers appels.

La sonnerie peut être paramétrée par l’utilisateur.


Validation des spécifications

En interne :• Établir une matrice de traçabilité par rapport aux exigences fonctionnelles du

cahier des charges• Contrôler la complétude de cette matrice.

En externe :• Les dossiers décrivant les interfaces du système sont-ils corrects? Comportent-

ils toutes les interactions?• Les maquette des interfaces IHM sont-elle satisfaisantes?• Les acteurs sont-ils tous représentés ?• L’utilisateur est-il satisfait des séquences présentées ?• Y a-t-il des cas d’utilisation manquants ?• Les cas présentés font-ils tous partie du système ?• Les liens sont-ils tous représentés ? Est ce qu’il en manque ?


Exercice : Trouvez les acteurs

Le système à construire est souligné. Mais quels sont ses acteurs? Notre système de camion à pizza vend des pizzas à des consommateurs

en utilisant des produits qui sont achetés chez un grossiste. Il vend aussi du vin italien acheté chez un producteur

Le distributeur automatique de billets est alimenté régulièrement par la société ‘l’écureuil’ afin de distribuer des billets à ses clients

Nous devons construire un standard téléphonique automatique qui réagit aux appelants

La station service distribue à ses clients les carburants qui lui ont été livrés. Elle fournit tous les trimestres un relevé de ses ventes.

Je suiscaché


Détermination de la robustesse du système : les scénarii Ne font pas partie d'UML. Ils alimentent

• les descriptions dynamiques du système (diagrammes d’intéraction UML)• les scénarii de test

Toute relation de communication entre acteur et UC doit être interprétée comme représentant TOUS les dialogues possibles et imaginables entre l’acteur et l’UC considérés

Il faut donc• identifier la relation (par exemple lui donner un numéro)• identifier tous les événements possibles au sein de ce dialogue• associer à chaque événement un scénario• distinguer les scénarios nominaux (ce qui est attendu) des scénarios non nominaux (ce qui peut

arriver et peut poser problème)• montrer que les cas nominaux et les cas non nominaux partitionnent l'espace des cas possibles

En pratique un scénario est représenté par• un contexte (les hypothèses)• une séquence de triplets : date, événement, action (ou réaction ou traitement) du récepteur du signal

Important• il faut énumérer tous les scénarios et les décrire par une phrase discriminante et très courte• inutile de décrire complètement les scénarios


Diagrammes de séquences – les Concepts

Sens de lecture• vertical : représente la ligne de vie des objets et les périodes d'activité des

objets• horizontal : représente l'enchaînement des stimuli entre 1 objet émetteur et 1 ou

plus objet(s) récepteur(s), i.e. les flots de contrôle (séquence, répétition, alternative)

Objet Stimulus Fragments combinésContraintes temporelles


Diagramme de séquence : vue globale


540AGK31 : ImmatriculationObject1

1 : indiquerDepartement()

Les objets et les exécutions Stéréotype

• nomObjet : Type

Rôle • définit un des objets manipulés par le système.• un objet peut être anonyme (sans nom). Il représente alors un instance

arbitraire de la classe.• La ligne pointillée détermine la durée de vie de l’objet• Il est possible d’indiquer la création d’un objet en faisant arriver un

message sur le rectangle décrivant l’objet• Une exécution est matérialisée par un rectangle sur la ligne de vie.

C’est la durée où l’objet est actif (le système est occupé par le traitement de cet objet).

• Les rectangles peuvent être empilés pour indiquer la récursivité des traitements

Règle de V&V • l’objet doit être contenu dans le système• le contexte de l’objet (la valeur des attributs) doit être défini si il a un

impact sur la réaction de l’objet dans le diagramme de séquence


Les messages540AGK31 : ImmatriculationTerminalPolice

1 : consulterDepartement() Stéréotype • Une flèche matérialise

o un message synchrone o un message asynchroneo un flux de contrôle (réponse)

Rôle • le message indique un transfert de contrôle ou d’information entre deux objets.• un message peut renvoyer sur l’objet qui l’a généré (cas de l’appel interne d’une des méthodes

de l’objet). Eviter les messages vers des acteurs car ils n’ont pas de sens lors des phases de

codage Règle de V&V

• pas d’exécution sans message• un message doit être nommé• lorsque l’émetteur envoie un message, il doit attendre son la réponse : la durée de

l’exécution de l’émetteur est supérieure à celle du récepteur


Les fragments combinés Stéréotype

• opt, break, loop, par, alt, neg, seq, strict, critical

Rôle Indique une rupture dans le

déroulement temporel séquentiel du diagramme de séquence

Eviter l’utilisation des concepts UML 2.0 suivants :• Par (parallèlisation),• Alt (alternative),• Neg (négative),• Seq (weak sequencing),• Strict (strict sequencing),• Critical (séquence critique),

On retiendra par contre :• le concept d’Opt (option),• de Break• et éventuellement de Loop

(boucle)


Contraintes temporelles

Syntaxe :• Flèche oblique vers le bas

Rôle :• traduit le fait que la transmission du contrôle et des données prend un certain temps• Une contrainte temporelle peut s'exprimer

o sur une durée d'activation par une annotation ou un texte entre { }o sur les instants d'émission/réception de messages, par une annotation ou un

texte entre { }o Sur les différences entre temps, i.e. instants d'émission/réception de

messages Règle de V&V

• les messages ne pointent jamais vers le haut

NB : une contrainte temporelle est toujours une expression relationnelle !


Contraintes temporelles : exemple


: Utilisateur : Téléphone

: Réseau GSM

numéroter( )

lancerAppel( )

lancerAppel

appelObtenuenvoyerSonnerie

Un objet

Un message

Temps

Ligne de vie de l’objet

Un acteur

Exercice : que montre ce diagramme de séquence?


: Monteur

: Commande

: Composantnew

new

ajouterComposant(Composant, int)Séquence itérée

demanderCommande( )

Monteur Demander une commande

Diagrammes de séquence : validation d’un cas d’utilisation


Magasinier Gérer les commandes

Vérifier la commande

Charger une commande en demande

Enregistrer la commande

Autres cas

: MagasinierClasse :

CommandeDemande sélectionnée :

Commande

listerDemandes( )

validerDemande( )

enregistrerCommande( )

Diagrammes de séquence : validation d’un cas d’utilisation

Mise en pratique



Cette fois votre client souhaite que vous lui modélisiez la spécification d’appel en utilisant le répertoire :

Le téléphone comporte deux modules. Un pour l’appel et un pour la gestion du répertoire. L’utilisateur commence par accéder au répertoire et sélectionne la fiche d’un de ses correspondants. Il déclenche alors l’appel. Si la fiche comporte plusieurs numéros un menu lui propose de choisir le numéro à appeler. Ceci fait, le module d’appel est mis en œuvre pour effectuer la communication.


Les diagrammes de communication : vue globale

Ce sont des diagrammes équivalents aux diagrammes de séquence, mais avec une vue différente (vue du dessus)

1

2


Diagrammes de séquence : utilisation

Décrire la réalisation des cas d’utilisation à travers des diagrammes de séquence:

En phase d’analyse métier:• Un diagramme montrant l’exécution de base de chaque séquence du cas

d’utilisation• Un ou plusieurs diagrammes pour modéliser les exécutions alternatives du cas

d’utilisation• Un ou plusieurs diagrammes pour modéliser les exécutions exceptionnelles ou

optionnelles du cas d’utilisation

Les messages sont des opérations sur les objets cibles


Importance des diagrammes d'interaction

Essentiel :• un scénario = un diagramme de séquence ou un descriptif textuel détaillé• un scénario = 1 et 1 seule suite d'actions (seule la séquence est autorisée)• les scénarii doivent décrire TOUS les cas de traitements de TOUS les événements

possibles• on détermine ainsi la robustesse du système

Diagrammes de séquence• identification des objets, et donc

des classes potentielles• identification des échanges entre

objets, issus des scénarios

Diagrammes de communication• identification des responsabilités• identification des rôles


Les diagrammes de classe

Un élément essentiel (mais ce n'est pas le seul) de l'approche orientée-objet

Expriment l'aspect structurel/statique d'un système en termes de • classes • relations

Offrent également • les interfaces - comment on voit/utilise le système modélisé• les paquetages - comment on peut abstraire le système en (macro) composants


Diagramme de classe : vue globale


Les classes

Une classe = abstraction pour un ensemble d'objets ayant le même état, offrant le même comportement et ayant les mêmes liens avec d'autres objets

UML offre aussi différents types de classes, proches de l’implémentation• les classes énumération• les métaclasses• les processus ou les threads, …

NB : une classe doit être spécifiée à au moins 2 niveaux • niveau application : classe métier ou classe d'analyse• niveau implémentation :

o traduction informatique d'une classe métier (le mapping peut être 1-1)o insertion de classes dédiées (par ex. les conteneurs) assurant les

performances ou l'indépendance


Représentation d'une classe

1 à 4 champs : • nom de la classe : obligatoire• 0 ou n attributs• 0 ou n opérations• 0 ou n invariants de classe,

exceptions, … Présence de stéréotype

• <<class>> : implicite• <<utilitaire>>• <<interface>>• <<signal>>• <<acteur>> : ne devrait pas

apparaître !• ….

NB : l'outillage actuel ne permet pas toujours de respecter UML 2.0 ! Le 4e champ n’est pas directement représentable


Les attributs Stéréotype

• aucun Rôle

• sémantique : constitue un élément de l'état de l'objet• visualisé ou pas, selon le niveau de détail souhaité• … : liste d'attributs incomplète

syntaxe : Visibilité Id [Multiplicité] : Type [InitVal] [{Propriété}]• Visibilité = type d'accessibilité

o + : public - visible et modifiable par tout objet du même paquetageo - : private - seulement visible et modifiable par les opérations de l'objet auquel il appartient. o # : protected - seulement accessible et modifiable par les opérations des classes descendantes

• Multiplicité : intervalle ou nombreo Propriété : par ex. mutabilité i.e. gelé, variable, ajoutUniquement

Règle de V&V• le principe de masquage impose de rendre chaque attribut private • pas d'attribut redondant autre que les attributs dérivés

NB : Attribut dérivé : attribut qui peut être déduit par le calcul (/Attribut) et qui conduit en implémentation à une opération


Stéréotype• aucun a priori• <<crée>>, ... existent !

Rôle• représente un service spécifique offert par un objet ; peut être considérée comme

une fonction au sens mathématique du terme => recopie des paramètres et renvoi d'un résultat et d'un seul !

• Syntaxe : Visibilité Id ( [Args] ) : Type [{Propriété}] o Visibilité : +, -, #o Args : Direction Id : Type [= DefaultVal]o Direction : in, out, inout (in est la valeur par défaut) o Propriété : requête, concurrence, abstrait, estFeuille, estRacine

Règle de V&V• sémantique d'une fonction, i.e. correspond à un traitement• un seul résultat (contradiction apparente entre in et type retourné par une opération)

NB : au niveau métier on ne doit jamais représenter les opérations de création et de suppression

Les opérations


Identification des classes, attributs et opérations

C'est lors de la construction des diagrammes d'interaction (séquences et/ou collaboration) que les objets réels sont identifiés

Ils sont transformés • en classes s'il y a des messages échangés• sinon en attribut

Les opérations des classes correspondent aux messages échangés entre objets réels

Règle de V&V • il est essentiel de vérifier que tout classe possède des attributs et/ou des opérations.

Dans le cas contraire, il ne s’agit vraisemblablement pas d’une classe mais d’un attribut d’une classe de plus haut niveau. Sachez ne pas aller trop loin dans le raffinement.

NB : si ce n'est pas le cas, il faut impérativement justifier pourquoi !


Les classes Interfaces

Stéréotype• <<interface>>

Rôle• décrit le comportement visible de certaines classes• représentée par un rond rattaché à une classe • ne figurent que des opérations publiques • pas d'attribut

Règle de V&V• s'agit-il bien d'une interface physique ?

NB : • penser à la notion de menu et sous-menu pour la notion de classe interface • une classe interface peut être la réalisation de plusieurs classes


Classes paramétrables, classes utilitaires

Classe paramétrable = classe générique• représentée par un classe traditionnelle avec un

rectangle à traits tiretés dans la coin droit supérieur

• les paramètres de généricité sont identifiés dans le rectangle à traits tiretés

• classe sans instance • classe surtout utilisée en implémentation• une classe instance est liée à une classe

paramétrique par une flèche tiretée Classe utilitaire = représente des

bibliothèques• joue un rôle d'élément global contenant des

opérations et/ou des attributs• présence du stéréotype <<utilitaire>>


Les relations

Elles sont de 3 types et traduisent :• la notion d'assemblage/composition• le concept de spécialisation/généralisation• l'association entre une (réflexivité) ou plusieurs classes

Elles représentent des liens statiques/structurels entre objets et à longue durée de vie

NB : les associations ne sont en général pas directement supportées par les langages de programmation orienté-objet.


Agrégation/composition

Relation non symétrique Une extrémité supporte la notion de

responsabilité : • toute opération/attribut du

responsable peut se propager aux éléments contraints

• il y a subordination Agrégat/agrégé : durée de vie des

agrégés indépendante de l'agrégat Composite/composant : durée de

vie des composants dépendante du composite/conteneur - on parle d'embarquement


Généralisation/spécialisation

Relation de classification entre un élément plus général et des éléments spécialisés

L'élément spécialisé hérite des attributs et des opérations et des relations et des contraintes de l'élément dont il est la spécialisation

L'élément spécialisé peut avoir ses propres attributs, opérations, relations

Spécialisation simple ou multiple B hérite de A si dans tout contexte ou

l’on utilise A on peut remplacer A par B Attention si le périmètre du logiciel

change, les contextes sont augmentés, et la règle de remplacement peut ne plus être vérifiée


naval aérien

moyen de transport

Attention:• L’héritage multiple est

rarement nécessaire en phase d’analyse.

• Certains langages ne le supporte pas (Java).

L’héritage multiple – à éviter

Une classe peut avoir plus d’une classe mère. Plusieurs parcours d’héritage sont alors possibles.

L’objectif est de fusionner en une nouvelle classe, et éventuellement les y spécialiser, des comportements appartenant normalement à des classes différentes.

L’intérêt est de pouvoir fusionner des ascendants directs d’importance voisine ou d’ajouter à une classe d’autres fonctionnalités.

hydravion


L’héritage: règle de modélisation

Il n’est pas souhaitable de se focaliser sur les relations d’héritage trop vite

L’héritage est une notion très structurante dans un modèle objet. Elle fige la structure

sémantique des types d’objet.

L’ajout d’une nouvelle classe est obligatoirement influencé par les relations

d’héritages existantes. Il faut rester ouvert le plus longtemps possible.

C’est uniquement quand on estime que toutes les classes du domaine fonctionnel ont été

identifiées que l’on peut commencer à réfléchir sur les abstractions du système et ainsi

construire les premières classes abstraites.


Diagrammes de classes lors des phases d’analyse

En phase d'analyse métier, seules des classes métier doivent être identifiées (opérations métier, attributs métier et associations métier).

La recherche de classes, attributs, opérations et associations est guidée par la réponse au besoin :• expliciter les diagrammes de séquence correspondant aux cas d'utilisation recensés

Les paquetages permettent d'organiser l'analyse en domaines métier.

La notion de visibilité est absente: en analyse, toutes les propriétés sont publiques (potentiellement visibles par l'utilisateur du système).

La notion d'interface est absente (utilisées en architecture et conception uniquement).


Associations et classe association

Représente une propriété statique (se convaincre avec un diagramme d'instances)

Lie une ou plusieurs classes : arité 2 ou plus

Toute association doit être nommée par un verbe d'état ou comporter des rôles aux extrémités

Toute association peut être navigable Multiplicité :

• 0• 0..1• N• M..N• *, 0..*• 1..*


Remarques sur les Associations

Ne prendre en compte que des associations binaires ! Si ce n'est pas possible, il faut privilégier les classes associations

Le nommage est indispensable quand il y a plusieurs associations entre 2 classes. Ne s'agit-il pas d'un agrégat ?

Importance des contraintes !• Sous-ensemble, et/ou, etc.• {ordonné}, ...

Attention à ne prendre pour associations que des relations dont le libellé représente un verbe d'état


Trouver, parmi les phrases suivantes, celles qui décrivent des messages échangés et celles qui décrivent des associations entre des classes :

Assoc. Mess. Le livre est composé de pages La carte grise correspond à une voiture Le serveur envoie un mail d’alarme Le feu rouge est équipé d’une boucle de détection

dans la chaussée qui est activée par les voitures J’achète et je bois un café à la machine à café L’auteur écrit des livres Le client retire de l’argent Mr X dirige ces personnes

Exercice : Ne pas confondre associations et messages


Trouver, parmi les phrases suivantes, celles qui décrivent des messages échangés et celles qui décrivent des associations entre des classes :

Assoc. Mess. Le livre est composé de pages La carte grise correspond à une voiture Le serveur envoie un mail d’alarme Le feu rouge est équipé d’une boucle de détection

dans la chaussée qui est activée par les voitures J’achète et je bois un café à la machine à café L’auteur écrit des livres Le client retire de l’argent Mr X dirige ces personnes

Dépend ducontexte MOA

Exercice : Ne pas confondre associations et messages


Commentaires, notes et dépendances

Commentaires et notes • utilisation d'annotation• peut être attachée à tout élément

UML• une note, comme dans l'exemple

permet d'introduire des propriétés, des contraintes, etc.

Dépendance• relation qui traduit que le

changement d'un élément quelconque a un impact sur un autre élément



Le client désire comprendre comment les éléments de votre système vont être connectés. Vous décidez donc de traduire le cahier des charges suivant en diagramme de classes :

Le système du téléphone comporte un gestionnaire de fonctions. C’est lui qui contient les différentes fonctions ( contrôleur d’appels, répertoire, éditeur SMS et calculatrice) et assure la navigation dans les menus. Les différentes fonctions offrent un comportement identique. Le répertoire contient des fiches contact comportant un nom et un numéro de téléphone. Il est possible d’en stocker 200 dans la carte mémoire. L’éditeur SMS contient des SMS formalisés par un numéro de téléphone et un texte. Le contrôleur d’appel stocke les appels émis et reçus sous forme d’une date d’appel et d’un numéro.


Diagramme d’état-transition : vue globale


Les diagrammes d’états-transitions

Un diagramme d’états-transition = représentation d’un automate :• tout objet ou tout système possède un état à chaque instant

Un diagramme d’états-transition permet de représenter le comportement nominal ET non nominal de toute instance d’une classe

Un diagramme d’états-transition devrait permettre également de représenter le comportement global d’une application orientée objet : enchaînement des commandes ! Mais trop souvent le nombre d’états est trop grand pour être représenté !


Diagrammes d’états-transition : les concepts

Etat • à tout instant un état représente l’ensemble des valeurs des attributs et des liens avec les

autres objets• un état est caractérisé par une durée, i.e. une certaine stabilité dans le temps

Transition • connexion unidirectionnelle reliant 2 états• assure le passage d’un état à l’autre • est supposée instantanée• une transition peut être réflexive

Evénement • occurrence de quelque chose qui arrive à un instant inconnu ou connu (interruption, envoi

de message, …)• peut être porteur d’informations• doit avoir été prévu par la conception• l’événement est le déclencheur d’une transition


Etat

Un état est toujours nommé Il comporte :

• des actions d’entrée• des actions de sortie• des activités• des inclusions de sous-états

Etats particuliers :• état initial (forcément unique)• état final (0, 1 ou plusieurs)


Les transitions

Une transition est une relation entre un état source et un état cible. Une transition est déclenchée par un objet en réaction à un événement et conduit à un changement d’état.

Syntaxe : évènement[garde]/action Les éléments suivants sont tous

facultatifs : évènement (trigger) : événement

externe déclenchant une réaction du système

garde (guard) : expression logique qui conditionne le départ d’un état

action : action exécutée lors du franchissement de la transition


Evénement

Il traduit l’arrivée de quelque chose Types d’événement :

• <<signal>> : signal asynchrone• <<crée>>, <<détruit>>, … : appel• <<top>> : signal synchrone - fin de délai, top horloge, …

événement instantané : pas de label - correspond à la fin de l’activité dans l’état de départ

Sémantique des événements : à l'arrivée d'un événement prévu, on quitte l'état, que l'activité soit achevée ou pas


Compléments sur les diagrammes d’états-transitions

La maîtrise de la complexité des diagrammes états-transitions passe par l’utilisation d’états composite (état englobant)

Les sous-états concurrents permettent de représenter la notion de concurrence

Les états historiques permettent de conserver l’historique en tant qu’états, et donc d’y revenir


Concurrence pour les diagrammes états-transitions



Une partie du cahier des charge du téléphone portable est compliquée et gagnerait

à être traduite en diagramme d’état transition :

Pour utiliser le téléphone il faut passer du mode veille au mode actif en cliquant sur

le bouton on. Le mode appel permet de communiquer vocalement. On y accède en

composant un numéro de téléphone et on le quitte en appuyant sur le bouton de

fin de communication. On peut passer en mode gestion des SMS en appuyant sur

la flèche gauche. Et on le quitte en appuyant sur Ok. Si un appel survient durant

l’écriture d’un SMS le SMS est stocké et le téléphone passe en mode appel. De

plus le téléphone interroge en permanence le réseau afin de déterminer si il doit

émettre avec une puissance de signal forte ou faible.


Diagramme de composants

Traduit l’aspect implémentation en proposant une structure en composants et paquetages

Les composants représentent les éléments de conception réutilisables :• ils contiennent des classes• ils présentent des interfaces• et leurs interdépendances

Propriétés importantes • au sein d’un composant couplage fort• entre composants, couplage lâche

Paquetage = ensemble de composants


Exemples de composants et de paquetages

CoursProgrammation Cours

Professeur

Etudiant

Interfaces

Université

Gestion des Erreurs

Base de Données


Règles de nommage Objectifs : homogénéiser les informations pour faciliter

• la lecture • la traçabilité vers la conception détaillée et le codage

Unicité : Les noms de domaines, de packages et sous-packages doivent être uniques à l’échelle du progiciel pour être réutilisables.

Caractères : Les noms du modèle sont formés d’alternances majuscules/minuscules. Les caractères accentués ne doivent pas être utilisés. Les autres caractères (espaces, ponctuation…) sont à éviter mais les chiffres peuvent être utilisés.

Nommage des domaines : Les domaines, packages et sous-packages métier sont utilisés en phase de définition des exigences, en phase d’analyse et en phase de conception détaillée. Pour éviter les collisions de nom ces concepts seront préfixés de la façon suivante :• BR (Business Requirement) en phase de recueil des besoins. BRCommunication par exemple.• BM (Business Model) en phase d’analyse. BMCommunication par exemple.• Pas de préfixe en phase de conception technique (Technical Model), afin de faciliter la traçabilité ou la génération

de code associée à la modélisation Nommage des classes : Les classes métier sont nommées par leur nom métier naturel, de même que leurs attributs, opérations, associations. Une classe commence par une majuscule. Les autres concepts commencent par des minuscules. Lorsque le nom est

composé de plusieurs mots, les mots suivants commencent par des majuscules. Nommage des règles de gestion : Les règles de gestion définies à l’échelle d’un domaine, package ou sous-package seront codifiées de la façon

suivante : <nom-domaine>[_<nom-package>[_<nom-souspackage>]]_<numéro-de-règle>


Exercice : le jeu des 7 erreurs


Exercice : le jeu des 7 erreurs - Solution

BRGarage


Synthèse

Définir les paquetages des domaines fonctionnels. Définir les scénarii des fonctionnalités du système Documenter tous ces éléments à chaque étape. Ajuster les liens d’héritage au fur et à mesure. Vérifier la complétude par des diagrammes de séquence mettant en jeu les objets

métier. Spécifier les classes, attributs, associations, opérations réalisant les cas

d’utilisation. Définir la composante temporelle des objets métier par des diagrammes d’état. Vérifier les dépendances entre classes et les dépendances induites entre

paquetages. Éliminer les dépendances croisées. Ajuster le modèle et itérer.


Vue d’ensemble

Le génie logiciel

Recueil des besoins

Analyse

Compléments

Synthèse

Sommaire


Le dossier de validation

Constitué de cas de test structurés autour de :• Un contexte de fonctionnement / des pré requis• Des données de test (ou jeu de test)• Des scénarii de test découpé en pas de test• Des résultats attendus

L’outil à utiliser pour réaliser ce dossier est• Test Director de HP / Mercury :

http://mercury-web.capgemini.fr/qcbin/start_a.htm

Pour approfondir les sujets liés aux tests de validation, reportez vous aux formations :Les Tests – Management : outil et processTests de Validation et Tests de Non-régression : outils & process

http://mercury-web.capgemini.fr/qcbin/start_a.htm


Relations entre spécifications et testsLa spécification sert de base aux tests de validation

1. Lors de la phase de recueil des besoins, étudier la nécessité de disposer d’un simulateur/bouchon pour chaque association entre le système et un acteur ‘non humain’.

2. Rédiger le dossier de test :

1. Inscrire dans le cas de test la référence de l’exigence à laquelle il correspond.

2. Rédiger un cas de test pour chaque diagramme de séquence ou d’activité. Ces cas de test sont identifiés avec une criticité maximale.Règle : un pas de test pour chaque message du diagramme de séquence.

3. Rédiger un cas de test pour chaque scénario identifié lors des phases de spécification. La criticité du cas de test sera évaluée en fonction de l’importance de la fonctionnalité et de la probabilité d’apparition du scénario

4. Réclamer les jeux de test au client et/ou les construire à partir des paramètres définis dans les scénarii.

5. Faire évoluer les cas de test en ajoutant les résultats attendus.

6. Etablir le contexte de passage du cas de test.


La modélisation et les livrables Le livrable correspond à une extraction du modèle. Donc tout doit être répertorié dans

le modèle UML. En pratique

• Spécifications générales, préliminaireso Vision et vue métiero Cas d’utilisation essentielso Quelques diagrammes de séquence

• Spécifications détailléeso Cas d’utilisation réelso Besoins d’exploitationo Besoins opérationnels induitso Diagrammes de séquenceo Modèle objet du domaine

• Parfois séparationo Spécifications fonctionnelleso Spécifications techniques

Mise en pratique :Outils/Report Wizard


Modèles de documents Modèles Capgemini adaptés à une traçabilité Reqtify (nommés Req_xxx)

• Dossier de spécifications (DS)• Dossier d’architecture (DAR)• Dossier de conception (DC)• Dossier de tests (DT)

Accessibles sur • https://coconet.capgemini.com/sf/linkedapplication/do/viewLinkedApplication/proje

cts.fr_south_capgemini_industrializa/linkedApplication/lapp1843/docf194793

dans le processus« définir les spécificationsfonctionnelles etl'architecture »

(login f_indus_1

mot de passe F_indus_1)

https://coconet.capgemini.com/sf/linkedapplication/do/viewLinkedApplication/projects.fr_south_capgemini_industrializa/linkedApplication/lapp1843/docf194793

https://coconet.capgemini.com/sf/linkedapplication/do/viewLinkedApplication/projects.fr_south_capgemini_industrializa/linkedApplication/lapp1843/docf194793


Aperçu de MDA : Transformation de modèles

Ensemble de normes, de standards• développés par l’OMG en 2001• étend celui de l’UML(Unified Modeling Language).

Utilisation systématique de modèles Permet le passage du PIM (Platform Independant

Model) au PSM (Platform Specific Model). Procédé qui permet de convertir d’un modèle à un

autre modèle du même système à implémenter. Conversion de manière automatisée avec des

outils comme:• ATL(Atlas Transformation Language)• VIATRA(VIsual Automated model TRAnsformations)

Passage du PSM au code : • suite logique de MDA au moyen d’outils tels

qu’Acceleo, androMDA, MIA…


Aperçu de MDA : l’ingénierie des modèles

le concept « tout objet » vs le concept « tout modèle ».

« remplacer la composition d’objet par la notion de transformation de modèle »

Standard MDA: faciliter la production de modèles.

Exemple de processus de transformation de modèles: Pour approfondir les sujets liés à MDA,

reportez vous à la formation :MDA


Fonctions avancées de MagicDraw

XMLJava C++ SQLC#


Vue d’ensemble

Le génie logiciel

Recueil des besoins

Analyse

Compléments

Synthèse

Sommaire


A RETENIR

Le use case sert de pivot à toute la conception. Un outil de modélisation est indispensable pour manipuler et stocker le référentiel des objets

du modèle La traçabilité se fait sur l'ID de référence du use case (numéro dans le use case ou nom du

use case). La bonne granularité est obtenue lorsque l'on peut écrire un scénario fonctionnel nominal

pour le use case. Un use case = 4 ou 5 scénarii de test (nominaux et non nominaux). Au delà le use case est

trop compliqué et doit être découpé. Penser à appliquer des CRUD lorsque possible (ou des CUD avec le R ailleurs). Créer un glossaire métier avec des liens hypertexte des concepts UML vers ce glossaire Il n’y a pas de correspondance 1 à 1 entre une classe métier et une classe du modèle de

base de données. En effet, pour des raisons de performances ou de choix d’implémentation, une classe métier peut être transformée en plusieurs tables ou même plusieurs classes métiers peuvent être transformées en une seule table.


Quiz – Quel est le terme utilisé pour décrire une exécution conditionnelle dans un diagramme de séquence :? alt

critical

opt

ref

ü


Quiz – Qu’est-ce qu’une relation? ? Un élément avec au moins un élément relié

Un élément qui connecte deux éléments

Un élément qui connecte au moins deux éléments

ü


? 0

1

2

indéfini

ü

Quiz – Combien de transitions peuvent partir d’un état initial :


?ü

Quiz – Quel diagramme de séquence est invalide si il provient du même modèle que le diagramme d’activité :


? Un objet est une instance de classe

Une classe est une collection d’objets semblables

Un objet est une entité aux frontières bien définies, possédant une identité

Une classe est un descripteur d'objets similaires

ü

Quiz – Quelle affirmation est fausse :


?ü

Quiz – Quelles séquences d’évènements (à partir de l’état initial) conduisent à un blocage du système :

b

a e a

a e f

a e bü


?ü

Quiz – L’extension d’un cas d’utilisation UC1 par un autre cas d’utilisation UC2 (avec un lien “extend” d’UC2 vers UC1) :

UC2 enrichit UC1 sans le modifier

Modifie UC2 en lui ajoutant du comportement

Décrit une généralisation de UC1 vers UC2


? 9

11

13

14

ü

Quiz – Combien de diagrammes composent UML 2.0 :


? Attribut

Port

Multiplicité

Rôleü

Quiz – Le nom d’une extrémité d’association s’appelle :


Références documentaires UML 2 en action De l'analyse des besoins à la conception

Pascal Roques, Franck ValléeEyrolles 2007

Guide pratique du RUPPhilippe Kruchten et Per KrollCampusPress 2003

Introduction au Rational Unified ProcessPhilippe KruchtenEyrolles 2000

Modélisation objet avec UMLPierre-Alain Muller, Nathalie GaertnerEyrolles 2000

The Unified Modeling Language Reference ManualJames Rumbaugh, Ivar Jacobson, Grady BoochAddison-Wesley 1999

Design Patterns: Elements of reusable object-oriented softwareE.Gamma & al.Addison-Wesley 1995

Exercices corrigés d’UML : Génie logicielPascal André, Alain VaillyEllipses, 2003


Liens

Lien vers le wiki A&D :

Wi http://wiki.capgemini.com/index.php/MagicDraw_Indus_Sud

Lien vers CTF Indus A&D, Modélisation et Magic Draw :https://coconet2.capgemini.com/sf/docman/do/listDocuments/projects.fr_south_capgemini_industrializa/docman.root.03_poles.03_pole_cqp.docf1033038

http://wiki.capgemini.com/index.php/MagicDraw_Indus_Sud

https://coconet2.capgemini.com/sf/docman/do/listDocuments/projects.fr_south_capgemini_industrializa/docman.root.03_poles.03_pole_cqp.docf1033038

https://coconet2.capgemini.com/sf/docman/do/listDocuments/projects.fr_south_capgemini_industrializa/docman.root.03_poles.03_pole_cqp.docf1033038

The information contained in this presentation is proprietary and confidential. It is for Capgemini use only. ©2010 Capgemini. All rights reserved

Together. Free your energies

The information contained in this presentation is proprietary and confidential. It is for Capgemini use only. ©2010 Capgemini. All rights reserved

www.capgemini.com

Together. Free your energies

Fin

Merci de votre attention !