Component Based Systems Development Adoption and Diffusion

Component Based Development (CBD) has caught the attention of academics and practitioners alike. Building upon sound Object-Oriented principles, CDB has a strong conceptual foundation as well as extensive practical orientation and application. CBD approaches promise the potential to deliver quality systems in a short period of time with opportunities for component reuse to further reduce cost that seems especially appropriate for the myriad of e-business systems that are a focal point of many organizations’ contemporary systems development portfolios. Indeed, numerous commercial organizations are supplying components that can be relatively easily integrated to create cost-effective systems. Interestingly, however, CBD is currently not applied extensively. The prospective reasons are many. Management is currently ill-informed and not committed to the CBD approach as they often lack knowledge of the benefits of adopting CBD. Further, many system developers, system analysts and programmers are not aware of CBD issues and opportunities. Possible reasons could be that they received their software education a long time ago (e.g. five or ten years ago or more), and are only familiar with traditional approaches. There is also considerable confusion with regard to component granularity and CBD focus. To some, the focus is on creating the components while to others, the focus is on creating systems by integrating components. A question exists as to the role of education and research given this situation. Numerous opportunities exist for academics to play a leading role in creating awareness and removing uncertainties in exploring CBD concepts and application. However, little attention is currently being given to CBD, especially in teaching. Like IS professionals, many educators are hesitant to change from traditional development perspectives currently being taught as they face faculty development challenges. By in large, few have had experience in this area and easily fall back to what they learned historically. Further, there is a dearth of textbooks and educational material available to assist academic in the teaching process. Research seems to be fragmented and lacking coherency in focus. Research, teaching and practice all seem to be going in different directions

Méthodologie de transformation du CIM en PIM dans l'approche MDA

L’Object Management Group (OMG) a proposé une nouvelle approche de développement de logiciel nommée Model Driven Architecture (MDA). Cette approche met l’accent sur l’élaboration des modèles de plus haut niveau d’abstraction et favorise l’approche de transformation d’un modèle à l’autre. MDA préconise l’élaboration des trois types de modèles suivants : • Computation Independent Model (CIM) : ce modèle représente le plus haut niveau d’abstraction et décrit les exigences du système ainsi que sa manière de fonctionner dans son environnement tandis que les détails de la structure de l’application et de la réalisation sont cachés ou encore indéterminés. • Platform Independent Model (PIM) : ce modèle décrit les détails du système sans montrer les détails spécifiques à une plateforme d’exécution ou à une technologie particulière. • Platform Specific Model (PSM) : ce modèle décrit les détails et les caractéristiques supprimés du PIM. Il doit être adapté pour spécifier l’implémentation du système dans une seule et unique plateforme technologique. Comme ces différents types de modèles représentent différents niveaux d’abstraction d’un même système, MDA recommande l’utilisation de mécanismes de transformation permettant les transformations du CIM vers le PIM et du PIM vers le PSM. Depuis l’avènement de MDA, plusieurs travaux de recherche ont abordé la problématique de transformation du PIM vers le PSM et du PSM vers le code mais très peu traitent de la transformation du CIM vers le PIM. Bien que la littérature présente quelques travaux reliés à cette question, il semble que peu de chercheurs se soient penchés sur les problèmes reliés à la transformation du CIM vers le PIM. Ainsi, le CIM a été initialement considéré comme partie intégrante du PIM. Bien que la notion de l’indépendance de la plateforme soit assez claire, la notion du concept ‘’Computation’’ reste floue. Par conséquent, la frontière entre les modèles CIM et PIM reste aussi vague. Dans le but de transformer le CIM en PIM, nous avons identifié les trois problématiques de recherche suivantes : 1) la définition de l’architecture du CIM permettant de circonscrire ses frontières par rapport au PIM, 2) la définition de l’architecture du PIM permettant de circonscrire ses frontières par rapport au PSM, 3) la définition d’une méthodologie permettant de transformer le CIM en PIM. La contribution de cette thèse s’inscrit dans le domaine de l’ingénierie dirigée par les modèles. Nous y proposons : 1) une architecture du CIM basée sur la composition de trois modèles Business Motivation Model (BMM), Business Process Model (BPM) et Requirement Model (RM), 2) une architecture du PIM basée sur les patrons d’analyse et les patrons archétype, 3) une méthodologie couvrant l’ensemble des étapes de création du CIM ainsi que les techniques et les artefacts à produire, permettant la transformation du CIM en PIM. Ce travail contribue de plus à l’amélioration de la traçabilité entre le CIM et le PIM ainsi qu’à la réduction du fossé entre les activités des analystes d’affaires et des architectes de logiciels

Graph-based Pattern Matching and Discovery for Process-centric Service Architecture Design and Integration

Process automation and applications integration initiatives are often complex and involve significant resources in large organisations. The increasing adoption of service-based architectures to solve integration problems and the widely accepted practice of utilising patterns as a medium to reuse design knowledge motivated the definition of this work. In this work a pattern-based framework and techniques providing automation and structure to address the process and application integration problem are proposed. The framework is a layered architecture providing modelling and traceability support to different abstraction layers of the integration problem. To define new services - building blocks of the integration solution - the framework includes techniques to identify process patterns in concrete process models. Graphs and graph morphisms provide a formal basis to represent patterns and their relation to models. A family of graph-based algorithms support automation during matching and discovery of patterns in layered process service models. The framework and techniques are demonstrated in a case study. The algorithms implementing the pattern matching and discovery techniques are investigated through a set of experiments from an empirical evaluation. Observations from conducted interviews to practitioners provide suggestions to enhance the proposed techniques and direct future work regarding analysis tasks in process integration initiatives