UML (Programmation orienté objet)

UML (Programmation orienté objet) Ont trouve trois aspect:

Les Principaux modèle:

– Niveau Fonctionnelle:

• Diagramme de USE CASE: (Besoin fonctionnelle des utilisateurs)

– Le diagramme d'activité.

– Le digramme de séquence.

– Niveau Statique:

• Diagramme de classe (ce qui concerne la pratique du système)

– Diagramme d'Objet

• Diagramme de composants

– Diagramme de déploiement

– Niveau dynamique:

• Diagramme d'état.

• Diagramme d'activité.

• diagramme de séquence.

– Diagramme de communication:

– Modélisation fonctionnelle:

• Objectif:

– Mise en œuvre de la technique des cas d'utilisation

• Identification des acteurs

• Identification des cas d'utilisation

• Description textuelle des cas d'utilisation

• compléter la modélisation fonctionnelles par le diagramme de séquence et d'activité.

– Mots clés:

• Acteur.

• Cas d'utilisation.

• Acteur principale.

• Acteur secondaires.

• Diagramme de séquence.

• Diagramme d'activité.

• Inclusion / extension et généralisation d'une cas d'utilisations

• pack­age de cas d'utilisation.

– Principes et définitions de base:

– acteur: un acteur représente un rôle joué par une entité externe (utilisateur humain,  dispositif, matériel ou autre système) qui interagis directement avec le système étudié.

– Comment les identifiés?: les acteurs candidats sont systématiquement:

– les utilisateurs humaines : faire en sorte d'identifier tous les profils. Possibles sans  oublier l'administrateur, l'opérateur de maintenance ... etc

– Les autres système connexes qui interagissent aussi directement avec e système  étudié par le biais de protocoles  

– Représentation d'un acteur 1er représentation:

(StickMan)

Nom d'utilisateur Ex: Client 2emme Représentation:

– Comment les représenté?:

la représentation graphique standard de l'acteur en UML est l'icone, appelé StickMan avec le nom  de l'acteur sous le dessin.

On peut également figurer un acteur sous la forme rectangulaire d'une classe avec le mot clé 

« Actor »

une Troisième représentation: également possible comme cela est indiqué sur le schéma:

Remarque: Une recommandation consiste à faire prévaloir l'utilisation de la forme graphique de 

« stick man » pour les acteurs humaines et une représentation rectangulaire pour les systèmes  connectés 

• Cas d'utilisation:

c'est un ensemble d'action qui permettent de donnée un résultat.

Un cas d'utilisation (Use Case) représente un ensemble de séquences d'action qui sont réalisé par le  système et qui produisent un résultat observable intéressant pour un acteur particulier.

Chaque cas d'utilisation spécifie un comportement attendu du système considérer comme un atout,  sans imposé le mode de réalisation de ce comportement il permet d'écrire de que le future système  de bras fer  sans spécifier comment il le fera.

• Comment les représenté?:

étude d'un cas:

Etude d'un guichet automatique bancaire (GAB):

1­ Identification de acteurs:

– Porteurs de la carte bancaire

– Le clients

– Le Système d'Autorisation Globale (SAG)

– Le Système d'Information de la Banque (SIB)

– l'Opérateur de la maintenance

Le diagramme du contexte statique:

Deuxième représentation :Le diagramme du contexte statique:

– Le GAP et un système fondamentalement mono­utilisateur :

A toute instant, il ya qu'une instance de chaque acteur au maximum connecter au système.

Il faudrait ajouté une note graphique pour indiqué  que les acteurs humain clients banque et  porteurs de carte sont mutuellement exclusif.

Une autres solution un peut plus élaboré, consiste a considérer que client banque est une 

spécialisation de Porteur de carte. Le problème d'exclusivité est ainsi résolut grave a l'héritage  entre Acteurs.

