A Look at Current Component Models from the Black-Box Perspective

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.

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.

Component bused software engineering (CBSE) represents an exciting and promising paradigm for software development, attracting much interest and effort from industrial practice and scientific research. Software components are one of the key issues in CBSE. While practical, the current component models are limited in providing support for CBSE. We introduce a framework aimed at comprehensive interface modelling for software components in the context of CBSE. This framework deals with interface signature, interface constraints, interface packaging and configurations, and non functional properties of software components.

This challenges and open problems paper discusses the role of software engineers when combining modeling with Search-Based Software Engineering (SBSE). With SBSE techniques increasingly providing insights into difficult software modeling problems, the role of the software engineer might be thought of as diminishing. However, given the crucial role of the model understanding in SBSE, we argue that the role of the software engineer will become more important through interactive SBSE, although exploiting this interaction remains a challenge for the field.

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.

Logicians may want to consider the following statements: Engineers use mathematics in their Software Engineers do not use mathematics in their What should we conclude from these axioms? would conclude that Software Engineers are not Engineers. Others would conclude that the first statement must be incorrect and should read, All Engineers except Software Engineers use mathematics in their work. They would argue that mathematics is irrelevant in software development. Still others would conclude that, Some of the people who now call themselves Software Engineers are not qualified to do so. Although much of the mathematics developed by Computer Scientists is not very practical, this talk will argue that mathematics can and should play a central role in software engineering. It will show how classical engineering concepts can be applied in software development. 3rd IEEE International Conference on Formal Engineering Methods (ICFEM'00)

Empirical research is playing a significant role in software engineering (SE), and it has been applied to evaluate software artifacts and technologies. There have been a great number of empirical research articles published recently. There is also a large research community in empirical software engineering (ESE). In this paper, we identify both the overall landscape and detailed implementations of ESE, and investigate frequently applied empirical methods, targeted research purposes, used data sources, and applied data processing approaches and tools in ESE. The aim is to identify new trends and obtain interesting observations of empirical software engineering across different sub-fields of software engineering. We conduct a mapping study on 538 selected articles from January 2013 to November 2017, with four research questions. We observe that the trend of applying empirical methods in software engineering is continuously increasing and the most commonly applied methods are experiment, case study and survey. Moreover, open source projects are the most frequently used data sources. We also observe that most of researchers have paid attention to the validity and the possibility to replicate their studies. These observations are carefully analyzed and presented as carefully designed diagrams. We also reveal shortcomings and demanded knowledge/strategies in ESE and propose recommendations for researchers.

In response to the enormous annual dollar value spent on software, major emphasis is being placed within industry, Government and academia on the establishment of a rigorous discipline for the development of software—i. e., on the establishment of software engineering. This has significance in the realm of computer system simulation for two basic reasons: first, computer system simulation (any simulation for that matter) does itself involve the development of software; and second, computer system simulation is a technique/tool which can be applied to the discipline of software development. It will be the purpose of this workshop to discuss both the role of software engineering in computer system simulation and the role of computer system simulation in software engineering. Potential topics for discussion include, but are not limited to: a. Identification of software engineering b. Disciplines required for software engineering c. Software engineering in support of computer system simulation d. Computer system simulation as a tool in software engineering e. Recent progress in the direction of establishing the software engineering discipline.

Autistic individuals possess many unique skills that are beneficial to the workforce, especially the technology industry. However, research shows the unemployment rate is still considerably high among the autistic population compared to their neurotypical peers. It has been suggested that some autistic individuals may excel in software engineering roles. This paper presents a Multivocal Literature Review (MLR) to highlight the cognitive style and talents of individuals with Autism Spectrum Disorder (ASD). An analysis is carried out to fully understand the challenges faced by autistic individuals transitioning into the workplace while also highlighting the challenges faced in their day to day working life. These challenges include workplace environments as well as workplace ceremonies, including, for example, daily stand-up meetings. Many neurotypical software engineers, software engineering firms and academics can benefit from this information as they work towards a more inclusive and more effective software engineering community.

Logic is not only of foundational importance in mathematics, it is also playing a big role in software engineering and formal verification. Its different roles influence its teaching, which has to take into consideration the recent developments in category theory and proof theory. We show that teaching set theory from a categorical viewpoint, in contrast with Zermelo-Fraenkel axioms, helps develop proper skills that are essential in mathematics and software engineering. The use of a proof assistant provides students with another perspective on both subjects: basic category theory and proof theory.

: The Software Engineering Institute is undertaking a feasibility study of component-based software (CBSE). The objective of this study is to determine whether CBSE has the potential to advance the state of software engineering practice and, if so, whether the SEI can contribute to this advancement. This report is the second part of a three-part report on the study. Volume I contains a market assessment for CBSE. Volume III outlines a proposed course of action for the SEI. Volume II, this report, establishes the technical foundation for SEI work in CBSE. The paper asserts that the key technical challenge facing CBSE is to ensure that the properties of a system of components can be predicted from the properties of the components themselves. The key technical concepts of CBSE that are needed to support this vision are described: component, interface, contract, component model, component framework, composition, and certification.

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.

An important role in software engineering is played by design notations. The Agent UML (AUML) notation for sequence diagrams has been widely used to capture the design of interactions between agents. However, AUML is not precisely defined, and there is very little in the way of tool support available. We argue that using a textual notation allows the notation to be precisely defined, and facilitates the development of tool support. We present a textual notation that we have developed, and describe a number of tools that support this notation. One of these tools is a 'renderer' which takes a textual AUML protocol and generates the standard graphical view. The layout of graphical elements in the generated graphical view is done automatically, using a layout algorithm which we present.

Conservative extensions of logical theories play an important role in software engineering. They provide a formal basis for program refinement and guarantee the integrity and transparency of modules and objects. This paper studies conservative extension ideas in the context of default logic. In particular, we define several alternative concepts, study their properties, and derive interconnections among the concepts. The main result provides an interesting distinctive feature of Reiter's default logic over some well-known variants.

The role of design pattern in the form of software metric and internal code architecture for object-oriented design plays a critical role in software en-gineering in terms of production cost efficiency. This paper discusses about code reusability that is a frequently exercised cost saving methodology in IT produc-tion. After reviewing existing literatures towards study on software metrics, we found that very few studies are witnessed to incline towards code reusability. Hence, we developed a simple analytical model that establishes relationship between the design components of standard software metric and code reusability using case studies of three software projects (Customer Relationship Management project, Supply Chain Management project, and Enterprise Relationship Management project). We also testify our proposal using stochastic based Markov model to find that proposed system can extract significant information of maximized values of code reusability with increasing level of uncertainties of software project methodologies.