La production de logiciels informatiques ne se résume pas à la réalisation de « gros » programmes nécessitant des années d'effort fournies par des équipes imposantes. Bien souvent, on a besoin de petits programmes, dont la durée de vie est assez courte et qui sont écrits par une ou deux personnes. La course incessante à l'innovation des entreprises informatiques les contraint fréquemment à renoncer aux techniques de génie logiciel pour opter pour des techniques légères favorisant un développement court et souple. Pour favoriser ce type de réalisations nous avons conçu un environnement de programmation qui repose sur un langage particulièrement concis et sur quelques outils permettant un développement rapide d'applications réalistes (un compilateur optimisant, des outils de mise au point, de navigation, etc.). Le choix du langage de programmation pour un tel projet est primordial car c'est le langage qui façonne le système. Au risque de paraître hérétique, nous avons choisi Scheme, un langage fonctionnel, parce que cette famille de langages permet une écriture d'une concision presque sans égal. Scheme est un petit langage. C'est parfois un atout (par exemple pour l'enseignement) mais c'est aussi souvent un handicap. Nous avons donc dû lui adjoindre de nombreuses extensions. Nous en présenterons deux au cours de cette soutenance: un langage de module et une couche objet. Nous nous efforcerons de montrer les liens reliant ces deux constructions et nous montrerons l'exploitation que nous avons faite de certaines caractéristiques de Scheme (comme, par exemple, le typage dynamique) pour augmenter encore l'expressivité de ce langage. Scheme est connu pour être difficile à implanter (parce que sa concision repose sur un haut niveau d'abstraction sémantique): c'est pourquoi nous avons consacré une grande partie de nos recherches à la compilation de ce langage. Nous présentons quelques uns de ces travaux dans le mémoire. Notre compilateur Scheme occupe une place privilégiée dans notre environnement car c'est lui qui permet la production d'applications efficaces. Toutefois, il arrive que les programmes doivent être travaillés afin que leur performances soient améliorées. Sur les architectures récentes c'est souvent une mauvaise utilisation de la mémoire (allocation, récupération) qui est la cause de performances moyennes. Lorsque le compilateur seul ne parvient pas à optimiser les programmes sources, les utilisateurs de notre environnement peuvent avoir recours à deux outils permettant l'étude de la gestion de la mémoire dans leurs applications.

Depuis quelques années, la manière de programmer des applications complexes subit d'importants bouleversements induits essentiellement par cette nouvelle informatique présente partout, dite ubiquitaire. Ces bouleversements imposent de concevoir de nouvelles approches pour le développement logiciel avec comme objectif d'obtenir des applications plus ouvertes et adaptables. Des concepts comme la programmation par composants (comme les EJB ou les Web Services), par séparations des préoccupations (la programmation par aspects), la programmation générative ou encore par transformation de modèle (l'approche MDA proposée par l'OMG) ont été proposées pour essayer de répondre partiellement à ces nouveaux défis. Notre contribution est de montrer que ces différents concepts peuvent être unifiés dans la notion de fabrique logicielle basée sur la programmation générative. Intuitivement, cette notion de fabrique logicielle permet, en faisant le parallèle à une chaîne de production, d'automatiser le plus possible, le développement logiciel pour une famille d'applications (de produits). Cette automatisation assure une plus grande fiabilité, réutisabilité et évolutivité des applications. La fabrique logicielle essaie de capitaliser les savoirs-faire des divers métiers sous-jacents à la chaîne de fabrication. Il est essentiel que le développement logiciel soit guidé par le domaine de l'application (Domain-Driven Development). Les concepts généraux des langages de programmation (classique) ne permettent pas de capturer aisément ces divers savoirs-faire. Plus précisément, nous monterons comment les concepts comme la programmations par composants, par transformations de modèle et par séparations de préoccupation sont instanciés et revisités dans notre démarche. Finalement, nous défendons l'idée que les langages de programmation actuels ont peu évolués face à ces bouleversements et sont en fin de compte, le vrai goulet d'étranglement de l'informatique. Lors de la présentation, nous insisterons plus sur les motivations, les objectifs et les concepts que sur les aspects purement techniques. Précisons tout de même que cette démarche a été validée dans la conception et la réalisation d'un générateur de fabrique logicielle, dénommé SmartTools. En effet, ce prototype de recherche permet de ce faire une idée précise et de matérialiser concrètement, cette nouvelle approche. De plus, cela montre très clairement que cette nouvelle approche du développement logiciel est envisageable à très court terme.

.

Ce mémoire a pour objectif de donner un aperçu précis et synthétique des activités de recherches que j'ai développées depuis le début de ma carrière d'enseignant-chercheur. Le travail qui va vous être présenté n'est pas le travail d'une seule personne mais le résultat de la collaboration avec plusieurs personnes que j'ai encadrées ou co-encadrées. Ce petit bout de vie dans la recherche doit bien sûr aussi beaucoup aux autres chercheurs ; je pense bien sûr à ceux du projet OCL et en particulier à Roger Rousseau mais aussi à tous ceux que j'ai rencontrés et côtoyés dans le laboratoire ou dans les divers congrès. Vous l'aurez donc compris toutes les idées présentées ci-après ne sont pas issues d'une seule personne, mais je revendique la démarche qui les a guidée. Je me suis intéressé dès mon stage de DEA aux problèmes liés à la conception de logiciels et en particulier aux aspects concernant la réutilisation, la fiabilité et l'évolution des applications. Ce document retrace mes contributions dans ce domaine.

Ce mémoire d'Habilitation à Diriger des Recherches présente mes contributions à la vérification formelle des processeurs et des programmes, ainsi qu'à la programmation par contraintes. La vérification formelle, tant de matériel que de logiciel, est cruciale pour la sécurité des systèmes critiques, est un enjeu économique important et reste un défi pour la recherche. Les méthodes de vérification formelle retenues, aussi bien pour la vérification des processeurs que des programmes sont des méthodes entièrement automatiques qui reposent sur l'utilisation de procédures de décision. Pour la vérification de programmes, la résolution de contraintes sur domaines finis fournit une procédure de décision sur les entiers bornés (codables en machine). L'explosion combinatoire est retardée par la combinaison de solveurs spécifiques (booléen, linéaires, domaines finis), ce qui a permis d'obtenir des résultats expérimentaux qui surpassent dans certains cas les outils de "bounded model checking" basés sur l'utilisation de solveurs SAT. Dans un second temps, la vérification formelle des programmes est également abordée sous l'angle du développement conjoint d'une vérification complète et d'une exploration par model checking, basés sur la sémantique formelle du langage définie dans l'assistant de preuves HOL4. Enfin, ce mémoire présente mes contributions sur les contraintes en domaines continus (i.e. où les variables sont des nombres réels). Ces contraintes ont de nombreuses applications pratiques, par exemple en mécanique ou avionique, et leurs mécanismes de résolution peuvent servir de base à la vérification de programmes en présence de nombres flottants.

<p>Examensarbetet utfördes åt företaget Medius AB. Arbetet bestod av att designa en ny process för Medius nuvarande och framtida dokumentationsbehov.</p><p>För att göra detta behövde tre steg slutföras. Först skulle information om dagens dokumenthantering inhämtas, vilka dokument skrivs av vem och för vem skrivs de och vilka behov finns det som idag kanske inte fylls. En grov lista över önskad funktionalitet togs också fram och därefter designades en process som klarar av att fylla alla dessa krav och behov. Sist skulle en lista över verktyg som behövs för den nya processen tas fram och en undersökning om vad som finns och vad som behöver byggas från grunden skulle genomföras. Alla dessa steg har genomförts och den nya processen har utvärderats genom enkäter till medlemmar ur ett antal olika fokusgrupper.</p><p>Resultatet av utvärderingen tyder på att det är lite arbete kvar att genomföra innan processen är redo att börja implementeras hos Medius, och dessutom behöver alla verktyg implementeras. När detta väl är klart kan den nya processen dock hjälpa Medius AB att lösa flera av de nuvarande problemen eller bristerna.</p>

<p>In this diploma thesis we have aimed to identify metrics that accommodate two chosen system quality factors and implementing the selected metrics in a metrics tool. The metrics chosen should measure change in the system quality factors reusability and maintainability for the middleware system COS at Telenor Mobile and similar systems. The metrics tool should support the aspect-oriented programming language AspectJ, and is planned to be a plugin to the open source code analysis framework XRadar. Changes due to introduction of aspects are of particular interest.</p><p>We have through a GQM process identified the following subcharacteristics for the chosen system quality factors: modularity, testability, analyzability, changeability and stability. Questions are formulated to analyze these sub factors, and metrics that can answer the questions are chosen.</p><p>We have implemented the tool AspectMetrics, which calculate metrics on Java and AspectJ code and generates an XML report containing the measurement results. A transformation from XML to HTML web pages is also provided. The metrics tool can measure size metrics, like the number of statements and the number of classes, coupling, fan-in/fan-out, cohesion and advice-in/advice-out. Advice-in and advice-out are two new metrics which respectively measures how many advice a class (or aspect) is affected by and how many joinpoints an advice hits on. These metrics are inspired by the concept for the fan-in and fan-out metrics.</p><p>The tool has been used to analyze two versions of the system DIAS v.2.0, which is a part of a diploma study in 2000. We have in our preparation project in 2003 added aspects to the DIAS system while keeping the system functionally equal to the original version. We have used our metrics tool to calculate the differences between the system with and the system without aspects. The introduction of aspects gave a positive change in coupling, fan-in/fan-out and size measures, while cohesion was negatively affected. The metrics thus, overall, indicated a positive change to the subcharacteristics testability, analyzability, changeability and stability and both the main quality factors. There was no indication of a positive change to modularity.</p><p>The analysis of the measurement results indicates that most of the metrics perform as intended. The size metrics, coupling, fan-in/fan-out, and advice-in/advice-out all gave results that corresponded to what we had expected. However, the cohesion measure did not behave in a way that could be correlated to the actual changes performed on the code. A closer analysis showed that moving and merging of functionality could result in either an increase or a decrease in cohesion. Thus we find that cohesion, at least in its current form, is not a suitable metric when using aspect-oriented programming. Further, this gave reason to reinvestigate the disappointing modularity results. With a reworked set of criteria we also found indication of improved modularity.</p>

Thesis (Ed. D.)--West Virginia University, 2007. / Title from document title page. Document formatted into pages; contains ix, 133 p. : ill. (some col.). Vita. Includes abstract. Includes bibliographical references (p. 83-90).

Project Management is the primary key to successful software development. In 1995 Caper Jones stated that the failure or cancellation rate of large software systems was over 20% in his article on patterns of large software systems. More than two thirds of the projects fail due to improper management of skills, activities, and personnel. One main reason is that software is not a tangible entity and is hard to visualize and hence to monitor. A manager has to be skilled in different CASE tools and technologies to track and manage a software development process successfully. The volume of results produced by these CASE tools is so huge that a high level manager cannot look into all the details. He has to get a high level picture of the project, to know where the project is heading, and if needed, then look into the finer level details by drilling down to locate and correct problems. The objective of this thesis is to build an Advanced Charting System (ACS), which would act as a companion to PAMPA 2 (Project Attribute Monitoring and Prediction Associate) and help a manager visualize the state of a software project over a standard World Wide Web browser. The PAMPA 2 ACS will be responsible for visualizing and tracking of resources, tasks, schedules and milestones of a software project described in the plan. PAMPA 2 ACS will have the ability to depict the status of the project through a variety of graphs and charts. PAMPA 2 ACS implements a novel charting technique called as DOT Chart to track the processes and activities of a software project. PAMPA 2 ACS provides a multilevel view of the project status. PAMPA 2 ACS will be able to track any arbitrary plan starting from a collapsed / concise view of a whole project. This can be further drilled down to the lowest level of detail. The status can be viewed at the project version level, plan and workbreakdown levels, process, sub process, and activity level. Among all the process models, the DOT charts can be applied effectively to spiral process model where each spiral represents a project version.

In this diploma thesis we have aimed to identify metrics that accommodate two chosen system quality factors and implementing the selected metrics in a metrics tool. The metrics chosen should measure change in the system quality factors reusability and maintainability for the middleware system COS at Telenor Mobile and similar systems. The metrics tool should support the aspect-oriented programming language AspectJ, and is planned to be a plugin to the open source code analysis framework XRadar. Changes due to introduction of aspects are of particular interest. We have through a GQM process identified the following subcharacteristics for the chosen system quality factors: modularity, testability, analyzability, changeability and stability. Questions are formulated to analyze these sub factors, and metrics that can answer the questions are chosen. We have implemented the tool AspectMetrics, which calculate metrics on Java and AspectJ code and generates an XML report containing the measurement results. A transformation from XML to HTML web pages is also provided. The metrics tool can measure size metrics, like the number of statements and the number of classes, coupling, fan-in/fan-out, cohesion and advice-in/advice-out. Advice-in and advice-out are two new metrics which respectively measures how many advice a class (or aspect) is affected by and how many joinpoints an advice hits on. These metrics are inspired by the concept for the fan-in and fan-out metrics. The tool has been used to analyze two versions of the system DIAS v.2.0, which is a part of a diploma study in 2000. We have in our preparation project in 2003 added aspects to the DIAS system while keeping the system functionally equal to the original version. We have used our metrics tool to calculate the differences between the system with and the system without aspects. The introduction of aspects gave a positive change in coupling, fan-in/fan-out and size measures, while cohesion was negatively affected. The metrics thus, overall, indicated a positive change to the subcharacteristics testability, analyzability, changeability and stability and both the main quality factors. There was no indication of a positive change to modularity. The analysis of the measurement results indicates that most of the metrics perform as intended. The size metrics, coupling, fan-in/fan-out, and advice-in/advice-out all gave results that corresponded to what we had expected. However, the cohesion measure did not behave in a way that could be correlated to the actual changes performed on the code. A closer analysis showed that moving and merging of functionality could result in either an increase or a decrease in cohesion. Thus we find that cohesion, at least in its current form, is not a suitable metric when using aspect-oriented programming. Further, this gave reason to reinvestigate the disappointing modularity results. With a reworked set of criteria we also found indication of improved modularity.