WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception et réalisation d'une application de gestion du presse-papier de Windows 7.

( Télécharger le fichier original )
par MAKA MAKA Ebenezer NOUMBO NGUETSOP Stephane Cedric
ENSET DE DOUALA - DIPET II 2013
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

3.1.2.2. La vue dynamique

La vue dynamique est orientée algorithme et traitement, elle vise à décrire l'évolution (la dynamique) des objets complexes du programme tout au long de leur cycle de vie. De leur naissance à leur mort, les objets voient leurs états changés et ce à cause de leur interaction avec d'autres objets du programme. La vue dynamique est constituée des diagrammes d'états, des diagrammes d'activité, des diagrammes de séquence et des diagrammes de communication.

Diagramme de séquence :

Un diagramme de séquence sert à la description d'un scénario possible dans la description d'un cas d'utilisation d'une fonction. Les diagrammes de séquences mettent en valeur les échanges de messages (déclenchant des événements) entre acteurs et objets (ou entre objets et objets) de manière chronologique (l'évolution du temps se lisant de haut en bas). Chaque colonne correspond à un objet (décrit dans le diagramme des classes), ou à un acteur (introduit dans le diagramme des cas). La ligne de vie de l'objet représente la durée de son interaction avec les autres objets du diagramme. Notons que le même besoin dans un logiciel peut être réalisé à travers plusieurs scénarios, dans ce cas on aura donc plusieurs diagramme de séquence pour ce même besoin.

41

Diagramme de séquence associé à chaque cas d'utilisation :

Gérer une collection : une collection est gérée par un utilisateur, le logiciel lui-même et le système d'exploitation dans le quel tourne l'application.

Figure 3.7 : Diagramme de séquence de la gestion d'une collection.

42

Gérer un groupe : un groupe est contenu dans une collection. Pour cela on suppose qu'une collection a été démarrée. Le diagramme de séquence ci-dessous est celui d'un groupe qui sera créé et contenu dans une collection.

Figure 3.8 : Diagramme de séquence de la gestion d'un groupe.

Gérer une copie : une copie est contenue dans un et un seul groupe. Pour cela on suppose que le comportement de la copie dont le diagramme de séquence est donné ci-dessous est dans un groupe qui lui-même est dans une collection ; bien évidemment le groupe et la collection étant ouverts.

43

Figure 3.9 : Diagramme de séquence de la gestion d'une copie.

Ces diagrammes de séquences nous ont permis d'avoir un comportement détaillé de chaque objet de notre application et de ressortir les différentes méthodes associées à chacun d'eux. Tout ceci étant fait on peut donc présenter la vue statique de notre application.

3.1.2.3. La vue structurelle ou statique

La vue structurelle présente la structuration des données et identifie les objets/composants constituant le programme, leurs attributs, opérations et méthodes, ainsi que les liens ou associations qui les unissent. Elle regroupe également les classes fortement liées entre elles en des composants les plus autonomes possibles. Cette vue a pour objectif principal de modéliser la structure des différentes classes d'une application orientée objet ainsi que leurs relations [18]. La vue statique est constituée des diagrammes de classes, des diagrammes de

44

packages, des diagrammes d'objets, des diagrammes de structure composite, des diagrammes de déploiement.

· Le diagramme de classe :

Le diagramme de classe est le diagramme le plus important dans la modélisation UML (il est le diagramme prioritaire pour les outils de génération automatique de code). Ces diagrammes sont représentés avec plus ou moins d'exhaustivité selon que l'on est en phase d'analyse, de conception ou d'implémentation. Avant de dessiner un diagramme de classe il est donc important de tenir compte de la phase dans laquelle on se trouve ; ainsi donc :

En phase d'implémentation on cherche à décrire chaque classe, ses attributs et ses méthodes en pensant déjà au code qui les implémentera tout en prenant en compte les contraintes matérielles de temps d'exécution, d'architecture, etc.

Présentation des concepts utilisés dans le diagramme de classe

Les concepts élémentaires que nous présentons dans cette section sont les plus employés pour la réalisation de la vue structurelle d'un modèle UML et ceux que nous avons utilisé pour la réalisation de notre diagramme de classe.

Une classe :

De façon sémantique : En UML, une classe définit la structure commune d'un ensemble d'objets et permet la Construction d'objets instances de cette classe. Une classe est identifiée par son nom. [18]

De façon graphique : Une classe se représente à l'aide d'un rectangle sous forme de tableau à une colonne et trois lignes ; qui contient le nom de la classe (première ligne et éventuellement le nom du package auquel elle appartient) viennent ensuite les propriétés (deuxième ligne) de la classe puis ses opérations (troisième ligne). La Figure 3.11 illustre la classe nommée User.

Les propriétés ou attributs

Pour une classe, une propriété peut être vue comme une forme simple d'association entre les objets (instances) de la classe et un objet de classe standard. Il s'agit d'une variable qui est en général propre à l'objet ou qui est peut être commun à tous les objets de la classe (on parle alors de propriété de classe). Dans un diagramme de classe les propriétés de la classe sont notées de la façon suivante :

<NomAttribut> : <Type> = [<valeur par défaut>]. (Voir deuxième ligne Figure 3.11)

Les opérations

Une opération peut être vue comme une tâche que doit effectuer l'objet lorsqu'on lui fait appel. En programmation elle représente une méthode de la classe. Dans un diagramme de classe la notation des opérations se fait de la façon suivante :

<NomOpération> (ListeParamètres) : <TypeRetour>(Voir troisème ligne Figure 3.11) On distingue deux catégories d'opérations :

· celles qui modifient l'état de l'objet (ses attributs) : ces opérations sont appelées modifiants ou mutateurs.

· A l'opposé des opérations d'accès ou accesseurs qui ne se contentent que de retourner la valeur d'une propriété.

De ce qui précède on a donc la Figure 3.11 suivante :

User

IdUser : integer Nom : string

Creer( ) Demarrer( ) Changer ( )

 

Figure 3.11 : Représentation graphique d'une classe

Les associations

Les associations représentent des relations entre objets, c'est-à-dire entre des instances de classes. Aux extrémités d'une association figure la multiplicité (cardinalité) qui est une énumération sous forme d'intervalle d'entiers positifs ou nuls indiquant le nombre d'objets qui peuvent participer à une relation avec l'objet de l'autre classe dans le cadre d'une association. Les multiplicités sont notées de la manière suivante

1 : Obligatoire (un et un seul)

0..1 : Optionnel (0 ou 1)

0..* ou * : Quelconque

n..* : Au moins n

n..m : Entre n et m (n et m en entier)

I,n,m : I, n, ou m

45

Les multiplicités les plus utilisées sont : 1,*, 1..* et 0..1.

46

Ayant présenté de façon très brève les concepts du diagramme de classe, et les informations acquises lors de la réalisation des diagrammes de cas d'utilisation et de séquence ; ces informations nous ont permis d'avoir le diagramme de classe suivant :

Figure 3.12 : Diagramme de classe de l'application PressePapier1.0

· Le diagramme de package

Un package est un regroupement de classes présentant des liens sémantiques entre elles. Le regroupement de classes en package est une activité délicate mais d'une importance capitale dans les logiciels de grande taille. Le regroupement de classes en packages les plus indépendants possibles améliore la modularité du logiciel et son développement par des équipes séparées (en évitant les interactions) ou encore en utilisant les classes statiques déjà développées et pouvant se mettre en relation avec les classes de l'application qu'on veut

47

implémenter. La structuration d'un modèle en package doit respecter deux principes fondamentaux à savoir : la cohérence et l'indépendance.

La cohérence consiste à regrouper les classes qui sont proches d'un point de vue sémantique.

Le principe de l'indépendance vise à concentrer les efforts pour minimiser les relations entre les packages (autrement dit les relations entre classes de packages différents).

Les classes de la Figure 3.12 étant en relation avec les classes statiques du système d'exploitation dont un héritage n'est possible il est vient donc qu'il soit possible de les mettre en relation grâce aux packages. D'où les packages suivant :

Figure 3.13 : Package de l'application PressePapier1.0

Figure 3.14 : Package des classes du système d'exploitation

48

Des Figure 3.13 et Figure 3.14 on obtient le diagramme de package suivant :

49

Figure 3.14 : Diagramme de package du PressePapier1.0.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Nous voulons explorer la bonté contrée énorme où tout se tait"   Appolinaire