Component Reconn-exion
A Ph.D. Thesis by Andrew Le Gear, University of Limerick, 2006 [About the Author]
A PDF Version of this thesis is available to download here [component-reconn-exion.pdf]
Submitted in partial satisfaction of the requirements for the degree of
Doctor of Philosophy
in
Computer Science
at the
University of Limerick, Ireland
Supervised by Dr. Jim Buckley
Examined by Prof. Tony Cahill and Prof. Gail Murphy
9th November 2006
“There is no such thing as a long piece of work, except one that you dare
not start.”
-Charles Baudelaire.
For over thirty years, increased software reuse and replaceability have been touted as a means of easier software development. Unfortunately this is a non-trivial task. Component-based development attempts to ease the creation of replaceable and reusable software. However, the majority of legacy systems are not implemented using the component-based development paradigm. To enable the reuse of portions of legacy software as part of a component-based development process, a component recovery technique must first be employed.
The two phases to component recovery are (1) encapsulation of a candidate component, followed by (2) the application of a component wrapper to allow the component to be used with component-based technologies. This thesis focuses on the first phase, proposing and evaluating a human-driven process for targeted component encapsulation using a combination of two existing techniques: A dynamic software understanding technique called Software Reconnaissance and a design recovery technique called Reflexion Modelling. Specifically, reuse of core assets in a system is identified using a variation of the Software Reconnaissance technique called the reuse perspective. The set of reuse elements in the reuse perspective, is subsequently investigated and partitioned into cohesive units of functionality using an adapted version of the Reflexion Modelling technique.
The potential usefulness of this process is demonstrated and evaluated using two large scale, industrial case studies. The results of the studies, for the most part, would seem to indicate that the process is worthwhile and affords significant time saving opportunities for software engineers.
I Literature Review
1.1 SoftwareMaintenanceandDevelopment
1.3 Reusable and Replaceable Software Through Component-based Development
1.4 ProblemStatement:TheLegacyDilemma
1.5 ReengineeringTowardsComponents
1.6 ObjectivesandContributions
2.3 Introducing Component-Based Development
2.3.1 A Component-Based Development Process
2.4 The Legacy Dilemma Revisited
2.5.1 A Brief History of Encapsulation in Software Development
2.5.1.3 Object Oriented Programming
2.5.3 Encapsulation Features of Component-Based Development
3.1 Agendas for Reengineering Software Systems
3.2 Dynamic versus Static Analysis
3.3 Reuse Identification Techniques
3.3.3 Frequency Spectrum Analysis
3.5 Reengineering Towards Components
3.5.2 Clustering for Architectural Recovery and Component Recovery
3.5.2.1 Dataflow-based Approaches
3.5.2.2 Structure-Based Approaches
3.5.2.3 Domain-Model Based Approaches
3.5.3 Aggregated Recovery Approaches
3.5.4 Componentisation Processes
4.1 A Functionality View of Software
4.1.1 Common Software Elements
4.1.2 Potentially Involved Software Elements
4.1.3 Indispensably Involved Software Elements
4.1.4 Uniquely Involved Software Elements
4.2.1 Software Instrumentation Enabling Software Reconnaissance
4.2.2 Best Practices When Applying Software Reconnaissance
4.2.3 Previous Work Using Software Reconnaissance
5 Software Reflexion Modelling
5.1 TheReflexionModellingProcess
5.2.1 Early Experiences with Reflexion Modelling
5.2.2 Extensions and Further Uses of Reflexion Modelling
5.2.3 A Cognitive Basis for Reflexion Modelling
6.3 Quantitative and Qualitative Research Methods
6.4 The Culture of Research Evaluation in Computer Science
6.4.1 Arguing for Hybrid Approaches to Research in Computer Science
6.5 A Research Model for This Thesis
6.5.1 Empirical Techniques Employed
II “Component Reconn-exion”: Reengineering Towards Components Using Variations on Reconnaissance and Reflexion
7.1 A Conjecture for Prompting Component Abstractions
7.1.1 A New Reuse Perspective Derived from Software Reconnaissance
7.2 A Hypothesis for Encapsulating Components Using Reflexion Modelling
7.3 Hypothesising a Process For Component Encapsulation
7.4.2 Part1:A Reuse Perspective
7.4.3 Part 2: Encapsulating with Reflexion
8 Evaluating the Basis Techniques of Reconn-exion
8.1 Validating the Reuse Perspective: The JIT/S Shipping Case Study
8.1.1 Purposeand Research Questions
8.1.2 The Subject System: JIT/S
8.2 Validating Reflexion-Based Component Encapsulation: The Workspace CaseStudy
8.2.1 PurposeandResearchQuestions
8.2.2 The Subject System: The Learning Management System
9 Evaluating Reconn-exion: The AIM Case Study
9.1 PurposeandResearchQuestions
9.2 The Subject System: The Advanced Inventory Management Application
9.6.1.1 Creating the reuse perspective
9.6.1.2 Using the reuse perspective to prompt component abstractions
9.6.1.3 Encapsulation with Reflexion
9.6.1.4 Identifying Multiple Interfaces
9.6.2.1 Creating the reuse perspective
9.6.2.2 Using the reuse perspective to prompt component abstractions
9.6.2.3 Encapsulation with Reflexion
9.6.2.4 Identifying Multiple Interfaces
9.7.1 Process: The Effectiveness of Reuse Perspective as a Prompt
9.7.2 Process: Reconn-exion for Component Encapsulation
9.7.3 Product: An Architect’s Assessment of Encapsulated Components
9.7.4 Product: Metrics of Coupling and Cohesion on Encapsulated Components
10.2 Theoretical Limitations of Reconn-exion
11.2 Exploring Database Accesses
11.4 Combining with Automated Techniques
11.5 Feature-based Decomposition of Software
11.6 Software Product Line Recovery
11.8 Inverse Structural Summarization
11.9 Collaborative Design Recovery
III Bibliography
IV Appendices
A.1 Scrabble Emulator Reuse Perspective
G Interfaces on the House Application
2.1 Levels of interface specification adapted from Beugnard et. al. (Beugnardetal., 1999)
2.2 A Generic Component Architecture adapted from Bachmann et al. (Bachmannetal., 2000).
2.3 The component based development process adapted from (Cheesman andDaniels,2001).
2.4 A detailed description of the provisioning workflow.
2.5 A code fragment from a C program.
2.6 A visualisation of the encapsulation exercise shown in figure 2.7.
2.7 A revised version of the code fragment in figure 2.5.
2.8 An inheritance hierarchy code sample.
2.9 A visualisation of the inheritance hierarchy in 2.8.
2.10 Using polymorphism for encapsulation code example.
2.11 An example of a loosely coupled and highly cohesive component.
2.12 Many classes without and encapsulation policy.
2.13 Many classes from figure 2.12 encapsulated by a component.
2.14 Event handling code sample.
2.15 A deployment diagram of two distributed components.
2.16 A call between the distributed components shown in 2.15.
3.1 Code example1.
3.2 A possible graph representation of code example 1 in figure 3.1.
3.3 Code example2.
3.4 A possible graph representation of code example 2 in figure 3.3.
3.5 Code example3.
3.6 A possible graph representation of code example 3 in figure 3.5.
3.7 Code example 4.
3.8 A possible graph representation of code example 4 in figure 3.7.
4.1 Identifying Features from Running Systems.
4.2 Common Software Elements.
4.3 Potentially Involved Software Elements, shaded in black.
4.4 Indispensably Involved Software Elements, are shaded in black.
4.5 Uniquely involved software elements, are shaded in black. .
5.1 Collapsing strategy in operation.
5.2 The Software Reflexion Modelling Process .
5.3 Adaptedfrom(BraceandRoth,2005).
7.1 The three sets used to form the shared set.
7.2 Encapsulating a component and making its interface explicit.
7.3 Identifying multiple interfaces on a component using Reflexion Modelling.
7.4 The Component Reconn-exion process.
7.5 A screenshot of the house application.
7.6 First house application Reflexion model.
7.7 First house application Reflexion model map.
7.8 Second house application Reflexion model.
7.9 Second house application reflexion model map.
7.10 Third house application reflexion model.
7.11 Third house application reflexion model map.
8.1 A screenshot of the jRMTool eclipse plug-in.
8.2 First iteration by the first participant.
8.3 Last iteration by the first participant.
8.4 Web administration user interface component. (Note the bolded black box is not part of the tool’s visual output.)
8.5 A design pattern in the LMS.
9.1 Procedure clusters prompted by the reuse perspective (participant 1). File names are blurred for copyright reasons.
9.2 Participant one’s first Reflexion model and map.
9.3 Participantone’sfinalReflexionmodel.
9.4 Procedure clusters prompted by the reuse perspective (participant 2). Note that the file names are blurred for copyright reasons.
9.5 Participant two’s third Reflexion model.
9.6 Participant two’s final Reflexion model.
11.1 Decomposing a system in terms of its SHARED sets.
11.2 Including the common software elements in the model of the system.
11.3 A feature based decomposition of a software systems that shows shared, unique and common software elements of a system.
11.4 A simple temporal source model.
11.5 An example of temporal summarization.
12.1 The Component Reconn-exion process
B.1 Pilot Study -Scrabble Emulator -Reflexion model and map 1.
B.2 Pilot Study -Scrabble Emulator -Reflexion model and map 2.
B.3 Pilot Study -Scrabble Emulator -Reflexion model and map 3.
B.4 Pilot Study -Scrabble Emulator -Reflexion model and map 4.
C.1 Case Study -Workplace -Participant 1 -Reflexion Model and map 1 .
C.2 Case Study -Workplace -Participant 1 -Reflexion model and map 2 .
C.3 Case Study -Workplace -Participant 1 -Reflexion model and map 3 .
C.4 Case Study -Workplace -Participant 1 -Reflexion model and map 4 .
C.5 Case Study -Workplace -Participant 1 -Reflexion model and map 5 .
C.6 Case Study -Workplace -Participant 1 -Reflexion model 6 .
C.7 Case Study -Workplace -Participant 1 -Reflexion model and map 7 .
C.8 Case Study -Workplace -Participant 1 -Reflexion model and map 8 .
D.1 Case Study -Workplace -Participant 2 -Reflexion model and map 1 .
D.2 Case Study -Workplace -Participant 2 -Reflexion model and map 2 .
D.3 Case Study -Workplace -Participant 2 -Reflexion model and map 3 .
D.4 Case Study -Workplace -Participant 2 -Reflexion model and map 4 .
D.5 Case Study -Workplace -Participant 2 -Reflexion model and map 5 .
D.6 Case Study -Workplace -Participant 2 -Reflexion model and map 6 .
D.7 Case Study -Workplace -Participant 2 -Reflexion model and map 7 .
D.8 Case Study -Workplace -Participant 2 -Reflexion model and map 8 .
D.9 Case Study -Workplace -Participant 2 -Reflexion model and map 9 .
D.10 Case Study -Workplace -Participant 2 -Reflexion model 10 .
D.11 Case Study -Workplace -Participant 2 -Reflexion model and map 11 .
E.1 Case Study -AIM -Participant 1 -Reflexion Model and map 1 .
E.2 Case Study -AIM -Participant 1 -Reflexion Model and map 2 .
E.3 Case Study -AIM -Participant 1 -Reflexion Model and map 3 .
E.4 Case Study -AIM -Participant 1 -Reflexion Model and map 4 .
E.5 Case Study -AIM -Participant 1 -Reflexion Model and map 5 .
E.6 Case Study -AIM -Participant 1 -Reflexion Model and map 6 .
E.7 Case Study -AIM -Participant 1 -Reflexion Model and map 7 .
E.8 Case Study -AIM -Participant 1 -Reflexion Model and map 8 .
E.9 Case Study -AIM -Participant 1 -Reflexion Model and map 9 .
E.10 Case Study -AIM -Participant 1 -Reflexion Model and map 10 .
F.1 Case Study -AIM -Participant 2 -Reflexion Model 1 .
F.2 Case Study -AIM -Participant 2 -Reflexion Model 2 .
F.3 Case Study -AIM -Participant 2 -Reflexion Model 3 .
F.4 Case Study -AIM -Participant 2 -Reflexion Model 4 .
F.5 Case Study -AIM -Participant 2 -Reflexion Model 5 .
F.6 Case Study -AIM -Participant 2 -Reflexion Model 8 .
F.7 Case Study -AIM -Participant 2 -Reflexion Model 9 .
G.1 “Transforms” component’s interface on “Main.” Provides interface.
G.2 “Transforms” component’s interface on “GUI.” Provides interface.
2.1 Motivations for software components described by four tiers.
2.2 Levels of maturity among CBD Technologies.
7.1 Features identified for the house application.
8.1 JIT/SSummary.
8.2 Particulars of the participants of the JIT/S study.
8.3 FeaturesidentifiedinJIT/S.
8.4 Summaryofreuseperspective.
8.5 Workplace case study participant details.
9.1 Participantdetails.
9.2 Feature set examined by participant 1 during case study.
9.3 The set of features chosen by the second participant.