A comprehensive interface definition framework for software components

Component-based Development (CBD) is an important emerging topic in Software Engineering, promising long sought after benefits like increased reuse and reduced time-to-market (and hence software production cost). However, there are at present many obstacles to overcome before CBD can succeed. For one thing, CBD success is predicated on a standardised market place for software components, which does not yet exist. In fact currently CBD even lacks a universally accepted terminology. Existing component models adopt different component definitions and composition operators. Therefore much research remains to be done. We believe that the starting point for this endeavour should be a thorough study of current component models, identifying their key characteristics and comparing their strengths and weaknesses. A desirable side-effect would be clarifying and unifying the CBD terminology. In this tutorial, we present a clear and concise exposition of all the current major software component models, including a taxonomy. The purpose is to distill and present knowledge of current software component models, as well as to present an analysis of their properties with respect to commonly accepted criteria for CBD. The taxonomy also provides a starting point for a unified terminology.

Software modules and components have always played a key role in software engineering, primarily as coarse-grained abstractions that embody the principle of information hiding. The fundamental contribution of component-based software engineering lies in making the black-box property a core requirement. In this paper we point out that this important notion tends to be neglected in component model analyses, and define the black-box property in terms of detailed characteristics which help to evaluate component models from this perspective. A survey of typical representatives of industrial and research component models shows that especially the former ones leave much to be desired, and the paper discusses the consequences of the weak aspects of their design.

Component-Based Software Development (CBSD) is an approach that has many benefits, such as improving application developer productivity, reducing costs and complexity by reusing of existing codes. Programming within this approach is like assembly (i.e. composing software out of prefabricated components) rather than development, which reduces skill requirements, and allows expertise focuses on domain problems. The foundation of any CBSD methodology is its underlying component model, which defines what components are, how they can be constructed, and specifies the standards and conventions that are needed to enable composition of independently developed component. The current component models do not support composition in both design and deployment phase. They also focus on the specification and packaging of components but provide almost no support for the easy composition of components. Component in these models uses either direct or indirect message passing as connection schemes, which leads to tightly coupling (i.e. components mix computation with control). It is conclude that this research has proposed an effective way for component composition which provides loosely coupling between composed components. For system maintenance and evolution, this decoupling should make it simpler to manage changes in the components, and also changes in the connector separately. This research has resulted in the proposed of mediator connector which is similar to a communication hub. It initiates method calls and manages the returns, and also provides total loosely coupling between components and also itself. Mediator connector is a framework and can be reused without any modification. The components composition using mediator connector belongs to the deployment phase. Our approach is based on interactions between components as a subset of behavior in a system. In order to minimize coupling between components and mediator connector, we have designed and developed an XML-based language, called Component Interaction Markup Language (CIML), where components as well as their interactions are described in a CIML document which are used by mediator connector. For evaluation of mediator connector in order to measure the loosely coupling it provides, four case studies have been tested. To measure coupling we applied Coupling Between Object (CBO) software metric. The result shows that mediator connector provides totally loosely coupling between software components composing in the deployment phase.

Abstract: The fast growth of high-bandwidth wide-area networks has encouraged the development of computational grids. To deal with the increasing complexity of grid applications, the software component technology seems very appealing since it emphasizes software composition and re-use. However, current software component models only support explicit data transfers between components through remote procedure call (RPC), remote method invocation (RMI) or event based ports. The distributed shared memory paradigm has demonstrated its utility by enabling a transparent access to data via a globally shared data space. Data localization, replication and transfer as well as synchronization of concurrent accesses are delegated to an external data-sharing service. This paper proposes to extend software component models with shared memory capabilities: a) a transparent access to shared data, and b) the possibility to use shared data as parameters of operations provided by component ports. The proposed model is instantiated as an extension of the CORBA Component Model (CCM) and the Common Component Architecture (CCA), using the transparent data access model provided by the JUXMEM grid data-sharing service. Key-words: data sharing, component, grid, JUXMEM

