LLLALI
HISTORIQUE
Dans les années 1980, les méthodes utilisées pour organiser la programmation étaient fondée sur la modélisation séparée des données et des traitements (Merise, Axial,…). Au début des années 1990, lorsque la programmation par objets prend de l’importance, la nécessité d’une méthode qui lui soit adaptée devient évidente. Entre 1990-1995, plus de cinquante méthodes apparaissent (Booch, Classe-Relation, Fusion, OOSE, OMT, OOD, etc.) mais aucune ne s’est réellement imposée. En 1994, le premier consensus se fait autour de trois méthodes :
• OMT(Object Modeling Technique) de JamesRumbaugh(General Electric) qui représente les vues statiques, dynamiques et fonctionnelles d’un système ;
• OOD (Object Oriented Design) de GradyBooch, défini par le Department of Defense, introduit le concept d’élément d’organisation des modèles : package; NOTION SUR LE LANGAGE UML
• OOSE (Object Oriented Software Engineering) d’Ivar Jacobson (Ericsson) quifonde l’analyse sur la description des besoins des utilisateurs.
Entre 1995-1997, l’unification et la normalisation des méthodes ont évolué par étapes. En 1995, GradyBooch, JamesRumbaughet d’autres se sont mis d’accord pour élaborer une méthode unifiée nommée UnifiedMethod 0.8 ; en 1996, Ivar Jacobson les a rejoints pour fonder UML 0.9.Les acteurs les plus importants dans le monde du logiciel s’associent alors à l’effort (IBM, Rational, Microsoft, Oracle, Unisys, etc.). Cette collaboration a donné naissance à l’UML 1.0, un langage de modélisation bien défini, expressif, puissant, et généralement applicable. UML 1.0 est soumis à l’OMG en janvier 1997. Et en Novembre 1997, UML 1.1 est devenu une norme de l’OMG, ce qui lui a permis de s’imposer en tant que méthode de développement objet et d’être reconnu et utilisé par de nombreuses entreprises.
LA VUE « 4+1 » DE KRUCHTEN
Une architecture décrit les choix stratégiques qui déterminent en grande partie les qualités du logiciel telles que son adaptabilité, sa performance et sa fiabilité donc elle constitue un facteur clé du succès du développement. C’est pourquoi, Philippe Kruchten propose des différentes perspectives indépendantes et complémentaires qui permettent de définir un modèle d’architecture comme indique la figure ci-après. La représentation des cinq façons de voir un système (la vue « 4+1 ») qui ont fortement inspiré UML.
Les caractéristiques de la vue « 4+1 »:
La vue logique : la vue logique se concentre sur l’abstraction et l’encapsulation, et modélise les éléments et les mécanismes principaux du système; elle identifie les éléments du domaine, ainsi que leurs relations et interactions. Ces éléments sont liésau métier de l’entreprise et indispensable à la mission du système. selon les critères purement logiques, cette vue organise les éléments du domaine en catégories (repartir les tâches dans les équipes, regrouper ce qui est générique, isoler ce qui est propre à une version donnée, etc.)
La vue des composants : La vue des composants appelée aussi vue de réalisation montre: l’allocation des éléments de modélisation dans des modules (fichiers sources, bibliothèques dynamiques, bases de données, etc.); les modules qui réalisent les classes de la vue logique; l’organisation des modules en sous-système, les interfaces des sous-systèmes et leurs dépendances.
La vue des processus : La vue des processus est très importante dans les environnements multitâches car elle montre: la décomposition du système en termes de processus; les interactions entre les processus; la synchronisation et la communication des activités parallèles.
La vue de déploiement : La vue de déploiement a un rôle considérable dans les environnements distribués parce qu’elle décrit les ressources matérielles et la répartition du logiciel dans ces ressources portant sur : la disposition et la nature physique des matériels ainsi que leurs performances; l’implantation des modules principaux sur les nœuds du réseau; les exigences en termes de performance comme le temps de réponse, la tolérance aux fautes et pannes…
La vue des besoins des utilisateurs : La vue des besoins des utilisateurs appelée aussi « vue des cas d’utilisation » mène lesquatre autres vues de l’architecture. Elle consiste à: dessiner le plan ou bien l’architecture d’un système informatique et le justifier; définir les besoins des clients du système et l’architecture du système sur la réalisation de ces besoins; conduire à la définition d’un modèle d’architecture pertinent et cohérent à l’aide de scénarios et de cas d’utilisation; identifier les interfaces critiques et se concentrer sur les problèmes importants.
Diagramme d’objets
L’utilité du diagramme : Un diagramme d’objets représente des instances de classes et leurs relations pour rendre plus évident le modèle de classes en montrant un exemple qui explicite le modèle. Pour préciser certains aspects du système en évidence, des détails imperceptibles et une exception en modélisant des cas particuliers ou des connaissances généralisables non modélisées dans le diagramme de classe et pour prendre une image d’un système à un instant donné.
Lareprésentation du diagramme : Un objet est représenté par un rectangle contenant le nom de l’objet souligné précédé de deux points « : » ou la syntaxe nom_objet:nom_classepourinsister sur le type de l’objet. On peut mettre aussi le compartiment des attributs avec leurs valeurs affectées. Les relations du diagramme de classes deviennent des liens. Un lien se représente comme une relation mais s’il y a un nom, on doit le souligner et on ne met pas la multiplicité. La relation de généralisation ne possède pas d’instance alors on ne la figure jamais dans le diagramme d’objets.
APPROCHE ORIENTEE OBJET
L’approche orientée objet considère le logiciel comme une collection d’objets dissociés, identifiés et possédant des caractéristiques. Une caractéristique est soit attribut : une donnée caractérisant l’état de l’objet, soit une entité comportementale de l’objet : une fonction. La fonctionnalité du logiciel émerge alors de l’interaction entre les différents objets qui le constituent. L’une des particularités de cette approche est qu’elle rapproche les données et leurs traitements associés au sein d’un objet unique. Les concepts de base d’approche orientée objet comprennent : L’objet qui représente une entité du monde réel, ou de monde virtuel dans le cas d’objets immatériels, et se caractérisent pas une identité, des états significatifs et par un comportement. L’identité d’un objet permet de distinguer les objets les uns par rapport aux autres, indépendamment de son état. On construit généralement cette identité grâce à un identificateur naturellement du problème. L’état correspond aux valeurs de tous les attributs caractérisant l’objet. A vrai dire, ces attributs sont des variables stockant des informations d’état de l’objet. Le comportement d’un objet se définit par l’ensemble des opérations qu’il peut exécuter en réaction aux messages envoyés par les autres objets, tel qu’un message provoquel’exécution d’une opération d’un objet.
Exemple :On prend un exemple d’une Fenêtre : Identité : Fen1 ; Etat: position, taille, bordure, titre ;Opérations: restaurer, fermer, agrandir. Un Objet peut correspondre à :
− un objet concret du monde réel, ayant une réalité physique (une personne, une voiture, un outil, un système mécanique, . . .)
− un concept abstrait telun compte bancaire, le temps, une vitesse, . . .
− une activité produisant des effets observables (un calcul numérique, un pilote d’impression, . . .)
La classe :c’est un type abstrait de données caractérisées par des propriétés communes : attributs et méthodes à tous les objets de même famille et un mécanisme permettant de créer des objets ayant ces propriétés. N.B. : Lorsque des objets ont les mêmes attributs et comportements, ils sont regroupés dans une même classe et les objets appartenant à celle-ci constituent les instances de cette classe. L’encapsulation :il s’agit de un mécanisme consistant à rassembler les données et les méthodes au sein d’une structure en masquant les détails d’implémentation d’un objet, en définissant une interface qui est la vue externe offrant un service accessible aux utilisateurs. Les intérêts de l’encapsulation peuvent se résumer comme suit:
• D’une part, elle facilite l’évolution du modèle en stabilisant l’utilisation des objets, c’est-à-dire on peut modifier les détails internes d’une classe sans modifier son interface ; la façon de s’en servir ne change pas pour les utilisateurs (modèles, programmes,..) de la classe ;
• D’autre part, elle permet de garder une cohérence dans la gestion de l’objet, tout en assurant l’intégrité des données qui ne pourront être accédées qu’à l’aide des méthodes visibles, c’est-à-dire, elle peut interdire ou restreindre l’accès direct aux attributs des objets. L’héritage :c’est le mécanisme de constructiond’une classe à partir d’une ou plusieurs d’autres donc il permet d’assurer une grande variabilité dans la réutilisation des objets. Il existe deux techniques liées à l’héritage :
1. Laclasse abstraite qui est une classe ayant des propriétés qui ne permettent pas de préciser des instances. Cette classe met en commun un certain nombre de propriétés à des objets ;
2. L’héritage multiple qui permet à une classe d’avoir plusieurs classes dérivées et d’hériter ainsi de tous les attributs et méthodes de ces ancêtres.
N.B. : -La classe de base(super-classe, classe mère, parente, ancêtre) transmet toutes ses propriétés transmissibles(protected) aux classes dérivées (sous-classe, classe fille, enfant) ;
– La classe dérivée ne peut pas accéder aux membres privés de la classe de base ; elle possède ses propres attributs et méthodes, que la classe de base ne connaît pas et en plus, elle peut redéfinir ou améliorerles méthodes transmises par la classe de base. Le polymorphisme :ilpermet de définir plusieurs formes pour une méthode commune à une hiérarchie d’objets donc il représente la faculté d’une opération de s’appliquer à des objets de classesdifférentes.
N.B. :Le concept de polymorphisme ne doit pas être confondu avec celui d’héritage multiple. L’héritage multiple permet à un objet d’hériter des membres (champs et méthodes) de plusieurs objets à la fois, alors que le polymorphisme réside dans la capacité d’un objet à modifier son comportement propre et celui de ses descendants au cours de l’exécution.
|
Table des matières
Introduction
Chapitre I : NOTION SUR LE LANGAGE UML (Unified Modeling Language)
I.1 INTRODUCTION
I.2 HISTORIQUE
I.3 LA VUE « 4+1 » DE KRUCHTEN
I.4 DIAGRAMMES UML
I.4.1 DIAGRAMMES STATIQUES
I.4.2 DIAGRAMMES DYNAMIQUES
Chapitre II : NOTION SUR LA PROGRAMMATION ORIENTEE OBJET ET LA BASE DE DONNEES
II.1 LA PROGRAMMATION ORIENTEE OBJET
II.1.1 DEFINITION
II.1.2 APPROCHE ORIENTEE OBJET
II.1.3 LANGAGES ORIENTES OBJETS
II.2 LA BASE DE DONNEES
II.2.1 GENERALITES
II.2.2 SYSTEME DE GESTION DE BASES DE DONNEES
II.2.3 MODELE RELATIONNEL
II.2.4 MODELE OBJET
Chapitre III : APPROCHE DU SUJET
III.1 .PRESENTATION DU SUJET
III.1.1 PROBLEMATIQUE
III.1.2 OBJECTIFS DE L’ETUDE
III.1.3 DEROULEMENT DE TRAVAIL
III.2 MODELISATION AVEC UML
III.2.1 INTRODUCTION
III.2.2 REPRESENTATION DES DIAGRAMMES UML
Chapitre IV : LOGICIEL « GPAuto 1.0 »
IV.1 CONCEPTION DU LOGICIEL
IV.1.1 LANGAGE DE PROGRAMMATION C++
IV.1.2 COMPILATEUR
IV.1.3 IMPLEMENTATION DES CLASSES
IV.2 PRESENTATION DU LOGICIEL
IV.2.1 INSTALLATION ET LANCEMENT DU LOGICIEL
IV.2.2 INTERFACES GRAPHIQUES
Conclusion
Annexe
Bibliographie
Webograhie
Télécharger le rapport complet
