7.1
Introduction
The aim of this thesis was ‘to develop, model, demonstrate and evaluate an aspect-oriented interdisciplinary approach to engineering that can be used to build and operate systems required to understand and improve Problem Situations of all
kinds’. This aim has been achieved through the development and demonstration of
Aspect-Oriented Thinking.
In this chapter, I summarise the contribution made by this thesis including key elements of Aspect-Oriented Thinking, results of theProof-of-Concept reported in Chapter 6, and current limitations of the approach. I then draw final conclusions and make recommendations regarding future research and development of the approach.
7.2
Summary of contribution
In Chapter 2, I argued that the success of software engineering and engineering in general can only be understood by considering all of the stakeholders involved, their separate needs and how they evolve with time. This view stands in contrast to common definitions of project success that centre around the satisfaction of budgetary and schedule constraints. It is also a view that led to the development of
Capability Dynamics (Section 2.5), Aspect-Oriented Systems Engineering(Section
2.7) and ultimately the idea ofAspect-Oriented Thinking.
In Chapter 3, I proposed a plan for Aspect-Oriented Thinking research and development. This was achieved by first developing and using a novel conceptual model of software engineering research to describe and compare various research approaches described in the software engineering literature. The model was then used to help describe the Aspect-Oriented Thinkingresearch approach adopted in this thesis. The approach comprises two phases. The first has been completed and its results have been reported in this thesis. The second phase constitutes future research including industrial evaluation and development of Aspect-Oriented
Thinkingas discussed in Section 7.5 below.
In Chapter 4, I described the language of Aspect-Oriented Thinking using a UML class model. The key concepts involved are:
• Problem Situations.A problem situation can be defined as an environment of interacting systems in which at least one person perceives a need for change. In Chapter 4, I recast Software and systems engineering as a process
7.2 Summary of contribution
of bringing about changes which improve Problem Situations rather than simply satisfying a set of stated requirements and constraints.
• Systems. Systems are either human, man-made or natural. Man-made systems are created, modified, operated and retired in order to learn about
Problem Situations and to realise changes that aim to improve Problem
Situations.
• Domains.Problem Situationsare considered as a set of autonomous subject matters calledDomains. EachDomainrepresents a separate view or perspec- tive of a Problem Situation or the Systems involved. Examples within the context of software-intensive systems development include human-machine interfaces, security, safety, architecture, functional requirements, manage- ment and quality assurance. Within a broader context of the environment, for example, domains might include various aspects of climate, pollution, economics, biology and social science.
• Domain Models. Domain Modelsare formed, using appropriate languages, to develop and capture knowledge aboutDomains. These models can be used to learn about a subject matter of concern within aProblem Situation or in the implementation of changes usingAspect-Oriented Specifications, Aspect-
Oriented Specification ArchetypesandImplementation Models.
• Aspect-Oriented Specifications. Aspect-Oriented Specifications are formed to specify systems. These systems include those required to learn about and improve a Problem Situation, as well as those required to create, modify, operate and retire other systems.
Each Aspect-Oriented Specification comprises a set of Specification Domain
Modelsand a set ofRequirements. Specification Domain Modelscapture in-
formation such as interface specifications, security policies and performance constraints for a required system.
Requirements make use of subject-matter captured in Knowledgeand Spec-
ification Domain Models to specify some property of a required System.
They are formed in accordance with Requirement Archetypes defined in an
Aspect-Oriented Specification Archetype.
• Aspect-Oriented Specification Archetypes. An Aspect-Oriented Speci-
fication Archetype comprises an integrated set of Requirement Archetypes.
These archetypes describe the way in which subject matter captured in a set of autonomous Knowledge Domain Models can be used to form an
Aspect-Oriented Specification which fully specifies the functional, perfor-
mance, architectural, implementation and other requirements for a required
System.
Because they cover all aspects of a System, including architectural and implementation concerns, each Aspect-Oriented Specification Archetype can be reused in the formation ofAspect-Oriented Specificationsfor many systems that share the same architecture.
• Implementation Models. A givenAspect-Oriented Specification Archetype
will be associated with one or more Implementation Models. These models comprise a set of Implementation Rules that can be followed by people or automated tools to implement any Aspect-Oriented Specification formed in accordance with the givenAspect-Oriented Specification Archetype.
In Chapter 5, I described a continuous process that makes use of the above concepts to learn about and improveProblem Situations. In Chapter 6, along with associated Appendices B to G, I demonstrated the use of this process to develop a complete software application using theAspect-Oriented Thinkingapproach.
7.3
Limitations of contribution
Limitations of the contribution made by the research presented in this thesis, relate mainly to the Proof-of-Conceptpresented in Chapter 6. While the Proof-of-
Conceptdemonstrates the mechanics ofAspect-Oriented Thinkingand the viability
of the approach for developing software systems, it has the following limitations:
• TheProof-of-Conceptinvolved the development of a functionally simple, small
and well defined software application within a controlled environment. An appropriate evaluation of Aspect-Oriented Thinkingwill need to involve the development of a large software-intensive system within a real worldProblem
Situationof co-evolving man-made, natural and social systems.
• The results produced so far provide limited evidence that theAspect-Oriented
Thinking approach can lead to improved productivity along with reduced
defect rates and rework. However, results reported byStien[2003, 2006] and
Boughton [2006] in relation to the application of X
TUML, indicate that such improvements are possible within an industrial context.
• The results do not demonstrate reuse of Domain Models, Aspect-Oriented
Specification ArchetypesandImplementation Models. For example, it should
be possible to reuse many of the Domain Models described in Chapter 6 to form Product Management System Aspect-Oriented Specifications in accordance with archetypes other than the LAMP archetype presented in Appendix C. These other archetypes could, for example, make use of
7.4 Overall conclusion
architectural domains such as the Java Platform, Enterprise Edition [Sun
Microsystems, 2006a] or Asynchronous JavaScript and XML (AJAX)[Garrett,
2006].
Similarly, it should be possible to reuse theLAMP Aspect-Oriented Specifica-
tion Archetypeto form Aspect-Oriented Specificationsfor systems other than
theProduct Management System.
• The detail involved in the Proof-of-Concept presented in Chapter 6 and Appendices B to G highlights some of the tediousness of applying the
Aspect-Oriented Thinking approach without software tool support. In any
real-world context, it will be necessary to make use of tools that support the development of Aspect-Oriented Thinking artifacts and to manage the
Aspect-Oriented Thinkingprocess.
More generally, theProof-of-Concept described in Chapter 6 does not demon- strate applicability ofAspect-Oriented ThinkinginProblem Situationsthat require the expertise of a broad range of disciplines to build systems other than software. For example, Problem Situations involving the environment, will require the expertise of many disciplines including engineering, chemistry, biology, economics, the law and social science to understand, build, modify, operate and/or retire a broad range of man-made and natural systems.
A summary of plans for future work to address the above limitations is presented in Section 7.5.
7.4
Overall conclusion
The overall conclusion that can be drawn from the research presented in this thesis is that Aspect-Oriented software development techniques can be combined with
Systems Thinking ideas to form a novel approach that has the potential to help
people from multiple disciplines work together to learn about and improve a broad range ofProblem Situations.
It is the form of Aspect-Oriented Specifications and the way in which they are developed that differentiates Aspect-Oriented Thinking from other interdisci- plinary approaches to Problem Situation improvement. While other approaches such asSystem DynamicsandSoft Systems Methodologycan be used to learn about
aProblem Situation, they rely on the use of a single approach across all aspects of
aProblem Situationand offer little in the way of an approach that can be used to
act on any decisions made.
Aspect-Oriented Thinking, on the other hand, provides a framework within which these and other existing approaches to the development of knowledge and expertise, can be used to specify, build and operate the systems necessary to learn about and improve entireProblem Situations.
BecauseAspect-Oriented Thinkingis based on the notion of initially separating each aspect of a Problem Situation into autonomous and often discipline based domains, it might provide a way to ‘Bridging the disciplinary divides’ [Grafton
et al., 2005].
7.5
Recommendations for future work
This thesis contains the results of research conducted inPhase Oneof the research approach presented in Chapter 3. That is, this thesis contains the theoretical foundations of Aspect-Oriented Thinking and a demonstration of its potential value. The aim of Phase Two of the research approach is to the continue the development ofAspect-Oriented Thinkingand to support its adoption by industry.
In this section, I outline a series of specific activities for future research and development of Aspect-Oriented Thinking that might be undertaken within the framework established in Chapter 3 (see Figure 3.6 on page 45). The aim of these activities is to address the limitations identified in Section 7.3.
7.5.1 Bootstrapping the approach
Because Aspect-Oriented Thinking is a general approach to improving Problem
Situations, it should be possible to improve Aspect-Oriented Thinkingitself using
the approach. This could be achieved by developing a set of Knowledge Domain
Modelsbased on aspects of the conceptual and process models presented Chapters
4 and 5. Various Aspect-Oriented Specification Archetypescould then be formed to enable users to specify and implement various systems to support the development, practice and evaluation ofAspect-Oriented Thinking.
Within this context, this thesis can be viewed as part of a bootstrapping
process that aims to establish a situation in which futureAspect-Oriented Thinking
research, development and evaluation is conducted using the Aspect-Oriented
7.5 Recommendations for future work
7.5.2 Tool support
Software tools will need to be developed to support the application of Aspect-
Oriented Thinking. At this early stage, three phases of development are envisaged.
The first phase will aim to develop a database system to store artifacts produced during the process of Aspect-Oriented Thinking. This phase could be developed using theLAMP Aspect-Oriented Specification Archetypepresented in Appendix C and application specificDomain Modelsincluding one based on theAspect-Oriented
Thinking Conceptual Modelpresented in Chapter 4.
In phase two, a set of graphical model editors will be incorporated for important modelling languages including eXecutable and Translatable UML (X
TUML) and
System Dynamics.
Phase three will aim to provide a framework that can be used to automate the execution of Implementation Models. This framework will, itself, be a collection
ofAspect-Oriented Thinking artifacts including a set of Domain Models that deal
with repository navigation, code generation and reporting. An Aspect-Oriented
Specification Archetype will be developed to describe how these models can be
assembled to form Aspect-Oriented Specifications for applications that automate the execution ofImplementation Models.
7.5.3 Additional software system examples
In order to demonstrate the reusable nature of Knowledge Domain Models and
Aspect-Oriented Specification Archetypes, it will be necessary to develop a second
Proof-of-Concept. This secondProof-of-Conceptwill comprise a set of newApplica-
tion Domain Modelsand a newAspect-Oriented Specificationformed in accordance
with the existing LAMP Aspect-Oriented Specification Archetype presented in Appendix C. The new specification will be implemented using the existingLAMP
Implementation Modelpresented in Appendix E.
In addition to the above, a new set of architectural and implementation
Domain Models, along with a new Aspect-Oriented Specification Archetype and
Implementation Model, will be developed to capture knowledge required to build
applications using the armidale architecture presented in Flint and Boughton
[2002, Reproduced in Appendix I ]. These artifacts will be used to form a
newAspect-Oriented Specificationfor implementation of theProduct Management
Systemusing the new architecture. This will demonstrate the reuse ofApplication
Domain Modelswith different architectures.
7.5.4 Industrial-scale evaluation
The initial plan for future evaluation of Aspect-Oriented Thinking involved the development of a software system within an industrial context (Section 3.3.2.2). During the later stages of the research reported in this thesis I concluded that this might not be possible given the novel nature of the approach. It would be difficult to convince potential industry collaborators to participate in a live evaluation of
Aspect-Oriented Thinkingon anything other than a small, non-critical project.
Recent discussions with colleagues have suggested the possibility of demon- strating and evaluating Aspect-Oriented Thinkingby using the approach to rede- velop a large-scale real-world government information system within a research context.
The proposal is to gain sponsorship from an organisation to form a devel- opment team to undertake the re-development of an existing project within a research context using leading-edge research ideas, including Aspect-Oriented
Thinking. The team is likely to be significantly smaller than the commercial
equivalent and would comprise researchers with significant industrial experience and understanding of Aspect-Oriented Thinking, post-graduate students, other researchers and representatives from the sponsoring organisation (possibly as full-time post-graduate research students). The team would need to have access to documentation including plans, specifications and studies related to the real project, as well as the real-world users, sponsors and other stakeholders.
The aim of such a project would be to answer the following questions by comparing, where appropriate, results of the research based project with those of the corresponding commercial project.
• CanAspect-Oriented Thinkinghelp people manage complexity?
• Can the benefits reported by Stien [2003, 2006] and Boughton [2006] in relation to the application of X
T UML, be realised with respect to the use of
Aspect-Oriented Thinking within the broader context of a large software-
intensive system development project?
• Can Aspect-Oriented Thinking help people from multiple disciplines work
together?
• Can Aspect-Oriented Thinking lead to the development and use of system
capabilities that are better aligned with stakeholder needs?
• CanAspect-Oriented Thinkingimprove an organisation’s ability to respond to
7.6 Closing remarks
• Can effective tool support, including automated implementation of Aspect-
Oriented Specifications, be developed and used? Techniques such as the
Technology Acceptance Model[Davis, 1989] could be used to help answer this
question.
Note that an industrial-scale project, such as that described above, will also facilitate the conduct of other research related to the development of large software-intensive systems. This research could include that related to project management, process improvement, measurement, architecture, human-computer interfaces, data mining and high-performance computing. It will also provide an important case study for teaching and small group projects within a university context.
7.5.5 Research in a interdisciplinary context
By including people from non-computing disciplines within the above project team, it will be possible to evaluate the effectiveness of Aspect-Oriented Thinkingas an interdisciplinary approach to understanding and improving Problem Situations. Other disciplines that might be involved include sociology, psychology, teaching, economics, accounting, the law and philosophy.
7.6
Closing remarks
With further research and development I believe that Aspect-Oriented Thinking
will prove itself to be of broad applicability and a viable interdisciplinary approach to learning about, and improving complexProblem Situationsof all kinds.
It is my intention to continue with this work for as long as I am able and so long as the approach, and any derivatives from it, remain relevent.
The End
Part
IV
Appendix
A
Aspect-Oriented Specification
notation
Contents A.1 Introduction . . . 114 A.2 Domain model notation . . . 114 A.3 Individual requirement notation . . . 114 A.4 Requirement set notation . . . 114 A.5 Domain model set notation . . . 116 A.6 Conclusion . . . 117A.1
Introduction
Within this appendix, I describe a notation that can be used to simplify the representation of Aspect-Oriented Specifications. The notation has been derived from elements of the HiGraph notation [Harel, 1988] and the Unified Modelling
Language (UML)[Object Management Group, 2005].