Portable and embedded devices form an increasingly large group of computers, often referred to as ambient intelligence (AmI). This new variety in computing platforms cause a corresponding diversity in software/hardware platforms and other context factors. Component-based middleware platforms offer a uniform environment for software, but they do not take away specific context differences, such as hardware resources, user identity/role and logical/physical location. Specialised component versions and/or configurations have to be made for each computing context if that computing context is to be used to its full extent. This is because the fine differences between component versions cannot be separated into finer components with the current component models. Aspect-oriented programming and generative programming technologies can be used to provide the fine-grained modularity that is necessary. In addition, the diversity of component-based platforms themselves form an extra reason for different component versions. We propose using a context-driven framework for the development of AmI components, which is based upon a gradual refinement mechanism. This refinement mechanism can cope with the course-grained differences between component models as well as the fine-grained differences between computing configurations.

A component framework plays an important role in CBSD as it determines how software components are developed, packaged, assembled and deployed. A desirable component framework for developing diverse cross-domain embedded applications should meet such requirements as (1) lightweight on memory use, (2) integrated task execution model, (3) fast inter-component communication, (4) support for distributed processing, and (5) transparency from underlying communication middleware. Although current embedded system component frameworks address some of the above requirements, they fail to meet all of them taken together. We thus propose a new embedded system component framework called CREAM (component-based remote-communicating embedded application model). It achieves these goals by using build-time code generation, explicit control of task creation and execution in the component framework, static analysis of component composition to generate efficient component binding, and abstraction of the componentpsilas application logic from the communication middleware. We have implemented the CREAM component framework and conducted a series of experiments to compare its performance characteristics to a raw socket-based communication implementation and the lightweight-CCM implementation by MicoCCM.

Componentware is a new paradigm in software development that is based on the concept of a software component. Software components are self‐contained, immutable units of software which can be distributed over large networks or even over the Internet. The distribution of software components requires new, Internet‐based search and retrieval mechanisms. A set of collaborating software components is called componentware. We discuss the architectural requirements and mechanisms of componentware, a technical realisation of a componentware architecture, and identify obstacles in building componentware. Finally, we propose possible solutions for the realisation of componentware and componentware architectures.

Robot software components, which can be accessed through their interface, are reusable and replaceable software modules used in composing robotic services. Using robot software components in developing a robot, developers can expect shortening of developing times, reduction of maintenance cost and improvement of program reusability, because interoperability among components is guaranteed. We have developed a component framework assisting robot developers to make robot application with ease. The component framework consists of a specification of component model, a component authoring tool, a component composer, and a component container. In this paper, we will not only show the developed component framework, but also demonstrate its usability by applying to commercial robots.

Modern component retrieval approaches are based on the context and domain of the software component in addition to using various classification and retrieval techniques like keyword search, attribute-based search and semantic search. This work proposes ontological retrieval framework for software components that makes the use of ontology for effective retrieval of components. Ontological component retrieval framework has been created to facilitate the users and developers to retrieve software components matching precisely to their needs. A well-framed set of queries ranging from little to specific knowledge about the component requirement has been used to validate the results.

Modern software development is based on a systems approach, in which a program or software complex is considered as a system of interacting software components. Models of software components are analogs of complex system subsystems. Therefore, a complex program is considered as a system of software components. The organization of the structure of software components affects the quality and result of the program. The organization of interaction between software components affects the efficiency of the program. An important factor in the system of software components is the life cycle, which determines the effectiveness and feasibility of using this program. Software differs from many complex systems and information systems in that it has the ability to increase its life cycle. Moreover, the need to increase the life cycle is characterized by two factors: external and internal. The internal factor arises due to the obsolescence of the program. In this case, it does not meet the new conditions, for example, a new operating system. The external factor arises from external influences in the form of interference or purposeful actions, such as computer viruses. The problem of creating the structure of software components of computing systems and information systems that ensure the duration of the life cycle in the presence of external influences is topical. The study of this problem contributes to the improvement of the technological base of computing systems and information systems that solve applied problems. The article presents a new life cycle model based on two models of growth and degradation. The article recommends a resource-based approach for life cycle assessment. As an analytical solution, it is proposed to use a logistic equation, which describes the mechanisms of the life cycle formation process quite well. The article discusses three types of resource in calculations: physical, technological and communicative. A general redundancy solution is proposed to create a network with the inclusion of a multigraph model.

