A Generic method for assembling software product line components

Software product lines (SPL) facilitate the industrialization of software development. The main goal is to create a set of reusable software components for the rapid production of a software systems family. Many authors propose different approaches to implement and assemble the reusable components of an SPL. However, the construction and assembly of these components continue to be a complex and time-consuming process. This thesis analyzes the advantages and disadvantages of the current approaches to implement and assemble the reusable components of an SPL. Taking advantage of these elements and with the goal of developing a generic method (which can be applied to several software components developed in different software languages), we develop Fragment-oriented programming (FragOP), a framework to design, implement and reuse SPL domain components. FragOP is based on: (i) domain components, (ii) domain files, (iii) fragmentation points, (iv) fragments, (v) customization points, and (vi) customization files. FragOP was implemented in an open-source tool called VariaMos, and we also carried out three evaluations: (i) we created a clothing stores SPL, derived five different products, and discussed the results. (ii) We developed a discussion about the comparison between FragOP and other approaches. And (iii) we designed and executed a usability test of VariaMos to support the FragOP approach. The results show preliminary evidence that the use of FragOP reduces the manual intervention when assembling SPL domain components and it can be used as a generic method for assembling assets and SPL components developed in different software languages.Las líneas de productos de software (LPS) promueven la industrialización del desarrollo de software mediante la definición y ensamblaje de componentes reutilizables de software. Actualmente existen diferentes propuestas para implementar y ensamblar estos componentes. Sin embargo, su construcción y ensamblaje continúa siendo un proceso complejo y que requiere mucho tiempo. Esta tesis analiza las ventajas y desventajas de las diferentes estrategias actuales para implementación y ensamblaje de componentes de LPS. Con base en esto y con el objetivo de desarrollar un método genérico (el cual se pueda aplicar a múltiples componentes de software desarrollados en diferentes lenguajes), esta tesis desarrolla la programación orientada a fragmentos (FragOP), la cual define un marco de trabajo para diseñar, implementar y reutilizar componentes de dominio de LPS. FragOP se basa en: (i) componentes de dominio, (ii) archivos de dominio, (iii) puntos de fragmentación, (iv) fragmentos, (v) puntos de personalización, y (vi) archivos de personalización. Además, se realizó una implementación de FragOP en una herramienta llamada VariaMos, y se llevaron a cabo tres evaluaciones: (i) se creó una LPS de tiendas de ropa, se derivaron cinco productos y se discutieron los resultados. (ii) Se realizó una discusión acerca de la comparación de FragOP y otras propuestas actuales. Y (iii) se diseñó una prueba de usabilidad acerca del soporte de VariaMos para FragOP. Los resultados muestran evidencia preliminar de que el uso de FragOP reduce la intervención manual cuando se ensamblan componentes, y que FragOP puede usarse como un método genérico para el ensamblaje de componentes.Doctorad

An Empirical Comparison of Reuse in Embedded and Nonembedded Systems

High-quality software, delivered on time and budget, constitutes a critical part of most products and services in modern society. Our government has invested billions of dollars to develop software assets, often to redevelop the same capability many times. Recognizing the waste involved in redeveloping these assets, in 1992 the Department of Defense issued the Software Reuse Initiative. The vision of the Software Reuse Initiative was To drive the DoD software community from its current re-invent the software cycle to a process-driven, domain-specific, architecture-centric, library-based way of constructing software.\u27\u27 Twenty years after issuing this initiative, there is evidence of this vision beginning to be realized in nonembedded systems. However, virtually every large embedded system undertaken has incurred large cost and schedule overruns. Investigations into the root cause of these overruns implicates reuse. Why are we seeing improvements in the outcomes of these large scale nonembedded systems and worse outcomes in embedded systems? This question is the foundation for this research. The experiences of the Aerospace industry have led to a number of questions about reuse and how the industry is employing reuse in embedded systems. For example, does reuse in embedded systems yield the same outcomes as in nonembedded systems? Are the outcomes positive? If the outcomes are different, it may indicate that embedded systems should not use data from nonembedded systems for estimation. Are embedded systems using the same development approaches as nonembedded systems? Does the development approach make a difference? If embedded systems develop software differently from nonembedded systems, it may mean that the same processes do not apply to both types of systems. What about the reuse of different artifacts? Perhaps there are certain artifacts that, when reused, contribute more or are more difficult to use in embedded systems. Finally, what are the success factors and obstacles to reuse? Are they the same in embedded systems as in nonembedded systems? The research in this dissertation is comprised of a series of empirical studies using professionals in the aerospace and defense industry as its subjects. The main focus has been to investigate the reuse practices of embedded systems professionals and nonembedded systems professionals and compare the methods and artifacts used against the outcomes. The research has followed a combined qualitative and quantitative design approach. The qualitative data were collected by surveying software and systems engineers, interviewing senior developers, and reading numerous documents and other studies. Quantitative data were derived from converting survey and interview respondents\u27 answers into coding that could be counted and measured. From the search of existing empirical literature, we learned that reuse in embedded systems are in fact significantly different from nonembedded systems, particularly in effort in model based development approach and quality where the development approach was not specified. The questionnaire showed differences in the development approach used in embedded projects from nonembedded projects, in particular, embedded systems were significantly more likely to use a heritage/legacy development approach. There was also a difference in the artifacts used, with embedded systems more likely to reuse hardware, test products, and test clusters. Nearly all the projects reported using code, but the questionnaire showed that the reuse of code brought mixed results. One of the differences expressed by the respondents to the questionnaire was the difficulty in reuse of code for embedded systems when the platform changed. The semistructured interviews were performed to tell us why the phenomena in the review of literature and the questionnaire were observed. We asked respected industry professionals, such as senior fellows, fellows and distinguished members of technical staff, about their experiences with reuse. We learned that many embedded systems used heritage/legacy development approaches because their systems had been around for many years, before models and modeling tools became available. We learned that reuse of code is beneficial primarily when the code does not require modification, but, especially in embedded systems, once it has to be changed, reuse of code yields few benefits. Finally, while platform independence is a goal for many in nonembedded systems, it is certainly not a goal for the embedded systems professionals and in many cases it is a detriment. However, both embedded and nonembedded systems professionals endorsed the idea of platform standardization. Finally, we conclude that while reuse in embedded systems and nonembedded systems is different today, they are converging. As heritage embedded systems are phased out, models become more robust and platforms are standardized, reuse in embedded systems will become more like nonembedded systems

