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

DEVELOPPEMENT LOGICIEL

CHAPITRE

3

 

Analyser et implémenter une solution informatique a toujours été une tâche rigoureuse. Elle requiert ainsi des connaissances particulières sur des méthodes d'analyse, les langages de modélisation et de programmation. Il sera d'abord question pour nous dans ce chapitre de présenter très brièvement l'outil d'analyse que nous avons utilisé pour implémenter les modules principaux de l'application. Ensuite produire un organigramme de fonctionnement de l'application et présenter les interfaces de l'application. Enfin nous ferons l'implémentation proprement dite de ces modules.

3.1. Analyse et conception

L'analyse et la conception d'une application font appel aux méthodes et langages de modélisation orientée objet. À chacune des différentes phases de la conception d'un logiciel correspondent des problèmes ou des contraintes différentes. Naturellement, ces niveaux ont fait l'objet de recherches méthodologiques considérables depuis les années 80. Il en résulte que de nombreuses méthodes de développement ou d'analyse de logiciel ont vu le jour, chacune plus ou moins spécialisée ou adaptée à une démarche particulière, voire à un secteur industriel particulier (bases de données, matériel embarqué, etc.). Celles-ci ayant été développées indépendamment les unes des autres, elles sont souvent partiellement redondantes ou incompatibles entre elles lorsqu'elles font appel à des notations ou des terminologies différentes.

De plus, à chaque méthode correspond un ou plusieurs moyens (plus ou moins formel) de représentation des résultats. Celui-ci peut être graphique (diagramme synoptique, plan physique d'un réseau, organigramme) ou textuel (expression d'un besoin en langage naturel, jusqu'au listing du code source). Dans les années 90, un certain nombre de méthodes orientées objets ont émergé, en particulier les méthodes :

· OMT (Object Modeling Technique) de James RUMBAUGH

· BOOCH de Grady BOOCH

·

35

OOSE (Object Oriented Software Engineering) de Ivar JACOBSON à qui l'on doit les Use Cases.

En 1994, on recensait plus de 50 méthodologies orientées objets. C'est dans le but de remédier à cette dispersion que les « poids-lourds » de la méthodologie orientée objets ont entrepris de se regrouper autour d'un standard.

En octobre 1994, Grady Booch et James Rumbaugh se sont réunis au sein de la société RATIONAL19 dans le but de travailler à l'élaboration d'une méthode commune qui intègre les avantages de l'ensemble des méthodes reconnues, en corrigeant les défauts et en comblant les déficits. Lors de OOPSLA'95 (Object Oriented Programming Systems, Languages and Applications, la grande conférence de la programmation orientée objets), ils présentent UNIFIED METHOD V0.8. En 1996, Ivar Jacobson les rejoint. Leurs travaux ne visent plus à constituer une méthodologie, mais un langage. Leur initiative a été soutenue par de nombreuses sociétés, que ce soit des sociétés de développement (dont Microsoft, Oracle, Hewlett-Packard, IBM - qui a apporté son langage de contraintes OCL -, ...) ou des sociétés de conception d'ateliers logiciels. Un projet a été déposé en janvier 1997 à l'OMG (Object Management Group, qui s'est rendu célèbre pour la norme CORBA20) en vue de la normalisation d'un langage de modélisation. Après amendement, celui-ci a été accepté en novembre 97 par l'OMG sous la référence UML-1.1. La version UML-2.0 est la plus rependue et la plus utilisée à nos jours. [16] C'est cette dernière que nous utiliserons pour la modélisation de notre application. Nous pouvons résumer l'historique de la constitution d'UML par la figure ci-dessous.

Figure 3.1 : historique de la constitution d'UML [16]

19 http://www.rational.com/UML/resources.html: site de RATIONAL (principal acteur de UML) 20 http://www.omg.org: Object Management Group

36

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








"Entre deux mots il faut choisir le moindre"   Paul Valery