Spelling suggestions: "subject:"orientéeobjet"" "subject:"orientéobjet""
1 |
Un cadre d'application pour la visualisation des métriques orientées objetDufresne, Pascal January 2003 (has links)
Mémoire numérisé par la Direction des bibliothèques de l'Université de Montréal.
|
2 |
L'interface native de Nit, un langage de programmation à objetsLaferrière, Alexis 03 1900 (has links) (PDF)
L'interface native permet à un logiciel de profiter des avantages des langages natifs ainsi que de ceux du langage de haut niveau. Elle intervient entre les différents langages pour permettre les appels de méthodes et la conversion des données. Son utilisation amène cependant généralement une perte de sûreté à l'exécution du logiciel et son emploi est souvent complexe. Dans le cadre de cette recherche, nous développons l'interface native du langage de programmation à objets Nit. Notre recherche vise à résoudre au mieux les problèmes soulevés par l'utilisation d'une interface native, et ce, par une analyse rigoureuse des différents détails de conception d'une interface. Notre intention est donc de concevoir, selon des objectifs précis, l'interface native idéale pour le langage Nit. Pour mettre à l'épreuve notre proposition, nous avons conçu et implémenté l'interface native du compilateur Nit. La conception de cette interface native s'appuie donc sur des objectifs que nous considérons garants d'une interface native de qualité. Ces objectifs consistent à préserver la sûreté d'exécution du logiciel, maintenir une connaissance du flot d'appels, utiliser le langage Nit de façon expressive et selon ses forces, conserver une syntaxe naturelle en C ainsi qu'offrir une interface native versatile et d'utilisation rapide par tout autre moyen. Pour atteindre ces objectifs, nous proposons quatre grandes approches clés : la forme des modules hybrides pour gérer la coexistence de deux langages; une déclaration explicite des appels de méthodes réalisées depuis le langage C pour conserver la connaissance du flot d'appels; une représentation symétrique des types et méthodes Nit en C pour en permettre une utilisation naturelle et vérifiée statiquement; les classes natives qui représentent les types C en Nit et leur appliquent les forces du paradigme de programmation à objets, dont le polymorphisme. Enfin, pour valider l'interface native proposée et implémentée, nous présentons comment nous avons utilisé cette interface pour réaliser des modules et des logiciels Nit. Nous démontrons également que cette interface peut être utilisée dans le développement d'autres interfaces spécialisées en fonction de besoins spécifiques.
______________________________________________________________________________
MOTS-CLÉS DE L’AUTEUR : interface native, interface de fonctions étrangères, compilation, langages de programmation à objets
|
3 |
Développement d'une base de données orientée-objets pour l'étude de la dynamique des changements d'utilisation du sol et des changements de propriétaires dans la municipalité de Godmanchester au QuébecBruel, Mireille January 2002 (has links)
Mémoire numérisé par la Direction des bibliothèques de l'Université de Montréal.
|
4 |
Bocal ou la boîte comme paradisgme programmatique : application à la simulation de systèmes productifsHamadeh, Ayman 27 October 1993 (has links) (PDF)
Le sujet présenté dans cette thèse consiste à concevoir un langage de programmation, appelé BOCAL, spécialement destiné à la modélisation et à la simulation de systèmes de production. La spécification et la simulation d'automates est également un domaine d'application de BOCAL. Les logiciels sont souvent partagés entre deux caractéristiques importantes : les logiciels extensibles (ouverts) mais pas assez conviviaux et les logiciels conviviaux mais fermés pour les utilisateurs. L'objectif de ce langage est de permettre à tous les niveaux d'utilisation (conception des objets de base, construction du modèle et réglage des paramètres) de fonctionner dans le même environnement sémantique afin de permettre à tous les utilisateurs de bénéficier de la modularité et de l'extensibilité.
|
5 |
Contribution à la conception logicielle de systèmes d'applications : la méthode MOSAIC dans le projet AristoteBrissaud, Frédéric 12 May 1993 (has links) (PDF)
Les sgbd orientes objets integrent les concepts des langages a objets et les mécanismes des sgbd. Ces propriétés les rendent bien adaptes au développement de systèmes d'applications regroupant plusieurs applications interactives opérant sur des données persistantes partagées (si, agl...). L'état de l'art développe porte sur la programmation, les bases de données et les interfaces homme-machine et montre qu'il existe différentes techniques spécifiques adaptées au développement de certaines parties de ces applications. Cependant, aucune methode de conception actuelle ne prend en compte la conception complète et détaillée d'un système d'applications et le concepteur est insuffisamment guide pour programmer une application a l'aide d'un sgbdoo. Notre methode mosaic permet de développer un système d'applications programme a l'aide d'un sgbdoo. Notre approche consiste a privilégier une décomposition dirigée par les objets au détriment de l'habituelle séparation entre la base de données et les programmes d'application. Ainsi une application comporte deux composants principaux. Le corps de l'application est constitue d'objets applicatifs, modèles du domaine d'application, et le gestionnaire de dialogue de l'application est compose d'objets interactifs, modèles du dialogue. Les objets applicatifs, persistants ou temporaires, sont a la fois des modules logiciels et des conteneurs de données potentiellement persistantes ou temporaires. Les objets interactifs regroupent les informations et les actions présentées a l'utilisateur et assurent leur cohérence. Un système d'applications est compose d'une base d'objets applicatifs persistants et d'applications. Le modelé mosaic permet d'étudier les dimensions structurelles, fonctionnelles et dynamiques des objets et du système d'applications dans sa globalité. Des langages textuels et graphiques, un outil, une démarche et des regles de traduction de mosaic vers le langage peplom et vers le sgbdoo o2 complètent ce modèle. Nos propositions sont illustrées par un exemple d'application programme a l'aide d'o2
|
6 |
Identification et localisation des préoccupations fonctionnelles dans un code légataire JavaEl Kharraz, Amal 06 1900 (has links)
Traditionnellement, les applications orientées objets légataires intègrent différents aspects fonctionnels. Ces aspects peuvent être dispersés partout dans le code. Il existe différents types d’aspects :
• des aspects qui représentent des fonctionnalités métiers ;
• des aspects qui répondent à des exigences non fonctionnelles ou à d’autres considérations de conception comme la robustesse, la distribution, la sécurité, etc.
Généralement, le code qui représente ces aspects chevauche plusieurs hiérarchies de
classes. Plusieurs chercheurs se sont intéressés à la problématique de la modularisation de ces aspects dans le code : programmation orientée sujets, programmation orientée aspects et programmation orientée vues. Toutes ces méthodes proposent des techniques et des outils pour concevoir des applications orientées objets sous forme de composition de fragments de code qui répondent à différents aspects. La séparation des aspects dans le code a des avantages au niveau de la réutilisation et de la maintenance. Ainsi, il est important d’identifier et de localiser ces aspects dans du code légataire orienté objets.
Nous nous intéressons particulièrement aux aspects fonctionnels. En supposant que
le code qui répond à un aspect fonctionnel ou fonctionnalité exhibe une certaine cohésion
fonctionnelle (dépendances entre les éléments), nous proposons d’identifier de telles fonctionnalités à partir du code. L’idée est d’identifier, en l’absence des paradigmes de la programmation par aspects, les techniques qui permettent l’implémentation des différents aspects fonctionnels dans un code objet. Notre approche consiste à :
• identifier les techniques utilisées par les développeurs pour intégrer une fonctionnalité
en l’absence des techniques orientées aspects
• caractériser l’empreinte de ces techniques sur le code
• et développer des outils pour identifier ces empreintes.
Ainsi, nous présentons deux approches pour l’identification des fonctionnalités existantes dans du code orienté objets. La première identifie différents patrons de conception qui permettent l’intégration de ces fonctionnalités dans le code. La deuxième utilise l’analyse formelle de concepts pour identifier les fonctionnalités récurrentes dans le code.
Nous expérimentons nos deux approches sur des systèmes libres orientés objets pour
identifier les différentes fonctionnalités dans le code. Les résultats obtenus montrent
l’efficacité de nos approches pour identifier les différentes fonctionnalités dans du code
légataire orienté objets et permettent de suggérer des cas de refactorisation. / Object oriented applications integrate various functional aspects. These aspects can
be scattered everywhere in the code. There are various types of aspects :
• aspects which represent business functionalities ;
• aspects related to non functional requirements or to design concerns such as robustness, distribution, and security.
The code representing such aspects can be located in different class hierarchies. Researchers have been interested in the problem of the modularisation of these aspects and many approaches were proposed : oriented programming subjects, oriented programming Aspects and oriented programming view. These approaches offer techniques and
tools for designing object oriented applications based on the composition of slices of various aspects. The main benefit of the separation of aspects is supporting reuse and maintenance. Consequently, it is well worth identifying and extracting aspects of legacy object oriented applications.
Our work mainly focuses on functional aspects. Assuming that the code of a functional aspect or a feature has a functional cohesion (dependencies between elements), we suggest methods for identifying such features from the code. The idea is to identify, in the absence of any aspect oriented paradigm, the techniques used for implementing a feature in the code. Our approach consists of :
• identifying techniques used by developers to integrate a feature in the absence of
aspect oriented techniques
• characterizing the patterns of these techniques
• and developing tools to identify these patterns.
We present two approaches for the identification of the existing features in the object oriented code. The first one identifies various design patterns which integrates these features in the code. The second approach uses the formal concept analysis to identify the recurring features in the code. We experiment our approaches to identify functional features in different open source object oriented applications. The results show the efficiency of our approaches in identifying various functional features in the legacy object oriented, and can some times suggest refactoring.
|
7 |
Identification et localisation des préoccupations fonctionnelles dans un code légataire JavaEl Kharraz, Amal 06 1900 (has links)
Traditionnellement, les applications orientées objets légataires intègrent différents aspects fonctionnels. Ces aspects peuvent être dispersés partout dans le code. Il existe différents types d’aspects :
• des aspects qui représentent des fonctionnalités métiers ;
• des aspects qui répondent à des exigences non fonctionnelles ou à d’autres considérations de conception comme la robustesse, la distribution, la sécurité, etc.
Généralement, le code qui représente ces aspects chevauche plusieurs hiérarchies de
classes. Plusieurs chercheurs se sont intéressés à la problématique de la modularisation de ces aspects dans le code : programmation orientée sujets, programmation orientée aspects et programmation orientée vues. Toutes ces méthodes proposent des techniques et des outils pour concevoir des applications orientées objets sous forme de composition de fragments de code qui répondent à différents aspects. La séparation des aspects dans le code a des avantages au niveau de la réutilisation et de la maintenance. Ainsi, il est important d’identifier et de localiser ces aspects dans du code légataire orienté objets.
Nous nous intéressons particulièrement aux aspects fonctionnels. En supposant que
le code qui répond à un aspect fonctionnel ou fonctionnalité exhibe une certaine cohésion
fonctionnelle (dépendances entre les éléments), nous proposons d’identifier de telles fonctionnalités à partir du code. L’idée est d’identifier, en l’absence des paradigmes de la programmation par aspects, les techniques qui permettent l’implémentation des différents aspects fonctionnels dans un code objet. Notre approche consiste à :
• identifier les techniques utilisées par les développeurs pour intégrer une fonctionnalité
en l’absence des techniques orientées aspects
• caractériser l’empreinte de ces techniques sur le code
• et développer des outils pour identifier ces empreintes.
Ainsi, nous présentons deux approches pour l’identification des fonctionnalités existantes dans du code orienté objets. La première identifie différents patrons de conception qui permettent l’intégration de ces fonctionnalités dans le code. La deuxième utilise l’analyse formelle de concepts pour identifier les fonctionnalités récurrentes dans le code.
Nous expérimentons nos deux approches sur des systèmes libres orientés objets pour
identifier les différentes fonctionnalités dans le code. Les résultats obtenus montrent
l’efficacité de nos approches pour identifier les différentes fonctionnalités dans du code
légataire orienté objets et permettent de suggérer des cas de refactorisation. / Object oriented applications integrate various functional aspects. These aspects can
be scattered everywhere in the code. There are various types of aspects :
• aspects which represent business functionalities ;
• aspects related to non functional requirements or to design concerns such as robustness, distribution, and security.
The code representing such aspects can be located in different class hierarchies. Researchers have been interested in the problem of the modularisation of these aspects and many approaches were proposed : oriented programming subjects, oriented programming Aspects and oriented programming view. These approaches offer techniques and
tools for designing object oriented applications based on the composition of slices of various aspects. The main benefit of the separation of aspects is supporting reuse and maintenance. Consequently, it is well worth identifying and extracting aspects of legacy object oriented applications.
Our work mainly focuses on functional aspects. Assuming that the code of a functional aspect or a feature has a functional cohesion (dependencies between elements), we suggest methods for identifying such features from the code. The idea is to identify, in the absence of any aspect oriented paradigm, the techniques used for implementing a feature in the code. Our approach consists of :
• identifying techniques used by developers to integrate a feature in the absence of
aspect oriented techniques
• characterizing the patterns of these techniques
• and developing tools to identify these patterns.
We present two approaches for the identification of the existing features in the object oriented code. The first one identifies various design patterns which integrates these features in the code. The second approach uses the formal concept analysis to identify the recurring features in the code. We experiment our approaches to identify functional features in different open source object oriented applications. The results show the efficiency of our approaches in identifying various functional features in the legacy object oriented, and can some times suggest refactoring.
|
Page generated in 0.0602 seconds