2. Identification des cas d'utilisations :

      Le porteur de la carte bancaire (l'acteur principale)

– Retirer de l'argent .

Le client de la banque: (l'acteur principale)

– Consulter le solde .

– Déposer du numéraires.

– Déposer des chèques.

– Retirer de l'argent.

L'opérateur de maintenance: (l'acteur principale)

– Rechargé le distributeur.

– Récupérer les cartes avalées.

– Récupérer les chèques.

Le SAG:

– Néant (pas de cas d'utilisation) Le SI Banque:

– Néant(pas de cas d'utilisation)

3. Acteur principale et acteur secondaire :

 Tout les acteurs n'utilises pas de forcément le système nous appelant acteur principale celui pour  qui le cas d'utilisation produit un résultat observable. 

Par opposition, nous qualifiant d'acteurs secondaire les autres participants du cas d'utilisation. Les  acteurs secondaire sont souvent sollicité pour des informations complémentaires.  

C'est exactement le cas des deux acteurs non Humain de notre exemple: le SAG et le SI Banque qui  sont uniquement sollicité par le GAP dans le cadre de la réalisation de certain cas d'utilisations.

Mais ils n'ont pas eux même de façon propre d'utilisé le GAP avec des objectifs a part entière

3­ Diagramme de cas d'utilisation :

3.1. Scénario: un scénario représente une succession particulière d'enchainement, s'exécutant  du début a la fin du cas d'utilisation. Un enchainement étant l'unité de description de séance  d'action. Un cas d'utilisation contient en générale un scénario nominale et plusieurs scénario  alternatif (qui ce termine  de façon normale) ou d'erreur (qui ce termine en échec).

­ il­ya trois type de scénario :

3.1.1. scénario nominale: ce type de scénario a un début et une fin, est pour ce  type de scénario la fin est aboutissants.

3.1.2. scénario relatif: ce type de scénario a aussi un début et une fin mais pendant  le parcoure il prendra un autre chemin. (il est considérer comme le type de scénario  nominale), mais la fin est aboutissants. Eg: un mot de passe erroné, mais 

récupérable.

3.1.3. scénario d'erreur: ce type de scénario na pas de fin aboutissants. Eg: un mot  de passe erroné, mais le mot de passe n'est pas récupérable.

Enchainement 

        Début

       Erreur Fin Normale

4­ Description textuelle des cas d'utilisation:

Modèle est correction:

– Titre (le titre du cas d'utilisation): Retirer de l'argent

– Résumé (description du cas d'utilisation): ce cas d'utilisation permet au client porteur de la  carte de retirer de l'argent

– Acteurs (les acteurs concerner par ce cas d'utilisation): Porteur de la carte (Principale).

Système d'autorisation Globale SAG (Secondaire).

– Date de création: 09/01/2010

– Date de mis a jour: 16/01/2010

– Le responsable ( le responsable de cet étude): en groupe. 

– Scénario nominale:

– Le porteur de carte introduit la carte dans le GAB.

– Vérification de la carte.

– Le GAB demande au porteur de la carte de saisir sont code d'identification.

– Le porteur de la carte saisie le code d'identification et valider.

– Le GAB compare le code d'identification avec celui existant dans la puce.

– Le GAB demande une autorisation au SAG.

– Le SAG autorise le GAB a opérer, donne le solde disponible.

– Le GAB demande au porteur de saisir le montant désirer.

– Le porteur saisie le montant désirer.

– Le GAB contrôle le montant demander par rapport au solde disponible. 

– Le GAB demande au porteur si il veux un ticket.

– Le client demande le ticket.

– Le GAB remis la Carte du porteur.

– Le porteur prend la carte .

– Le GAB délivre les billet et le ticket.

– Le porteur prend les billet et le ticket.

– Scénario alternatif:

– A1: code d'identification provisoirement erroné, l'enchainement A1 démarre au point 5  du scénario nominale.

– 6. le GAB indique au porteur de carte que le code d'identification est erroné pour la  première fois ou la seconde.

– 7. Le GAB enregistre l'échec.

– Le scénario nominale reprend au point: 3. Le GAB demande au porteur de la carte de  saisir sont code d'identification.

– A2: le montant demander est supérieur au solde, l'enchainement démarre au point 10 du  scénario nominale.

– 11. Le GAB indique au porteur de la carte que le montant saisie est supérieur au solde.

– Le scénario nominale reprend au point 8. Le GAB demande au porteur de saisir le 

montant désirer.

– A3: Ticket refusé, L'enchainement A3 démarre du point 11 du scénario nominale.

– 12. le porteur de la carte refuse le ticket.

– 13. le GAB rend la carte au porteur.

– 14. le Porteur reprend la carte .

– 15. Le GAB délivre les billets.

– Le scénario nominale reprend au point 16.

– Scénario d'erreur:

– E1: Carte non valide, l'enchainement E1 démarre au point 2 du scénario nominale.

– 3. le GAB indique au porteur que sa carte est non valide.

– Le cas d'utilisation ce termine.

– E2: code d'identification définitivement erroné, l'enchainement E2 démarre au point 5 du  scénario nominale.

– 6. Le GAB indique au porteur que sont numéro de sont code est erroné pour la  troisièmement fois.

– 7. La carte est confisqué 

– 8. le GAB informe le SAG.

– E3: retrait non autorisé.

– L'enchainement démarre au point 6 du scénario nominale.

– 7. Le système interdit tout retrait.

– 8. le GAB éjecte la carte.

– 9. le cas d'utilisation ce termine par un échec.

– E4: Le montant demandé et toujours supérieur au solde.

– L'enchainement E4 démarre au point 10 du scénario nominale.

– 11. le GAB indique au porteur de la carte que le montant est toujours supérieur au solde.

– 12. le GAB éjecte la carte 

– le cas d'utilisation ce termine par un échec. 

– E5: La carte non reprise, l'enchainement E5 démarre au point 13 du scénario nominale.

– 14. au bout de 15 seconde le GAB confisque la carte.

– 15. le GAB informe le SAG.

– Le cas d'utilisation ce termine en échec. 

– E6: Billets non pris.

– L'enchainement E6 démarre au point 15 du scénario nominale.

– 16. au bout de 30 seconde le GAB reprend les billets.

– 17. le GAB informe le SAG.

– Le cas d'utilisation ce termine par un échec.

– E7: annulation de la transaction.

– L'enchainement est démarre au point (entre 4 et 12) du scénario nominale.

– X. Le porteur de la carte peut demandé l'annulation de la transaction en cour.

– X. Le GAB éjecte la carte.

– Le cas d'utilisation ce termine par un échec.  

Le diagramme de séquence

­ Il suffit de transcrire sous forme de diagramme de séquence les interactions citée dans la  description textuelle du scénario nominale, ont utilisant les convention graphique suivante:

– l'acteur principale porteur de carte a gauche.

– Un participant représentant le GAB au milieu.

– L'acteur secondaire SAG a droite du GAB.

– Une possibilité intermédiaire consiste a enrichir le diagramme en faisant apparaître  également:

– les principales actions interne du système au moyen de messages qu'il s'envoient a  luis même.

– Les renvois en enchainement alternative et d'erreurs au moyen  des notes. 

– Cela donne souvent un diagramme moins complexe a lire que ne l'est un diagramme  d'activité, car moins riche en symbole mais au contenue informatifs appréciable pour 

l'expert métier.

– Poste condition

– exigences non fonctionnelle

– exigences IHM:

– Clavier

– Lecteur de carte.

– Écran

– Inclusion entre cas d'utilisations :         

 Avec UML Il ont est fait possible de détaillé est d'organisé des cas d'utilisations de deux façon 

différente est complémentaire:

– Ont a joutant des relation d'inclusion, d'extension et de généralisation entre cas d'utilisation.

– Ont les regroupant en pack­age afin de définir des blocs fonctionnel de plus haut niveau.

– Inclusion Entre cas d'utilisations

Si l'on examine en détaille la description textuelle du cas d'utilisation retirer de l'argent ont 

s'aperçoit que le début du scénario nominale va également être applicable a tout les cas d'utilisation  du client de la banque (de l'enchainement 1 a l'enchainement 5)

ont peux donc légitimement identifier un nouveau cas d'utilisation inclus dans les précédents, que  nous s'appelleront « s'authentifier » est qui contient les 5 enchainements cité en haut. Cela nous  permettra d'enlever des autres cas d'utilisation toute les descriptions textuelle redondante. En UML  cette relation d'inclusion obligatoire est formalisé par une flèche de dépendance entre le cas 

d'utilisation de base et le cas inclus, nommé avec le mot clé « Inclus ».

– Extension entre les cas d'utilisation:

on réexaminant la question du retrait d'argent ont s'aperçoit que le client de la banque applique le  même enchainement nominale que le client porteur de la carte mais autant que client il a également  accès au cas d'utilisation consulté le solde:

pourquoi ne pas luis permettre de consulté sont solde juste avant qu'il ne choisisse le montant de  sont retrait il pourrait ainsi ajusté le montant demander avec sont solde.

considérant les deux cas d'utilisation déposer des numéraire et déposer des chèques ils mettent en  jeux les même acteurs mais surtout ils parlent de la même chose:

La possibilité offerte a un client de la banque effectuer un dépôt d'argents le faite que cette 

transaction consiste a glisser des billets a simplement déposer des chèques n'est pas fondamentale. 

Le résultat sera similaire a savoir une ligne de crédit sur le compte du client pourtant le détaille des  enchainements va varier notablement:

– le dépôt de numéraire implique par Eg: un dispositif de reconnaissance de billets et  éventuellement d'autres actions spécifique. Alors que :

– le dépôt de chèque donnera lieu probablement a d'autres action particulière (vérification  manuelle ....etc).

Pour formalisé cette situation nous pouvant la relation de généralisation. Il suffis d'ajouté un cas  d'utilisation généralisé nommé « déposer de l'argent ». ce nouveau cas d'utilisation a la particularité  d'être abstrait (il apparaître en Italique)   car ils ne intensifiée pas directement mais uniquement par  le billais de l'un de ces deux cas spécialisé.   

Structuration des cas d'utilisation:      

– Packages :

Structuration des cas d'utilisation en packages:

plusieurs stratégie sont possible procéder au regroupement par acteur ou par domaine fonctionnelle  dans notre exemple, un regroupement des cas d'utilisation par acteur principale s'impose car cela  permet de régler la contrainte des acteurs secondaires et de les répartir.

Le cas d'utilisation inclus (s'authentifier) est mis das un package à part, en tant que service support  commun pour le bien distinguer des vrais cas fonctionnel qui l'inclus. Les flèches de dépendance  entres packages de cas d'utilisations synthétise les éventuelles relation entres les cas c'est a dire ici  les inclusions 

Correction d'exercice:

Acteurs :

Acteurs Principales Acteurs secondaires

­ Caissier

­ Responsable magasin ­ Centre d'autorisation­caisse

­ Centre d'autorisation­Chèque

­ Système de gestion de stock

­ Client

Diagramme de contexte statique :

La modélisation statique:

Comment définie l'orienté objet?

L'orienté objet signifie que l'ont organise le logiciel comme une collection d'objet dissocier  comprenant a la fois une structure de donnée et un comportement a la différence d'une 

programmation conventionnel dans la quel les structures de données est le comportement ne sont  que faiblement associer.

En programmation orienté objet un programme est un ensemble d'objets qui fonctionne ensemble  d'une manière prédéfinie a fin d'accomplir des tâches pour mieux clarifier cette notion prenant  l'exemple de construction LEGO, « les briques LEGO sont de petit bloques en plastique vendu en  différente couleurs est différente taille. Ces briques comportent sur l'une de leur face de petit  trompant rond qui rentre parfaitement dans tout les trous des autres briques. Ces combinaison des  brique permettent de construire des formes importante.

Les briques LEGO permettent de réalisé toute sorte de chose (château, voiture, ...ect) chaque pièce  LEGO est un objet qui associer a d'autre objet d'une manière bien spéciale permet de crée un objet  plus grand ».

la programmation par objet ressemble beaucoup a la construction d'un objet en brique LEGO.

Quel que concepts 1. Encapsulation:

dite aussi masquage d'information est un mécanisme consistant a rassembler les données et les  méthodes (opération) au sein d'une structure en cachant l'implémentation de l'objet c'est a dire ont  empêchant l'accès au données par un autre moyen que les service proposé 

2. Modularité

le concepts de modularité n'est pas un concepts récent ce mécanisme est reconnue par l'ensemble de  méthodologie de conception.

La modularité est constituer par tout les mécanisme qu'offre un langage de programmation pour  structuré les données et les procédures en unité logique de logiciel, indépendante les unes des  autres. C'est a dire les entité autonome qui peuvent être spécifier, implémenté, comprise et assimilé  a des boites noire.

3. L'héritage

permet la réutilisation des structures existante et reste une caractéristique fondamentale des langages  orienté objet. L'utilisation de l'héritage est simple: il permet de crée une nouvelle race non pas a  partir de zéro mais par extension ou par spécialisation d'une classe existante (ou plusieurs dans le  cas d'un héritage multiples) 

– Objet

un objet est une entité au frontière bien définie possèdent une identité et en capsulant un état et un  comportement. Un objet est une instance de classe. Un objet peut être concret ou abstrait,

Exemple:

ALI       ­­­­> Objet Concret

Module

Conduite de projet ­­­­> Sont des objets abstrait ou conceptuelle.

Base de donnée       

  pour pouvoir qualifier un objet a un éléments perçu il faut qu'il satisfasse trois principes:

1. principe de distinction: 

l'élément peut être repérer et distingué d'autre objets environnement. Ont peut luis trouvé un nom  permettant de le désigné et d'en parlez. Ont dit d'une façon générale qu'un objet a une identité  

2. le principe de permanence:

l'élément a une certaine durée de vie. Au cour de sa vie certaine de ces eucharistique peuvent  changer . Sont évolution ne remet pas en cause sont identité. Ont dit d'une façon générale qu'un  objet peut ce trouvé au cour du temps dans différents états. A un moment donné il est dans un seul  est unique état.

3. le principe d'activité:

quand on distingue un élément, ont luis reconnait un rôle dans le domaine que l'on étudie. Si  l'élément est doté d'autonomie, il est amené a accomplir certaines actions, si il est dépendant, ont  peut luis faire subir des traitements. Ce potentiel d'activité est une caractéristique de l'objet, un objet  possèdent donc une double facette: ce qu'il est et ce qu'il peut faire ou ce que l'on peut en faire.

Ont dit d'une façon générale qu'un objet possèdent un comportement.

Ont appellent objet un élément matériel ou immatériel dans la réalité étudier qui satisfait au principe  de distinction, de permanence et d'activité. Cela entraine qu'un objet possède une identité, un état et  un comportement.

– 20/02/2010

– Classes:

une classe d'objet décrie un groupe d'objet ayant des propriété similaire ( que nous appelons  attribut) au comportement commun (opération), des relations commune avec les autres objets avec  une même sémantique.

Exemple: 

Personne

Société Sont des classes d'objets Animal.

Personne : est une classe  ­    Ali

– Mohamed Sont des objets de la classe Personne

– Karim   

– Attribut:

un attribut est une valeur détenue par les objets d'une classe.

– Opération

une opération est une option ou une transformation qui peut être appliqué au objets ou par les objets  dans une classe

– Association:

une association représente une relation sémantique durable entre deux classes.

Exemple:

Une personne peut posséder des voitures.

• posséder    est une relation entre les classes Personne, et Voitures.

Les associations sont fondamentalement bidirectionnelle. Le nom d'une association binaire (deux  classes) ce lie habituellement dans un sens particulier mais peut être traversé dans les deux sens.

La direction respectant le sens du nm de l'association est appelez: direction vers l'avant.

La direction opposé est appeler: Direction inverse.

L'exemple précèdent inclus également le faite qu'une voiture est posséder par une personne.

– Comment les représenter?:

Au deux extrémité d'une association, ont doit faire figurer une indication de multiplicité. Elle  spécifie sou la forme d'un intervalle d'entier positive ou nul, le nombre d'objet qui peuvent participé  a une relation avec un objet de l'autre classe dans le cadre d'une association.

Exemple:

Une personne peut posséder plusieurs voitures (entre 0 et Un nombre quelconque) Une voiture est posséder  par une seul personne.

– Modéliser une association en classe

parfois il est utile de modélisé une association en classe. Chaque lien devient une instance de la  classe. La classe d'association peut avoir un nom est des opérations en plus des attribues 

Modélisation des phases suivantes

– Un répertoire contient des fichiers:

– Les modems et les claviers sont des périphériques d' E/S

Les Packages ou catégories:

– Introduction:

la classe représente une unité de structuration trop petite, des lors qu'ont s'attaque a un projet réel  au­delà de douzaine de classes il est utile de regroupé les classes  fortement couplé en entité plus  grande. Le couplage s'exprime a la fois structurellement par des associations, des agrégations, des  compositions ou des généralisations, mais aussi dynamiquement par les interactions qui ce 

produisent entres les instances des classes. Plus le nombres de classes devient important et plus cet  structuration s'avère indispensable 

– Définition:

Un Package consiste eu un regroupement logique de classes à forte cohérence interne d'un faible  couplage externe.

– Représentation:

– Découpage en catégorie:

• Objectif:

les objectifs de découpages sont:

– Organisation: organisé les équipes d'analystes puisqu'elle vont pouvoir travaillé sur des  ensembles cohérents est faiblement couplé. La cohérence implique le regroupement par  compétence métier est la diminution introduit la possibilité d'un travaille en parallèle sur  différends modules

– Maitrisé la complexité par la structuration

– Assuré l'évolutivité est la facilité de la maintenance, est favorisé la ré utilisabilité ont  donne l'importance en partis métier qui sont généralement plus stable et meilleure  candidate 

– Principe de découpage: 

– Le premier principe consiste a regroupé les classes sémantique­ment proche pour cela il  faut recherché la cohérence avec les critère suivants  :

• Finalité:

Les classes doivent rendre des services de même nature au utilisateurs  EX: Congé, type_de_congé, planning_des_congés, ...etc

• Évolution:

Ont isole ainsi les classes réellement stable de celle qui vont vrai semblablement évoluer au cour du  projet ou même par la suite. Ont distingue au notamment les classes métiers des classes applicatives

• Cycle de vie des objets:      

Permet de distinguer est donc de gérer différemment les classes dont les objets ont des durées de vie  très différente

EX: Client et commande.

  ­ Le deuxièmement principe consiste a renforcé ceux découplage initiale ont s'efforçant de  minimisé les dépendances entres les packages 

EX: Gestion d'un système de transport de marchandises:

– Application du 1er principe : (en respectant les critères de regroupement pour favorisé un  fort cohérence)

–

– Raison du découpage:

• Réseau est plan de transport: ont été séparé selon le critère d'évolution (réseau et  potentiellement réutilisable) 

• Exploitation informatique: a été isolé car elle correspond a un service technique mais pas  a un service métier (donc potentiellement réutilisable).

• Commande et client: ont été séparer selon le critère de cycle de vie et aussi d'évolution  (possibilité de réutilisé client). 

– Dépendance entre package et importation

Un package peut importer des éléments visibles d'un autre package. Cela signifie que le deuxième  package a explicitement déclarer que certaine de ces éléments peuvent être utilisé par d'autre  package.

UML définie ainsi deux niveau de visibilité 

+ (Publique): l'élément est utilisable par tout package relier par une dépendance  ­ (Privé): L'élément n'est utilisable que par le package parent 

Ont analyse nous préfixant simplement les classes visible par le symbole {+} 

la relation d'importation est représenté en UML par une dépendance du package fournisseur  EX: 

Les packages

Rq: Chaque objet missions doit connaitre les qui luis sont affecté mais 

Une association entre classe A et B permet par défaut de naviguer par les deux sens cependant  il  peut être utile de limité cet navigation à une seul des deux directions. C'est le cas pour les 

associations qui porte des packages, UML nous permet de représenter cet navigabilité en ajoutant  sur l'association une flèche indiquant le seul sens possible. Nous devon limité la navigabilité de ces  associations pour nous conformé au choix de dépendances entre packages.

Exercice:

Connaitre le modèle du matériel, la marque,  les caractéristiques sont affectation (Service, direction,  unité) les intervention qui a subit et le type de ces intervention 

Correction:

les classes:

• Matériel

• Marque

• Modèle

• Caractéristique

• Désignation

• Unité

• Directions

• Service

• Intervention

• Nature

– Affiner les diagrammes par le rajout de contrainte:

• la propriété « ORDERED »  

UML propose un certain nombres de propriété standard applicable au associations pour affiné un  diagramme de classe  

On peut spécifier que les objets à une extrémité de l'association doivent être ordonnées avec la  propriété « ORDERED » .

• La propriété « FROZEN »:

Ex:

Ont peux également préciser qu'un attribut ou un lien ne peut être modifier ou détruit avec la  propriété « FROZEN ».

• La propriété « addOnly » Ex :

a. Le lien entre incident et mission ne peuvent être détruit ni modifier. « FROZEN » b. Les objets incidents suivent un certain ordre [ORDERED].

c. Nous avons un cumul incident  après le premier objets incident « addOnly »

La propriété « addOnly » signifie que le nouveau lien  peuvent être ajouter depuis un objet de l'autre  de l'association.

– L'attribut dérivé:

Ex:      Symbole: /  : est le symbole de la dérivé comme démontre l'Exemple.

Un attribut dérivé est un attribut intéressante pour l'analyste, mais redondant car ca valeur peut être  déduite d'autres informations disponible pour la classe concerner. UML permet a la fois de le citer  au tant qu'attribut et d'indiqué au lecteur du modèle sont caractère redondant grâce au symbole:

 ' / '.

– Attribut de classe:

Ex1: Ex2:

Par défaut un attribut a une porter d'instance chaque objets de a classe possèdent sa propre valeur  pour la propriété dans certain cas l'attribut peut avoir une porter de classe il existe alors une seul  valeur commune de la propriété pour toute les instances de la classes, ont parle dans ce cas d'attribut  de classe ont luis affecte une valeur et ont le souligne pour le distinguer des attribut d'instance.

Exemple:

Exercice:

Cette étude de cas concerne un système simplifier de réservation de vols par une agence de voyage:

1. Des compagnie aériennes propose différentes vols.

2. Un vols et ouvert à la réservation et refermé sur ordre de la compagnie 3. Un client peut réserver un ou plusieurs vols, pour des passagers différents. 

4. Une réservation concerne   un seul vol et un seul passager.

5. Une réservation peut être annulés ou confirmé.

6. Un vol a un aéroport de départ et une aéroport d'arrivé.

7. Un vol a un jour et une heur de départ, et un jour et une heur d'arrivé.

8. Un vol peut comporter des escales dans des aéroports.

9. Une escales a une heur d'arrivé et une heur de départ.

10. Chaque aéroport dessert une ou plusieurs villes.

Question:

Élaborer le diagramme de classe correspondant.

Correction:

développement du modèle dynamique :

Diagramme d'état transitions:

Présentation

les digrammes d'états transition d'UML décrive le comportement interne d'un objet a l'aide d'un  graphe qui représente un automate a l'état finie. Il présente les séquences possibles d'états et d'action  qu'une instance de classe  peut traité au cour de sont cycle de vie en réaction a des évènements  discret (signaux, invocation de méthode).

Un automate a l'état fini est graphiquement représenté par un graphe comportant des états 

matérialisé par des rectangles au point arrondie, et des transitions matérialisé par des arcs orienté  (ou des lignes fléché) liant des états entre eux , 

la figure montre un exemple simple d'automate a état finie. Cette automate possèdent deux états  (Allumé et éteint) et deux transition correspondant au même évènement  (la pression sur un bouton  d'éclairage domestique). Cette automate a état finie illustre en faite le fonctionnement d'un 

interrupteur dans une maison. Lorsqu'on appuis sur le bouton, la réaction de l'éclairage associer  dépendra de sont états courant  (de sont historique). Si la lumière est allumé, elle s'éteindra, si elle  est éteinte elle s'allumera un états représente une situation durant le vie d'un objet pendant la quel:

• il satisfait une certaine condition

• il exécute une certaine activité.

• Ou bien il attend un certain évènement.

Un objet passe par une succession d'état durant sont existante un état a une durée finie variable  selon la vie de l'objet en particulier en fonction des évènements qui luis arrive

– état initiale:

l'état initiale est une pseudo état qui indique l'état du départ par défaut lorsque celui­si est invoqué .  Lorsqu'un objet est crée il entre dans l'état initiale:

Représentation de l'état initiale 

– l'état finale :

l'état finale est une pseudo état qui indique que le diagramme d'état transition est terminer

Représentation d'état finale.

En UML un évènement spécifie qui c'est passé quelque chose de significative localisé dans le temps  est dans, dans le contexte de machines a états finie il représente l'occurrence d'un stimulus  qui peut  déclenchée une transition entre états.

Quand un évènement est reçue, une transition peut être déclenché et faire basculer l'objet dans un  nouvel état. Ont peut divisé les évènements  en plusieurs types: signale, appel, changement, et  temporaire,

les  différent types :

    _ la réception d'un signal : envoyé par un autre objet pour un acteur, l'envoi d'un signal est  généralement asynchrone

   _ l'appel d'opération sur l'objet récepteur : l'évènement d'appel est généralement synchrone. Ces  évènements sont des méthodes déclarées au niveau des classes.

   _ Le passage de temps : qui se modélise en utilisant le mot clés « After » suivi d'un expression  représentant une durée décomptée à partir de l'entée dans l'état courant.

– Un changement dans la satisfaction d'une condition Q utilise  alors le mot clés « When »  suivi d'une expression booléenne l'évènement de changement se produit lorsque les  conditions passent a créée.

– Confrontation des diagrammes d'état avec les diagrammes de séquence et d’interaction :

EV0 EV1

Ev1/ seuil Ev2 EV1 EV2

la confrontation permet de montrer :

• la complémentarité entre :

• les diagrammes d’interaction (séquence communication).

• Les diagrammes d'états transitions.

Cette complémentarité et fondamentale.

Les diagrammes d'états apporte précision est exhaustivité et permettent de validé et de compléter les  diagrammes d’interaction. Ils peuvent également inciter a crée de nouveau diagrammes 

d’interaction pour compléter ce qui existe déjà.

• Commentaire de schéma :

Le schéma représente les relations entre les deux diagramme.

Prenons un diagramme de séquence simple mettant en jeu deux objets a de la classe A et b de la  classe B, l’interaction entre les deux objets consiste en l'enchainement de deux événements :

– Suite à la réception EV0 « a » envoie « EV1 à « b ».

– En retrouve « b » envoie l’évènement EV2 à « a »

Les diagrammes d'état des classes « A » et « B » doivent forcement être cohérent avec cette  interaction nous les avons représenter partiellement le long de la ligne de vie de chaque objet ainsi  l'objet « a » et dans l'état EA0 avant de recevoir l'événement EB0 puit passe dans le nouvel état EA1 

a : A b : B

EA0 EB1

EA1

EA2 EB2

aprés avoir envoyé l’évènement EV1 a l'objet B. l’évènement doit entre admissible à ce moment la  par l’automate de la classe B qui va a sont tour changer d'état après avoir répondu par l’évènement  EV2 à l'objet « a ». de nouveau cela signifie que dans l'état EA1 l'objet « a » doit être traiter 

l'élèvement EV2.   Nous voyant donc que l'on doit être capable de suivre toute les interactions entre  objet sur les diagrammes d'états les classes concerner, ce sont des contrainte à vérifier 

Il existes des relations diverses entres les principaux concepts du modèles statiques (objet, classe,  association, attribut et opération) et les principaux concepts dynamiques (messages, évènements,  états, activités), les plus importants sont les suivantes :

• un message peut être un appel d'opération sur un objet (le récepteur) par un autre objet  (l’émetteur)

• un évènement ou une activité sur une transition peuvent correspondre a l'appel d'une  opération 

• une activité peu concerner l'exécution complexe ou une succession d'opérations. 

• Une condition de garde et un « changevent » peuvent consulter des attributs ou des liens  statiques 

• une activité sur une transition peut manipuler des attributs ou des liens statiques.

Le paramètre d'un message peut être un attribue ou un objet 

il ne faut oublier de mettre à jour les digrammes de classe a fin de profiter de l'analyse réalisé avec  les différents diagrammes dynamiques. Vérifier également la bonne affectation des opérations.

1­ Create (Nom, nature) 2­ 

– Le paramètre date de départ prévue correspond a un attribut de la classe.

– Le paramètre nom du messages de création correspond probablement a l'attribut référence. Il  faut donc mettre à jour l'un des deux diagrammes pour arrondis.

– L'affectation cet destination (agence) illustre le fait qu'une activité sur une transition peut  utilisé des attribut ou des liens. Ici l'affectation crée un lien avec un objet de la classe agence  qui prend le rôle de destination par rapport a l'objet concerner de la classe mission.

– Le message tonnage estimer correspond au résultat d'un traitement réalisé par l'objet mission  qui ce traduit ici par une opération de calcule et un attribut pour mémorisé le résultat.

– Le message validé date départ prévue correspond directement a l'invocation de l'opération  validé sur l'objet mission concerner. Avec comme paramètre un des attribut deja répertorié. 

– Confronter les modèles statique et dynamiques :

exercice :

Gestion d'un club de chasse sous marin : les classes :

– Chasseur 

– Pseudo

– date de naissance

– nom

– prénom

– adresse

– Partie de chasse

– date

– N° chasse

– les espèces.

– Désignation.

– Poids moyen

– Niveau de tir

– code_niveau

– nbrs_points

– difficulté de chasse

– lieu 

– code lieu

– désignation lieu

Exercice2 :

processus d’approvisionnement a partir des demandes d'approvisionnement établie les acheteur  envoi des demande de prix des articles a commandé au fournisseurs possibles. Les fournisseurs  envoi des offres. Elle sont étudier en détaille et comparer entre elles par les acheteurs. Ces dernier  font un choix est établie un bon de commande a destination du fournisseur retenue. Quand la  livraison arrive, le magasinier quantitativement et caritative­ment la marchandise. La livraison est  renvoyé si l'un des contrôle est négative, si l'un des contrôle est satisfaisant les articles rentre en  stocke. Le magasinier établie un bon a payé au service  financier. Quand le financier reçoi la facture 

du fournisseur il vérifier qu'il correspond au bon a payé puis émet le chèque de payement.

Q:

– Identifier les acteurs

– élaborer le diagramme de cas d'utilisation.

– Élaborer un diagramme de séquence du cas d'utilisation: « préparer la commande »  Correction :

– Les acteurs

• Acteurs Principales : Acheteur, fournisseur, magasinier, financier.

• Acteur secondaire : 

– Le diagramme de contexte statique : Diagramme de séquence :