A Hierarchical Core Reference Ontology for New Technology Insertion Design in Long Life Cycle, Complex Mission Critical Systems

Organizations, including government, commercial and others, face numerous challenges in maintaining and upgrading long life-cycle, complex, mission critical systems. Maintaining and upgrading these systems requires the insertion and integration of new technology to avoid obsolescence of hardware software, and human skills, to improve performance, to maintain and improve security, and to extend useful life. This is particularly true of information technology (IT) intensive systems. The lack of a coherent body of knowledge to organize new technology insertion theory and practice is a significant contributor to this difficulty. This research organized the existing design, technology road mapping, obsolescence, and sustainability literature into an ontology of theory and application as the foundation for a technology design and technology insertion design hierarchical core reference ontology and laid the foundation for body of knowledge that better integrates the new technology insertion problem into the technology design architecture

Combining SOA and BPM Technologies for Cross-System Process Automation

This paper summarizes the results of an industry case study that introduced a cross-system business process automation solution based on a combination of SOA and BPM standard technologies (i.e., BPMN, BPEL, WSDL). Besides discussing major weaknesses of the existing, custom-built, solution and comparing them against experiences with the developed prototype, the paper presents a course of action for transforming the current solution into the proposed solution. This includes a general approach, consisting of four distinct steps, as well as specific action items that are to be performed for every step. The discussion also covers language and tool support and challenges arising from the transformation

The Value Proposition of Service-Oriented Architecture

The author of this thesis evaluates Service-Oriented Architecture (SOA) design and implementation strategies. The purpose is to provide the reader with the definition of Service-Oriented Architecture. This report discusses: (1) The definition of Service-Oriented Architecture, (2) The problems solved by Service-Oriented Architecture, (3) Application of design principles to achieve Service-Oriented Architecture. As a result of this investigation, Service-Oriented Architecture is a design style that is fundamentally about sharing and reuse of functionality across diverse applications, so that organizations can quickly adapt to changing business requirements while increasing IT asset reuse and minimizing integration and development costs

Model-Driven Development of Aspect-Oriented Software Architectures

The work presented in this thesis of master is an approach that takes advantage of the Model-Driven Development approach for developing aspect-oriented software architectures. A complete MDD support for the PRISMA approach is defined by providing code generation, verification and reusability properties.Pérez Benedí, J. (2007). Model-Driven Development of Aspect-Oriented Software Architectures. http://hdl.handle.net/10251/12451Archivo delegad

Automated Injection of Curated Knowledge Into Real-Time Clinical Systems: CDS Architecture for the 21st Century

abstract: Clinical Decision Support (CDS) is primarily associated with alerts, reminders, order entry, rule-based invocation, diagnostic aids, and on-demand information retrieval. While valuable, these foci have been in production use for decades, and do not provide a broader, interoperable means of plugging structured clinical knowledge into live electronic health record (EHR) ecosystems for purposes of orchestrating the user experiences of patients and clinicians. To date, the gap between knowledge representation and user-facing EHR integration has been considered an “implementation concern” requiring unscalable manual human efforts and governance coordination. Drafting a questionnaire engineered to meet the specifications of the HL7 CDS Knowledge Artifact specification, for example, carries no reasonable expectation that it may be imported and deployed into a live system without significant burdens. Dramatic reduction of the time and effort gap in the research and application cycle could be revolutionary. Doing so, however, requires both a floor-to-ceiling precoordination of functional boundaries in the knowledge management lifecycle, as well as formalization of the human processes by which this occurs. This research introduces ARTAKA: Architecture for Real-Time Application of Knowledge Artifacts, as a concrete floor-to-ceiling technological blueprint for both provider heath IT (HIT) and vendor organizations to incrementally introduce value into existing systems dynamically. This is made possible by service-ization of curated knowledge artifacts, then injected into a highly scalable backend infrastructure by automated orchestration through public marketplaces. Supplementary examples of client app integration are also provided. Compilation of knowledge into platform-specific form has been left flexible, in so far as implementations comply with ARTAKA’s Context Event Service (CES) communication and Health Services Platform (HSP) Marketplace service packaging standards. Towards the goal of interoperable human processes, ARTAKA’s treatment of knowledge artifacts as a specialized form of software allows knowledge engineers to operate as a type of software engineering practice. Thus, nearly a century of software development processes, tools, policies, and lessons offer immediate benefit: in some cases, with remarkable parity. Analyses of experimentation is provided with guidelines in how choice aspects of software development life cycles (SDLCs) apply to knowledge artifact development in an ARTAKA environment. Portions of this culminating document have been further initiated with Standards Developing Organizations (SDOs) intended to ultimately produce normative standards, as have active relationships with other bodies.Dissertation/ThesisDoctoral Dissertation Biomedical Informatics 201