Designing software components for future reuse has been an important area in software engineering. A software system developed with reusable components follows a "with" reuse process while a component designed to be reused in other systems follows a "for" reuse process. This dissertation explores the factors affecting design for reuse and design with reusable components through empirical studies. The studies involve Java components implementing a particular algorithm, a stemming algorithm that is widely used in the conflation domain. The method and empirical approach are general and independent of the programming language. Such studies may be extended to other types of components, for example, components implementing data structures such as stacks, queues etc. Design for reuse: In this thesis, the first study was conducted analyzing one-use and equivalent reusable components for the overhead in terms of component size, effort required, number of parameters, and productivity. Reusable components were significantly larger than their equivalent one-use components and had significantly more parameters. The effort required for the reusable components was higher than for one-use components. The productivity of the developers was significantly lower for the reusable components compared to the one-use components. Also, during the development of reusable components, the subjects spent more time on writing code than designing the components, but not significantly so.  A ranking of the design principles by frequency of use is also reported. A content analysis performed on the feedback is also reported and the reasons for using and not using the reuse design principles are identified. A correlation analysis showed that the reuse design principles were, in general, used independently of each other. Design with reuse: Through another empirical study, the effect of the size of a component and the reuse design principles used in building the component on the ease of reuse were analyzed. It was observed that the higher the complexity the lower the ease of reuse, but the correlation is not significant. When considered independently, four of the reuse design principles: well-defined interface, clarity and understandability, generality, and separate concepts from content significantly increased the ease of reuse while commonality and variability analysis significantly decreased the ease of reuse, and documentation did not have a significant impact on the ease of reuse. Experience in the programming language had no significant relationship with the reusability of components. Experience in software engineering and software reuse showed a relationship with reusability but the effect size was small. Testing components before integrating them into a system was found to have no relationship with the reusability of components. A content analysis of the feedback is presented identifying the challenges of components that were not easy to reuse. Features that make a component easily reusable were also identified. The Mahalanobis-Taguchi Strategy (MTS) was employed to develop a model based on Mahalanobis Distance  to identify the factors that can detect if a component is easy to reuse or not. The identified factors within the model are: size of a component, a set of reuse design principles (well-defined interface, clarity and understandability, commonality and variability analysis, and generality), and component testing. / Ph. D.

The ability of the software engineering community to achieve high levels of reuse from software frameworks has been tempered by the difficulty in understanding how to reuse them properly. When written correctly, a plugin can take advantage of the framework’s code and architecture to provide a rich application with relatively few lines of code. Unfortunately, doing this correctly is difficult because frameworks frequently require plugin developers to be aware of complex protocols between objects, and improper use of these protocols causes exceptions and unexpected behavior at run time. This dissertation introduces collaboration constraints, rules governing how multiple objects may interact in a complex protocol. These constraints are particularly difficult to understand and analyze because they may extend across type boundaries and even programming language boundaries. This thesis improves the state of the art through two mechanisms. First, it provides a deep understanding of these collaboration constraints and the framework designs which create them. Second, it introduces Fusion, an adoptable specification language and static analysis tool, that detects broken collaboration constraints in plugin code and demonstrates how to achieve this goal in a cost-effective manner that is practical for industry use. In this dissertation, I have done an empirical study of framework help forums which showed that collaboration constraints are burdensome for developers, as they take hours or even days to resolve. From this empirical study, I have identified several common properties of collaboration constraints. This motivated a new specification language, called Fusion, that is tailored for specifying collaboration constraints in a practical way. The specification language uses relationships to describe the abstract associations between objects and allows developers to specify collaboration constraints as logical predicates of relationships. Since a relationship is an abstraction above the code, this allows developers to easily specify constraints that cross type and language boundaries. There are three variants of the analysis: a sound variant that has false positives but no false negatives, a complete variant that has false negatives but no false positives, and a pragmatic variant that attempts to balance this tradeoff. In this dissertation, I successfully used Fusion to specify and analyze constraints from examples found in the help forums of the ASP.NET and Spring frameworks. Additionally, I ran Fusion on DaCapo, a 1.5 MLOC DaCapo benchmark for program analysis, to show that Fusion is scalable and provides precise enough results for industry with low specification cost. This dissertation examines many tradeoffs: the tradeoffs of framework designs, the tradeoffs of specification precision, and the tradeoffs of program analysis results are all featured. A central theme of this work is that there is no single right solution to collaboration constraints; there are only solutions that work better for a particular instance of the problem.

Dokumento tikslas yra pristatyti pakartotinio panaudojimo technologijos, komponentais grįsto projektavimo ir metaprojektavimo aspektų simbiozės. Simbiozė realizuojama per programinės įrangos architektūros modelį ir rinkinį pakartotinio panaudojimo komponentų, kurie sukurti įtraukti galutinį vartotoją į programinės įrangos procesą kaip projektuotoją. / The aim of this paper is to present symbiosis of reuse technology, component based design and meta-project aspects. Symbiosis occurs through software architectural model and set of reusable components designed to involve end-user to software development process as designer. Theoretical background of specified model is delivered in the beginning sections of this thesis. As experimental solution information system was introduced. System provides a pack of highly configurable and customizable components designed to achieve common tasks. Unexpected or rare tasks are solved by providing extra components, which are developed and integrated to entire system according predefined rules. Several complete definitions and application areas of those components are given. Paper also includes statistics about reusable component life cycle in different software projects: how often they are reused and for what purpose. Thesis is concluded with pros and cons of suggested model.

MSc thesis - Faculty of Engineering / Service creation in the Next Generation Network (NGN) is focused around software creation and borrows heavily from the Software Engineering community. In the NGN, telecommunication companies demand simple, rapid and economical service creation. The key to this type of service creation is software re-use. Software re-use is a conundrum where limited, dedicated solutions exists. These solutions include amongst others Enterprise JavaBeansTM (EJBs), design patterns and object-oriented programming. The Telecommunications Information Networking Architecture- Conformance And Testing (TINA-CAT) workgroup has done work on a functionality centric concept called RP-facets. This report proposes a redefinition of RP-facets, as Facets, for software re-use across the design and code level. We redefine Facets as functionality centric reusable components. A Facet is independent of the implementation language and the execution platform. Facets allow containment in a structured manner via a user defined Facet Hierarchy. Facets are resource, context and data agnostic. They also introduce a structured way to allow source code to be changed based on design level decisions. Also, possessing the ability to allow the simultaneous use of other reuse solutions and programming paradigms. Abstraction of detail from developers and platform migration can be achieved by using Facets. Facets are composed of a Generic definition and any number of Implementation definitions. The definitions are supported by an underlying informational model called meta-¼. Meta- ¼ is a model at the M3 meta-level that focuses on describing entities. Most of the Facet’s capabilities are enabled by the meta-¼ model. An environment for developing Facets is created, called the Facet Development Environment (FDE). The Facet Developer (FD) role is introduced to develop and maintain Facets. The FD verifies programmes from programmers to be included into the catalogue of Facets via the FDE. The FD interacts with service creation teams to determine which Facets can be used in the service they wish to develop. Facets prove their capability in targeted areas, yet lack in other categories. It is recommended that the underlying informational model should be revised to form a more robust and flexible entity describing model. In addition, a cataloging capability to easily find Facets with particular functionality should be appended to the capabilities of the facet. It is proposed, for future work, that a development environment be created that encompasses a process for using Facets to create services.