According to Szyperski, “a software component is a unit of composition with contractually specified interfaces and explicit context dependencies only”. But it is well known that these contractually specified interfaces should go well beyond mere syntactic aspects: they should also involve functional, synchronization and Quality of Service (QoS) aspects. In large, mission-critical component based systems, it is also particularly important to be able to explicitly relate the QoS contracts attached to provided interfaces with the QoS contracts obtained from required interfaces. In this paper we propose a language called QoSCL (defined as an add-on to the UML2.0 component model) to let the designer explicitly describe and manipulate these higher level contracts and their dependencies. We show how the very same QoSCL contracts can then be exploited for (1) validation of individual components, by automatically weaving contract monitoring code into the components; and (2) validation of a component assembly, including getting end-to-end QoS information inferred from individual component contracts, by automatic translation to a Constraint Logic Programming language. We illustrate our approach with the example of a GPS (Global Positioning System) software component, from its functional and contractual specifications to its implementation in a .Net framework.

VIOLAS: A vision-based sensing system for sentient building models

Designing Adaptive Mesh Refinement based applications is a very complex task. The aim of this paper is to study whether component models could simplify their conception and which concepts are needed. The analysis is based on an implementation of an AMR method on top of two component models, ULCM and SALOME.

Preface. 1. Introduction. 1.1 What is COP? 1.2 Why is COP important? 1.3 What is a component? 1.4 Hardware components and software components. 1.5 From OOP to COP. 1.6 Component-based software engineering. 1.7 Summary. 1.8 Self-review questions. 1.9 Exercises. 2. A Theory of Components. 2.1 Principles of COP. 2.2 Infrastructures of COP. 2.3 Component models. 2.4 Connection models. 2.5 Deployment models. 2.6 Unifying component technologies. 2.7 Summary. 2.8 Self-review questions. 2.9 Exercises. 3. COP with JavaBeans. 3.1 Overview of JavaBeans technology. 3.2 The component model of JavaBeans. 3.3 The connection model of JavaBeans. 3.4 The deployment model of JavaBeans. 3.5 Examples and lab practice. 3.6 Summary. 3.7 Self-review questions. 3.8 Exercises. 4. Enterprise JavaBeans Components. 4.1 The EJB a rchitecture. 4.2 The component model of EJB. 4.3 The connection model of EJB. 4.4 The deployment model of EJB. 4.5 Examples and lab practice. 4.6 Summary. 4.7 Self-review questions. 4.8 Exercises. 4.9 Programming exercises. 5. CORBA Components. 5.1 The COBRA component infrastructure. 5.2 The CORBA component model (CCM). 5.3 The connection model of CORBA and CCM. 5.4 The deployment model of CORBA and CCM. 5.5 Examples and lab practice. 5.6 Summary. 5.7 Self-review questions. 5.8 Exercises. 5.9 Programming exercises. 6. .NET Components. 6.1 The .NET framework. 6.2 The component model of .NET. 6.3 The connection model of .NET. 6.4 .NET component deployments. 6.5 Visual Studio .NET. 6.6 Examples and lab practice. 6.7 Summary. 6.8 Self-review questions. 6.9 Exercises. 6.10 Programming exercises. 7. COP with OSGi Components. 7.1 Overview of OSGi technology. 7.2 The component model of OSGi. 7.3 The connection model of OSGi. 7.4 The deployment model of OSGi. 7.5 Examples and lab practice. 7.6 Summary. 7.7 Self-review questions. 7.8 Exercises. 8. Web Services Components. 8.1 The Web Services framework. 8.2 The component model of Web Services. 8.3 The connection model of Web Services. 8.4 Web Services component deployment. 8.5 Examples and lab practice. 8.6 Summary. 8.7 Self-review questions. 8.8 Exercises. 8.9 Programming exercises. Appendix.

Little is known about the compliance of risk management models with the industrial practice and vice versa. In this paper, we compare the industrial risk management practice against a risk management model that we have synthesized from a set of current risk management models. This comparison has resulted in several discrepancies observed. As a result, this paper suggests a list of issues that need to be addressed in both the industrial and standard models.