5.7 Aspect-Oriented Specification implementation . . . 80 5.8 Continuous learning and improvement . . . 80 5.9 Comparison with traditional life-cycle models . . . 81 5.10 Documentation . . . 83 5.11 Conclusion . . . 84
5.1
Introduction
In order to make use of the Aspect-Oriented Thinking concepts presented in Chapter 4, it is necessary to develop, apply and continuously improve a well defined process. Archetype Specification Aspect−Oriented Development Aspect−Oriented Specification Archetype <<datastore>> Model Implementation <<datastore>> Modelling Implementation Analysis Problem Situation Aspect−Oriented Specification Development Specification Aspect−Oriented <<datastore>> Aspect−Oriented Specification Implementation Models Knowledge Domain <<datastore>> Knowledge Domain Identification and Analyse Decision Making Decision Implementation Learning Interdisciplinary Disciplinary
Figure 5.1: An activity diagram depicting the process ofAspect-Oriented Thinking. In this chapter, I describe the process of Aspect-Oriented Thinking with the aid of the UML activity diagram shown in Figure 5.1. This diagram depicts the activities involved in Aspect-Oriented Thinking, the order in which they
5.2 Problem situation analysis
are conducted, and the data items they consume and produce. The activity diagram also makes use of vertical partitions to identify those activities conducted within the context of a single discipline and those that are conducted within a interdisciplinary context. More importantly, horizontal partitions are used to identify those activities which are involved in learning about aProblem Situation, making decisions that aim to improve aProblem Situation and those involved in implementing such decisions.
5.2
Problem situation analysis
The Aspect-Oriented Thinking process begins with Problem Situation Analysis.
The aim of this activity is to fully understand a Problem Situation and to make decisions regarding the creation, modification, operation and/or retirement of
Systemsto improve it.
Problem Situations can be explored using existing approaches such as Soft
Systems Methodology [Checkland, 1981; Checkland and Scholes, 1999], System
Dynamics [Forrester, 1961] or Capability Dynamics [Flint, 2001] (Section 2.5).
Simulations and other tools used to support these approaches can be constructed using theAspect-Oriented Thinkingapproach itself. For example, aDomain Model
developed usingCapability Dynamics could be used to describe the effectiveness of interactions between the systems involved in a Problem Situation. This
Domain Model could then be woven together withDomain Models that deal with
agent-based simulation technology to form anAspect-Oriented Specification for a
Capability Dynamicssimulation. This specification could then be implemented to
form a simulation that can be used to learn about a Problem Situation, identify system interactions that need to be improved and to evaluate the impact of various options to bring about such improvements.
Domain Models developed using System Dynamics could be combined with
Domain Modelsthat represent off-the-shelf simulation tools such asiThink[ISEE
Systems, 2006] to form Aspect-Oriented Specifications for simulations that can
be used to identify and understand required improvements. In this case, the
Implementation Model associated with the Aspect-Oriented Specification would
comprise a set of instructions that humans could follow to use iThink. In fact,
theImplementation Modelmay simply refer to existingiThinkdocumentation1.
1This example highlights the very general applicability of theAspect-Oriented Thinkingapproach.
In this simple case the approach aligns with existing practices for using established modelling languages and off-the-shelf tools. As the approach is used for larger and more complex systems, the number ofDomain Modelsinvolved will increase and theImplementation Modelwill most probably become more sophisticated and possibly automated.
More complex Aspect-Oriented Specifications could also be formed by inte- grating simulations of several separate domains. Environmental simulations dealing with separate concerns such as climate, epidemiology and population could be integrated using Aspect-Oriented Thinking to produce a single, possibly distributed, simulation (anaspect-oriented simulation!).
5.3
Knowledge domain identification and analysis
The purpose of this activity is to develop and verify Knowledge Domain Models
(Section 4.4.2) that each deal with a specific aspect of a Problem Situation.
Knowledge Domain Modelsare used to improve understanding of a specific subject
matter and to help promote consensus and communication amongst the various relevent stakeholders, while avoiding confusion with unrelated concerns such as volatile technology.
TheKnowledge Domain Identification and Analysisactivity comprises the sub-
activities described in the remainder of this section. These activities will normally be conducted by people with relevent, often discipline based, domain knowledge.
5.3.1 Domain identification
The aim of this sub-activity is to identify the separate concerns, or subject matters, involved in a Problem Situation. In many cases, Domains can be identified by considering the various disciplines required to fully understand a
Problem Situation. For example, Domains that deal with the environment, civil
engineering, organisational structure, politics, medicine, sociology and the law might be identified when dealing with water shortages and the possibility of constructing new dams or recycling waste water.
Domains might also align with life-cycle activities such as requirements,
architecture and implementation, or with concerns that cut-across a number of other domains, such as project, risk and configuration management, security, testing and maintenance.
That is, Domains are used to separate the concerns involved in a Problem
Situationin multiple dimensions.
Note that the development of preliminary Aspect-Oriented Specifications is also often helpful when identifying domains. They help Aspect-Oriented thinkers understand how the subject matter of each domain might be used.
5.3 Knowledge domain identification and analysis
5.3.2 Language modelling
Most Aspect-Oriented Thinking Domain Models are developed using a language
defined in a modelling Language Domain Model (a Meta-model). For example,
Domain Modelsdeveloped usingX
TUML are instances of a separateDomain Model which describes theX
TUML language.
The purpose of theLanguage modellingsub-activity is to develop models of the languages used to formAspect-Oriented Thinking Domain Models. This is typically a once-off activity conducted whenever a modelling language, for which there is no existing meta-model, is required.
Note, however, that it may not necessary to have a complete and formal meta-model for every Domain Model. All that is required is that every Domain
Model Elementreferenced by aRequirement Archetype or Requirement, be clearly
identifiable. Indeed, the only formal meaning of such elements that is of interest, is that provided byImplementationRules(Section 4.8.1).
5.3.3 Domain modelling
The aim of this sub-activity is to develop models ofDomainsinvolved in aProblem
Situation. The purpose of modellingDomainsis to develop a clear understanding of
(potentially) complete subject matters in isolation of other subject matters. These models can then be used to communicate concepts within a team or organisation and, more importantly, across traditional interdisciplinary boundaries. Ultimately, they are used in the formation ofAspect-Oriented Specifications.
Domain Modelsare usually developed by domain experts using domain specific
languages and techniques. Significantly, no expertise inAspect-Oriented Thinking
is required at this stage other than a clear understanding that eachDomain Model
should be autonomous. That is, eachDomain Modelshould only deal with a specific aspect of aProblem Situationand should not be cluttered with unrelated concerns. Note thatKnowledge Domain ModelsandSpecification Domain Modelswill of- ten be developed in different contexts and at different stages of theAspect-Oriented
Thinkingprocess. For example, many of the reusableKnowledge Domain Models
that deal with subject matters such as system architecture and implementation will be developed in the context of organisational support for the life-cycle of systems throughout an enterprise and over an extended period of time. As specific Problem Situations emerge, Problem Space Knowledge Domain Models
(Section 4.4.2.1) will be developed and verified in order to learn about and improve situations of immediate concern. Specification Domain Models, on the other hand, 77
will only be developed in the context of Aspect-Oriented Specifications related to the creation, modification, operation and retirement of specific systems.
5.3.4 Domain model verification and exploration
Because of their autonomous nature, the correct structure and behavior of each
Domain Model can be verified independently of other models, and before they
are used in the context of an Aspect-Oriented Specification. For example,Domain
Modelsthat deal with system requirements can be verified independently of, and
possibly before considering any system architectural, design or implementation concerns. This has advantages in terms of cost and schedule because the possibility of architectural, design and implementation rework is reduced as discussed in Section 2.6.2.
5.3.4.1 Static verification
MostAspect-Oriented Thinking Domainsare modelled using a language defined in
a specific meta-model (see Section 5.3.2). The aim ofstatic verificationis to ensure that eachDomain Modelis properly constructed in accordance with its meta-model. The process is not dissimilar to the way in which programming language compilers check software source code for syntax errors.
Whilestatic verification can be conducted using manual processes, it is often automated within modelling tools. For example, Bridgepoint [Mentor Graphics, 2006] and iUML [Kennedy Carter, 2006] can statically verify X
TUML models as they are created. Similarly,System Dynamicstools such asiThink[ISEE Systems, 2006] can statically verifySystem Dynamicsmodels as they are created.
5.3.4.2 Dynamic verification
The behaviour of Domain Models developed using executable languages such as X
TUML and System Dynamics can be verified using simulation. This involves execution of Domain Models in an interactive execution/simulation environment such as the Bridgepoint Verifier [Mentor Graphics, 2006] for X
TUML models and
iThink [ISEE Systems, 2006] for System Dynamics models. These simulations
can be used to verify and explore the behavior of a Domain Model. Information gathered fromdynamic verificationcan be used to learn about aProblem Situation, and to make decisions regarding its improvement.
5.4 Aspect-Oriented Specification Archetype development
5.4
Aspect-Oriented Specification Archetype develop-
ment
The purpose of this activity is to developAspect-Oriented Specification Archetypes
(Section 4.7) that can be used to form Aspect-Oriented Specifications for systems required to implement decisions made during the Problem Situation Analysis
activity. It will usually be conducted by interdisciplinary teams with expertise
in Aspect-Oriented Thinkingas well as architectural and implementation aspects
of targetSystems.
5.4.1 Requirement archetype development
The purpose of this sub-activity is to develop the Requirement Archetypes for a given Aspect-Oriented Specification Archetype and to provide a natural language description of their meaning. Note that these meanings are informal at this stage in the process of improving a Problem Situation. It is the development of Imple-
mentation Rulesthat will provide formal meaning toRequirement Archetypes.
5.5
Aspect-Oriented Specification development
The purpose of this activity is to form Aspect-Oriented Specifications for systems required to implement decisions made during the Problem Situation Analysis
activity. This involves the development ofSpecification Domain Modelsapplicable to the specification of a newSystems, followed by the actualRequirements.
The development of Aspect-Oriented Specifications will need to be conducted by individuals or teams that have some expertise in each of the domains involved, as well as Aspect-Oriented Thinking. For example, the development of an Aspect-
Oriented Specificationfor a new aircraft will require the expertise and knowledge
of a wide range of disciplines. While most of this expertise and knowledge will be developed within the context of each separate discipline, it must be woven together in various ways to specify particular aspects of the new aircraft. This will involve the development of Specification Domain Models that are unique to the new aircraft, along with a set of requirements that specify how these and applicable Knowledge Domain Models are to be used to build the aircraft. While this may seem onerous, it should be noted that most modelling effort will relate to the development and maintenance of the separate, and autonomous,Knowledge
Domain Modelsinvolved. This effort can be provided by domain experts who have
little or no expertise inAspect-Oriented Thinking.