Chapter 1 Introduction
[Back to Home Page] [Next Chapter]
Despite advances in software development techniques, such as object-oriented programming (OOPSLA, 2006), aspect-oriented programming (Kiczales et al., 1997) and component-based development (Cheesman and Daniels, 2001), existing implementation abstractions are not used on a large scale to create new systems, therefore the majority of software is still built from scratch (Greenfield et al., 2004).
Software systems are projected to become ever more complex in the future (Corbi, 1989). This will require increased time and effort when developing new software systems (Voas, 1998; Meyer and Mingins, 1999; Zweben et al., 1995) making such development even less feasible in the future (Meyer and Mingins, 1999).
Not only is it imperative that we begin developing software artifacts that are reusable to address this agenda (Voas, 1998; Meyer and Mingins, 1999; Washizaki et al., 2002), but it is also desirable with respect to software maintenance. Software artifacts that are reusable and replaceable (Cheesman and Daniels, 2001), will facilitate software evolution and help to curb the time spent on maintenance and evolution, an activity (Leintz and Swanson, 1980) that accounts for up to 80% of the entire development process (Bowen et al., 1993; Seaman, 2002)(It should be noted that a comprehensive survey of software maintenance has not been carried out since that of Lientz and Swanson in 1978 (Leintz and Swanson, 1980; Lientz and Swanson, 1978). However, the increased complexity of software systems (Pressman, 2004) and observing the longevity of software systems such as Microsoft Word (Microsoft, 2006b), or Adobe Acrobat (Inc., 2006), suggests, if anything, that the proportion of effort consumed in manufacturing and evolving software systems has increased since their landmark study).
Software reuse refers to the construction and evolution of software systems from existing software assets rather than creating a new system from scratch (Krueger, 1992). The potential gains of reuse were first voiced at a NATO software engineering conference in 1968 as a means of curbing the unsustainable trend of creating increasingly larger systems in this way (Nauer and Randell, 1968).
Furthermore, software solutions for a specific domain contain many valuable business rules that an organisation will find difficult to reimplement. Over time, these rules become embedded in a system. Therefore they are no longer explicit to developers and maintainers, making it difficult to reuse these valuable assets in other systems within an organisation (Verhoef, 2000).
Reports of pragmatic software reuse have been partially realised. During the mid 1980’s the reuse of up to 40% of software within Japanese organisations has been reported (Mii and Takeshita, 1993). Software process models, once optimally applied within an organisation, have also prompted increased amounts of reuse during software development (Institute, 1997; Richardson, 1999). However, reuse in this way is entirely dependant upon the institutionalised cultural norms within the organisation’s development teams rather than a prescribed technological approach, such as object orientation or structured programming. However, such a high cultural standard is notoriously difficult to achieve (Richardson, 1999).
Other attempts at enabling future reuse on a larger scale have included approaches to software development such as object-orientation, or the availability of reuse libraries (see section 3.3) for common tasks such as string manipulation or lists. Neither of these, however, provide the needed panacea for software development that is sought. Object orientation has proved to be too fine grained for large scale reuse, while library reuse is often too generic to have a major impact on domain specific software solutions produced within many organisations (Greenfield et al., 2004).
Component-based development refers to the assembly of software from pre-packaged components (Cheesman and Daniels, 2001), and builds upon earlier development approaches, such as object-oriented programming, procedural programming, fourth generation languages and aspect-oriented software development. Component-based development presents itself as a possible solution that can introduce reuse and replaceability to software development practice on a large scale. Components will often encapsulate much larger bodies of code than their object-oriented predecessors and lead to more easily understood software solutions (Zweben et al., 1995). This approach to software development promises many benefits. Most notably, with respect to this thesis, this development approach accommodates the reuse and replacibility of existing software during development and evolution at an encapsulated level of interaction (Parnas, 2002, 1971, 1972). For example, an organisation’s business rules, that may be realised within a component of one of their systems, may be reused by deploying it to augment the functionality of another system. Conversely, if that business rule changes, a new component implementing the new business rule could quickly replace the existing one.
The vision of large-scale reuse and replaceability using a modern development approach, such as component-based development, would seem to afford significant benefits in alleviating the problems of hiding complexity and facilitating software reuse. However, the vast majority of existing software was developed in accordance with older, different software development paradigms such as structured programming or object-orientation (Kontogiannis et al., 1996; Johnson, 2002). These systems lessen the potential for reuse.
This thesis addresses the need to reuse portions of existing non-component-based software when implementing and evolving new or existing component-based systems within a domain vertical.
Reengineering and maintenance research provides a plethora of techniques for analysing and altering existing systems. Attempts at recovering modules for reuse have existed since the early 1980’s (Belady and Evangelisti, 1982; Hutchens and Basili, 1985; Livadas and Johnson,1994), with the most comprehensive review on the subject to date found in (Koschke, 2000a). Automatic approaches, in isolation, have shown poor rates of success when recovering components (Koschke, 2000a). Hence, Koschke (Koschke, 1999) states that the best approach when attempting component recovery should:
Aggregate several techniques: Research has shown that any single automated component recovery technique has a success rate no greater than 40%. To increase accuracy to acceptable levels, two or more techniques should be used to increase accuracy to acceptable levels.
Include the human in the recovery process: Human inference on data often provides insight that cannot be achieved algorithmically. Thus, semi-automating the recovery or encapsulation process can be greatly assisted using human insight.
Include domain knowledge: Domain knowledge can attribute semantics to the syntax of the program under analysis. Without meaningful semantics attached to the code under analysis, the identified component is often less useful. For example, semantic information such as ‘what is the purpose of the component identified?’is vital domain knowledge that can be provided by a software engineer during recovery.
This thesis is cognizant of these requirements when exploring existing reengineering and
maintenance research to arrive at a proposed solution to the legacy dilemma stated in section 1.4.
In approaching component recovery, two distinct steps can be identified:
Encapsulating reusable code.
Wrapping the reusable code to conform with a component-based development process.
If step one is adequately performed then step two becomes trivial, thus the main focus of this thesis lies with the first step, with step two given a lighter treatment (Le Gear et al., 2004). Given this focus, the objectives of this thesis can be outlined as follows:
To produce a repeatable process for targeted component encapsulation, that is driven by the software engineer, that makes use of domain knowledge, is human-oriented and aggregates two or more appropriate techniques, based on a comprehensive literature of the field.
To evaluate this process and its products in ecologically valid settings.
The key contributions of this thesis include:
Exploiting a previously unexplored variation on Software Reconnaissance that can be used to identify reuse in software systems. The view produced is called the reuse perspective.
Creating a tailored version of Reflexion Modelling designed specifically for component interface identification and component encapsulation.
The novel combination of the reuse perspective and the variation on Reflexion Modelling as a process for component recovery. This combination forms a component encapsulation process called Reconn-exion.
The positioning of Reconn-exion within existing literature.
An empirical evaluation of Reconn-exion acquired from realistic industrial settings that evaluates the validity of Reconn-exion with respect to the process and the product and also this evaluation suggests some future refinements to the process.
A repeatable process for component recovery.
The remainder of this thesis is structured as follows:
Chapters 2, 3, 4 and 5 forms a literature review relevant to Component Reconn-exion. The broad areas of software components and software reengineering are first discussed, followed by a more detailed look at two software analysis techniques -Software Reconnaissance and Software Reflexion Modelling.
Chapter 6 explores research methods and in particular describes the research approach that will be adopted in this thesis.
Chapters 8 and 9 follow with an evaluation of Component Reconn-exion. First, the two constituent parts of Reconn-exion, which are core contributions in themselves, are evaluated in industrial, case studies. Then a large industrial case study is undertaken to evaluate the complete Reconn-exion process.
Chapter 10 reflects on the previous three chapters providing a critical evaluation in terms of validity of the studies undertaken and the theoretical limitations of the technique.
Chapter 11 suggests potential future work that could be undertaken to refine Reconn-exion and evaluate results to date, as well as suggesting potential expansions to Reconn-exion.
Finally in chapter 12 a conclusion to the thesis is provided.
[Back to Home Page] [Next Chapter]
Component Reconn-exion