6.3.1 Knowledge domain identification . . . 92 6.3.2 Language modelling . . . 94 6.3.3 Knowledge domain modelling . . . 94
6.4 Aspect-Oriented Specification Archetype development . . . 95 6.5 Aspect-Oriented Specification development . . . 96
6.5.1 Specification domain models . . . 96
6.6 Implementation modelling . . . 98 6.7 Implementation . . . 99 6.8 Conclusion . . . 99
6.1
Introduction
In Chapters 4 and 5 I presented the conceptual and process models of Aspect-
Oriented Thinking. As discussed in Section 3.3.2.1, the next step in the planned
research is to demonstrate the mechanics and viability ofAspect-Oriented Thinking
in order to support a case for its future evaluation and subsequent adoption within an industrial context.
In this chapter and the supporting Appendices B to G, I demonstrate the mechanics and viability of Aspect-Oriented Thinking by using it to develop a complete software application. The decision to use a software case study was based on the diversity of concerns involved and the consequential ability to demonstrate important properties of Aspect-Oriented Thinking throughout the entire system life-cycle, from concept through toimplementation andoperation. In particular, a software case study will demonstrate the effectiveness of separating concerns into autonomous domains, the use of appropriate languages to model each domain, and the development of valuable reusable intellectual assets.
Note that Appendices B to G contain a series of very detailed models which form an integral part of the Aspect-Oriented Thinking Proof-of-Concept. In most cases, they do not need to be read in their entirety. Rather, they should be treated as a reference that readers candrill into, if required, to gain a thourough understanding of a particular facet of the Aspect-Oriented Thinking approach. It should also be noted that, because the models were developed without any tool support, they may contain minor errors. However, this should not detract from the effectiveness and instructive nature of the Proof-of-Concept.
Cross-References
Extensive use of cross-referencing is made throughout the presentation of the
Product Management System proof-of-concept. In addition, aProof-of-Concept
Indexof elements involved is provided on page 385.
6.2
Problem situation analysis
The Problem Situation I am dealing with here is that industry partners are
unlikely to become involved in the future development and evaluation of Aspect-
Oriented Thinkingunless they develop some degree of confidence in the viability of
the approach.
6.2 Problem situation analysis
eliminated, by using Aspect-Oriented Thinking to develop a complete software application. The results of this demonstration will be used to support proposals for future industry-based evaluation and development ofAspect-Oriented Thinking.
The chosen software application is the Product Management System, a web- based system which will allow employees of small stores to manage a database of products they sell. The application will also allow customers to view the products available for sale. User requirements1for theProduct Management System (PMS) are enumerated below. Note that these requirements are intentionally informal, incomplete and inconsistent to reflect the kinds of requirements that can be expected from an end user of a software system.
6.2.1 Contact management user requirements
(a) TheProduct Management Systemshall record the following details about peo- ple and organisations with which the business interacts. These are collectively referred to ascontacts.
• Name
• Address
• Telephone number
• Mobile Phone number
• Email address
(b) Users of theProduct Management Systemshall be able to:
• create contact records
• edit contact records
• delete contact records
(c) TheProduct Management Systemshall record the following details about notes that can be attached to contact records:
• Date and Time the note was created
• Text message
(d) Users of theProduct Management Systemshall be able to:
• create and attach notes to contact records
1Wiegers
[2003, page 490] defines user requirements as ‘User goals or tasks that users must be able to perform with a system, or statements of the user’s expectations of system quality.’
• edit note records
• delete note records
(e) TheProduct Management Systemshall record relationships between contacts of the following kinds:
• <contact A>owns<contact B>
• <contact A>manages the finances of <contact B>
• <contact A>manages shipping for<contact B>
• <contact A>manages human resources for<contact B>
• <contact A>handles product returns for<contact B>
(f) Users of theProduct Management Systemshall be able to:
• create relationships between any two contacts
• change the type of a relationship
• delete relationships
6.2.2 Product management user requirements
(a) TheProduct Management Systemshall record the following details about each product sold by the business:
• Name
• Description
• Manufacturer
• Category
(b) Users of theProduct Management Systemshall be able to:
• create product records
• edit product records
• delete product records
(c) TheProduct Management Systemshall record the following details about each category of product sold by the business:
• Name
6.2 Problem situation analysis
(d) Users of theProduct Management Systemshall be able to:
• create product category records
• edit product category records
• delete product category records
(e) Products are often available in a number of variations such as color or material. Each variant will often be differently priced. TheProduct Management System
shall record the following information about variants of each product:
• Description
• Price
(f) Users of theProduct Management Systemshall be able to:
• create product variant records
• edit product variant records
• delete product variant records
6.2.3 Security user requirements
(a) Users shall be authenticated before they are permitted to use the Product
Management System.
(b) Users must be registered with the Product Management System before they can be authenticated.
(c) Users shall register with the Product Management Systemby providing a user name and password.
(d) The user names of each registered user shall be unique. (e) Each user shall be assigned one or more of the following roles:
• Staff
• Customer
(f) Users assigned the Staff role shall be able to create, edit and delete any information recorded by theProduct Management System.
(g) Users assigned theCustomer role shall only be able to read product informa- tion.
6.2.4 Constraints
(a) Users shall interact with the software via a standard web browser such as Firefox.
(b) The software shall be implemented to run on the Linux, Apache, MySQL and
PHP(LAMP) web-based client-server architectural framework.
The LAMP framework has been chose because, despite its popularity, it supports few of the well established principles of software engineering. This provides scope, within this proof-of-concept, to demonstrate the way in which
Aspect-Oriented Thinkingcan facilitate appropriate ‘engineering’ of a software
system despite poorly engineered implementation technologies.
6.3
Domain identification and analysis
The purpose of domain identification and analysis is to develop and capture the knowledge required to understand and improve a Problem Situation. This is achieved by identifying, modelling and verifying aspects of a given Problem
Situation. The following sections contain the results of domain analysis for the
Product Management System.
6.3.1 Knowledge domain identification
Domain identification is a difficult task. The domains involved in a Problem
Situation are likely to evolve as the situation itself evolves and understanding
of it matures. In the case of software and systems development, an initial set of
Knowledge Domains can be identified by considering the categories of available
user requirements.
The following initial set ofKnowledge Domainscan be identified based on the user requirements presented in Section 6.2. Specification Domains will emerge during the development of the Product Management System Aspect-Oriented
Specification.
• Contact Management Domain. The Contact Managementproblem space domain will deal with the subject matter of Contacts, Notes and Relation-
ships. It will ignore all other concerns, by only modelling the functional
6.3 Domain identification and analysis
• Product Management Domain. TheProduct Managementproblem space domain will deal with the subject matter of Products, Product Categories,
Product Variants and Manufacturers. It will ignore all other concerns, by
only modelling the functional requirements stated in Section 6.2.2.
• Security Domain. TheSecurity Supportdomain will deal with the general subject matter ofSecurity. It will not deal with specific security requirements for theProduct Management System. Instead, it will describe a reusable body of knowledge that can be used to specify application specific security policies including the one required for the Product Management System (Section 6.2.3). Like allDomains, it will be completely autonomous and will not refer to the subject matter of any otherDomain, including that of theContactand
Product Management Domains.
• User Interface (UI) Domain. The UI Support Domain will deal with the subject matter of user interfaces. Like the Security Domain, the UI
Domainwill not deal with specific user interface requirements for theProduct
Management System. Instead, it will describe a reusable body of knowledge
that can be used to specify any user interface, including one for theProduct
Management System.
The following initial set of Architectural andImplementation domains can be identified from the constraints stated in Section 6.2.4.
• LAMP Domain.The LAMParchitecturaldomain will describe the high level organisation of an application developed using theLAMPframework. It will include elements such asWeb Browser, ServerandDatabase.
• Linux Domain. TheLinux Implementation Domainwill represent the sub- ject matter of the Linux open-source operating system. Note that the Linux domain will not be modelled because it is well understood and documented in many academic, industrial and user documents. In addition, the Linux domain is not a software system that is called or executed in any way. Rather, it represents knowledge about the Linux operating system that will be used during construction of theProduct Management Systemapplication.
• Apache Domain. The Apache Implementation Domain will represent knowledge about the Apache web server. The subject matter of this domain will be used to implement the server component of theProduct Management
Systemarchitecture.
• Structured Query Language (SQL). The SQL Implementation Domain
will represent knowledge about standard SQL. All database interaction re- 93
quired by theProduct Management Systemwill be conducted using concepts captured by the SQL domain.
• MySQL Domain. The MySQL Implementation Domain will be used to implement database concepts represented by theSQL Domain. Note that the autonomous nature of domains means that theMySQL Relational Database
domain model can be replaced by one that represents another database such
asPostgreSQL.
• PHP Domain. The PHP Implementation Domainwill represent knowledge about the PHP5 programing language. This knowledge will be used to implement parts of theContact Management, Product Management, Security
andUser Interface Domains.
6.3.2 Language modelling
In most cases, Aspect-Oriented Thinking knowledge domains will be modelled as instances of the common meta-models identified in Section 4.4.2.5. Modelling of domains for the proof-of-concept is no exception. Table 6.1 lists each of theproof-
of-concept Knowledge Domain Models, their meta-models and references.
Note that the Informal Block Diagram meta-model is not one of the common models identified in Section 4.4.2.5. As such, it needs to be developed before
the LAMP Framework domain model can be developed. Figure 6.1 shows a
class diagram that depicts the simple Block Diagram meta-model used in this
proof-of-concept. Block Link Name is linked from 0..1 0..1 is linked to Name
Figure 6.1: The Block Diagram Meta-Model.
6.3.3 Knowledge domain modelling
As mentioned in Section 5.3.3, the purpose of domain modelling is to develop a clear understanding of the subject matter of a specific Domain. Appendix B contains
theKnowledge Domain Modelswhich will be used in the formation of theProduct
Management System Aspect-Oriented Specification. These models relate to the
6.4 Aspect-Oriented Specification Archetype development
Table 6.1: Proof-of-Conceptknowledge domains and meta-models
Domain Meta-Model Reference
Contact Management X TUML Section B.2 Product Management X TUML Section B.3 Security X TUML Section B.4 User Interface X TUML Section B.5 LAMP Informal Block Diagram (Figure 6.1) Section B.6
Linux English Kernel.Org Organization,
Inc.[2006]
Apache English Apache Software Founda-
tion[2006]
Structured Query Language English International Organization
for Standardization[2005b]
MySQL English MySQL AB[2006]
PHP English The PHP Group[2006]
6.4
Aspect-Oriented Specification Archetype develop-
ment
Aspect-Oriented Specification Archetypes describe how subject matter captured in
Knowledge Domain Modelscan be used to formAspect-Oriented Specifications for
systems that share a common architecture.
For the purposes of this proof-of-concept, the Aspect-Oriented Specification
Archetype contained in Appendix C has been developed using the Knowledge
Domain Models contained in Appendix B. This archetype comprises a set of
Requirement Archetypesthat can be used to formAspect-Oriented Specificationsfor
software systems that share an architecture based on theLinux, Apache, MySQL,
and PHP(LAMP) framework.
6.5
Aspect-Oriented Specification development
As mentioned in Section 4.6, the purpose of developing an Aspect-Oriented
Specification is to state requirements for a new System. For the purposes of
thisproof-of-concept, anAspect-Oriented Specificationfor theProduct Management
System has been formed in accordance with the Aspect-Oriented Specification
Archetypecontained in Appendix C.
The completed Product Management System Aspect-Oriented Specification is contained in Appendix D. Figure 6.2 shows a diagram which depicts the contents of the specification using the notation described in Appendix A.
6.5.1 Specification domain models
The LAMP Aspect-Oriented Specification Archetype requires conformant Aspect-
Oriented Specificationsto include instances of theX
TUMLdomain model to specify data requirements, an instance of theUser Interfacedomain model to specify user interface requirements, and an instance of the Security domain model to specify security requirements. For the purposes of this proof-of-concept, the following
Domain Modelshave been formed or reused to satisfy these needs.
• Product Managementdomain model (Section B.3) and Contact Man- agement domain model (Section B.2). TheseKnowledge Domain Models
are instances of theX
TUMLdomain model and have been used to specify data requirements for theProduct Management System. The data to be managed by the Product Management System has been specified using Requirements
represented byRequirement Set RS01andRequirement Set RS02depicted in Figure 6.2. The details of theseRequirementsare contained in Section D.2.
• PMS User Interfacedomain model (Section D.5).User interface require- ments for the PMS were not provided in the original user requirements listed in Section 6.2. It was left, at that time, to Human-Computer Interaction (HCI) and other user interfacedomain expertsto elicit user interface require- ments and to capture them in the form of user interfaceDomain Models.
The PMS User Interface domain model is a Specification Domain Model
that has been formed to specify user interface requirements for the Product
Management System. It is an instance of the User Interface domain model
and has been depicted as a series of page layouts shown in Figures D.3 to D.19.
The way in which the user interface controls theProduct Management System
6.5 Aspect-Oriented Specification development PHP (Programming Language) PMS UI PMS Security (PMSSEC) Structured Query Language (SQL) Security (SEC) User Interface (UI) Contact Management (CM) Product Management (PM) xtUML Security Mechanisms (Linux) Linux Operating System
(Relational Database) MySQL Apache (Web Server) <<instsanceOf>> <<instsanceOf>> RS05 RS06 RS03 RS09 RS10 <<instsanceOf>> RS07 RS04 RS08 <<instsanceOf>> RS01 RS02 <<instsanceOf>> <<instsanceOf>> RS11
Figure 6.2: Package diagram depicting the Aspect-Oriented Specification for the
Product Management System.
matter within the PMS User Interface domain model, Contact Management
domain model and Product Management domain model as indicated by
Requirement Set RS04. Interaction among the pages is, likewise, specified
byRequirementsas indicated byRequirement Set RS05. The details of these
Requirementsare contained in Section D.6.
• PMS Security domain model (Section D.3). This is a Specification
Domain Model that has been formed to specify the Roles and Permissions
that are applicable to the Product Management System. It is an instance of the Security domain model and formalises the user requirements stated in Section 6.2.3. Requirements that reference subject matter from the PMS
Security domain model, Contact Management domain model and Product
Management domain model are represented by Requirement Set RS04 and
are used to identify those data items that are subject to a specific security policy. The details of theseRequirementsare contained in Section D.4.
6.6
Implementation modelling
Implementation modelling involves the development of Implementation Rules
which describe how an appropriately formedAspect-Oriented Specification can be implemented to create a newSystem.
Appendix E contains anImplementation Modelthat can be used to generate a complete LAMP application from anyAspect-Oriented Specification that conforms to theLAMP Aspect-Oriented Specification Archetypedescribed in Appendix C. As such, this and otherImplementation Modelsare highly reusable.
Note that X
TUML Domain Models referenced by the Product Management
System Aspect-Oriented Specification do include state models. As such, no action
language is used. This is possible because the Product Management System is a simple Create, Read, Update, Delete (CRUD) application with no business rules other than those captured in associations among domain model elements. As a result, theLAMP Implementation Modeldescribed in Appendix E is limited to the generation of CRUD type applications. More complex applications involving the use of theObject Constraint Language[Object Management Group, 2006] andState