A unified view approach to software development automation

Vietnam National University, Hanoi
VNU University of Engineering and Technology

LE MINH DUC

A Unified View Approach to
Software Development Automation

Doctor of Philosophy Dissertation
in Information Technology

Hanoi - 2020


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LÊ MINH ĐỨC

PHƯƠNG PHÁP TIẾP CẬN
KHUNG NHÌN HỢP NHẤT CHO
TỰ ĐỘNG HĨA PHÁT TRIỂN PHẦN MỀM

LUẬN ÁN TIẾN SĨ NGÀNH CƠNG NGHỆ THÔNG TIN

Hà Nội - 2020


Vietnam National University, Hanoi
VNU University of Engineering and Technology

LE MINH DUC

A Unified View Approach to
Software Development Automation
Specialisation: Software Engineering
Code: 9480103.01

Doctor of Philosophy Dissertation
in Information Technology

Supervisors:
1. Assoc. Prof., Dr. Nguyen Viet Ha
2. Dr. Dang Duc Hanh

Hanoi – 2020


ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LÊ MINH ĐỨC

PHƯƠNG PHÁP TIẾP CẬN
KHUNG NHÌN HỢP NHẤT CHO
TỰ ĐỘNG HÓA PHÁT TRIỂN PHẦN MỀM
Chuyên ngành: Kỹ thuật Phần mềm
Mã số: 9480103.01

LUẬN ÁN TIẾN SĨ NGÀNH CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC:
1. PGS. TS. Nguyễn Việt Hà
2. TS. Đặng Đức Hạnh

Hà Nội – 2020


Declaration
I hereby declare that the materials presented in this dissertation are my own work, conducted
under the supervision of Assoc. Prof., Dr. Nguyen Viet Ha and Dr. Dang Duc Hanh, at
the Faculty of Information Technology, University of Engineering and Technology, Vietnam
National University, Hanoi. All the research data and results presented in this dissertation
are authentic and (to the best of my knowledge) have not previously been published in any
academic publications by other authors.

Le Minh Duc


Abstract
An important software engineering methodology that has emerged over the past twenty
years is model-based software development. At the heart of this methodology lies two
complementary methods: model-driven software engineering (MDSE) and domain-driven
design (DDD). While the aim of MDSE is ambitiously broad, DDD’s goal is more modest
and direct but not less important – to apply model-based engineering techniques to tackle the
complexity inherent in the domain requirements. The state-of-the-art DDD method includes
a set of principles for constructing a domain model that is feasible for implementation in a
target programming language. However, this method lacks the solutions needed to address
the following important design questions facing a technical team when applying DDD in
object oriented programming language (OOPL) platforms: (i) what constitues an essentially
expressive domain model and (ii) how to effectively construct a software from this model.

The dissertation aims to address these limitations by using annotation-based domain-specific
language (aDSL), which is internal to OOPL, to not only express an essential and unified
domain model but generatively construct modular software from this model.
First, we propose an aDSL, named domain class specification language (DCSL), which
consists in a set of annotations that express the essential structural constraints and the essential
behaviour of a domain class. We carefully select the design features from a number of
authoritative software and system engineering resources and reason that they form a minimum
design space of the domain class.
Second, we propose a unified domain (UD) modelling approach, which uses DCSL to
express both the structural and behavioural modelling elements. We choose UML activity
diagram language for behavioural modelling and discuss how the domain-specific constructs
of this language are expressed in DCSL. To demonstrate the applicability of the approach we
define the UD modelling patterns for tackling the design problems posed by five core UML
activity flows.


Third, we propose a 4-property characterisation for the software that are constructed
directly from the domain model. These properties are defined based on a conceptual layered
software model that includes the domain model at the core, an intermediate module layer
surrounding this core and an outer software layer.
Fourth, we propose a second aDSL, named module configuration class language (MCCL),
that is used for designing module configuration classes (MCCs) in a module-based software
architecture. An MCC provides an explicit class-based definition of a set of module configurations of a given class of software modules. The MCCs can easily be reused to create
different variants of the same module class, without having to change the module class design.
Fifth, we develop a set of software tools for DCSL, MCCL and the generators associated
with these aDSLs. We implement these tools as components in a software framework, named
jDomainApp, which we have developed in our research.
To evaluate the contributions, we first demonstrate the practicality of our method by
applying it to a relatively complex, real-world software construction case study, concerning
organisational process management. We then evaluate DCSL as a design specification language and evaluate the effectiveness of using MCCL in module-based software construction.

We focus the latter evaluation on module generativity.
We contend that our contributions help make the DDD method more concrete and more
complete for software development. On the one hand, the method becomes more concrete
with solutions that help effectively apply the method in OOPL platforms. On the other hand,
the method is more complete with solutions for the design aspects that were not originally
included.


Tóm tắt
Trong vịng hai thập kỷ gần đây, phương pháp luận phát triển phần mềm dựa trên mơ
hình nổi lên là một phương pháp luận quan trọng trong kỹ nghệ phần mềm. Ở trung
tâm của phương pháp luận này có hai phương pháp có tính bổ trợ nhau là: kỹ nghệ
phần mềm hướng mơ hình (model-driven software engineering (MDSE)) và thiết kế
hướng miền (domain-driven design (DDD)). Trong khi MDSE mang một mục tiêu
rộng và khá tham vọng thì mục tiêu của DDD lại khiêm tốn và thực tế hơn, đó là
tập trung vào cách áp dụng các kỹ thuật của kỹ nghệ dựa trên mơ hình để giải quyết
sự phức tạp vốn có trong yêu cầu miền. Phương pháp DDD hiện tại bao gồm một
tập các nguyên lý để xây dựng một mơ hình miền ở dạng khả thi cho triển khai viết
mã trên một ngơn ngữ lập trình đích. Tuy nhiên phương pháp này còn thiếu các giải
pháp cần thiết giúp giải đáp hai câu hỏi quan trọng mà người phát triển phần mềm
thường gặp phải khi áp dụng DDD vào các nền tảng ngơn ngữ lập trình hướng đối
tượng (object oriented programming language (OOPL)): (i) những thành phần nào
cấu tạo nên một mơ hình miền có mức độ diễn đạt thiết yếu? và (ii) xây dựng một
cách hiệu quả phần mềm từ mơ hình miền như thế nào? Luận án này đặt mục đích
khắc phục hạn chế trên của DDD bằng cách sử dụng ngôn ngữ chuyên biệt miền dựa
trên ghi chú (annotation-based domain-specific language (aDSL)), được phát triển
trong OOPL, để khơng chỉ biểu diễn một mơ hình miền hợp nhất thiết yếu mà còn để
xây dựng phần mềm có tính mơ-đun từ mơ hình miền này.
Thứ nhất, luận án đề xuất một aDSL, tên là ngôn ngữ đặc tả lớp miền (domain
class specification language (DCSL)), bao gồm một tập các ghi chú để biểu diễn các

ràng buộc cấu trúc thiết yếu và các hành vi thiết yếu của lớp miền. Tác giả đã cẩn
thận lựa chọn các đặc trưng thiết kế từ một số nguồn tài liệu học thuật có uy tín về


kỹ nghệ phần mềm và kỹ nghệ hệ thống và lập luận rằng các đặc trưng này tạo thành
một không gian thiết kế tối giản cho lớp miền.
Thứ hai, luận án đề xuất một phương thức tiếp cận mơ hình hóa miền hợp nhất,
trong đó sử dụng DCSL để biểu diễn các thành phần mơ hình hóa cấu trúc và hành
vi. Luận án đã chọn ngôn ngữ biểu đồ hoạt động UML cho mơ hình hóa hành vi và
trình bày cách biểu diễn các đặc trưng chuyên biệt trạng thái của ngơn ngữ này bằng
DCSL. Để chứng tỏ tính thực tiễn của cách tiếp cận, luận án định nghĩa một tập mẫu
mơ hình hóa miền hợp nhất cho các bài toán thiết kế liên quan trực tiếp đến năm
luồng hoạt động UML cơ bản.
Thứ ba, luận án đề xuất một mơ tả đặc điểm gồm bốn tính chất cho phần mềm
được xây dựng trực tiếp từ mơ hình miền. Bốn tính chất này được định nghĩa dựa trên
mơ hình khái niệm phần mềm dạng phân lớp, bao gồm mơ hình miền ở lớp lõi, một
lớp mô-đun trực tiếp bao quanh lớp lõi và một lớp phần mềm ở ngoài.
Thứ tư, luận án đề xuất một aDSL thứ hai, tên là ngơn ngữ lớp cấu hình mơ-đun
(module configuration class language (MCCL)), dùng để thiết kế các lớp cấu hình
mơ-đun (module configuration classes (MCCs)) trong một kiến trúc phần mềm dựa
trên mô-đun. Mỗi MCC cung cấp một định nghĩa dạng lớp cho một tập các cấu hình
mơ-đun của một lớp mơ-đun. Các MCC có thể dễ dàng sử dụng lại để tạo ra các biến
thể của một lớp mô-đun mà không cần sửa thiết kế bên trong của mô-đun.
Thứ năm, luận án phát triển một bộ công cụ dành cho DCSL, MCCL và các bộ
sinh mã của các ngôn ngữ này, dưới dạng các thành phần của một phần mềm khung,
tên là JDOMAINAPP. Để đánh giá các kết quả trên, luận án trước hết trình diễn tính
thực tiễn của phương pháp bằng cách áp dụng vào một trường hợp nghiên cứu tương
đối phức tạp về phát triển phần mềm, liên quan đến quản lý quy trình tổ chức. Tiếp
theo, luận án đánh giá DCSL từ khía cạnh một ngơn ngữ đặc tả và đánh giá hiệu quả
việc sử dụng MCCL trong xây dựng mô-đun phần mềm một cách tự động. Chúng tôi

cho rằng, các đóng góp của luận án giúp phương pháp DDD trở nên cụ thể và đầy đủ
hơn. Một mặt, phương pháp trở nên cụ thể hơn với các giải pháp giúp áp dụng một
cách hiệu quả vào các nền tảng OOPL. Mặt khác, phương pháp trở nên đầy đủ hơn
với các giải pháp cho các khía cạnh thiết kế chưa được xem xét tới.


Acknowledgement
I would first like to thank my supervisors, Assoc. Prof. Nguyen Viet Ha and Dr. Dang
Duc Hanh, for their instructions and guidance throughout my research and the development
of this dissertation. I would also like to thank all the teachers at the Faculty of Information
Technology (University of Engineering and Technology, Hanoi) for the very kind support
that I have received throughout my research study at the department.
I am deeply grateful for my home university (Hanoi University) for providing the PhD
studentship and a gracious teaching arrangement, that has enabled me to have the time to
complete the required course works and research. I am also very grateful for the financial
support that I have additionally received from the MOET’s 911 fund and the NAFOSTED
project (grant number 102.03-2015.25), led by Assoc. Prof. Nguyen Viet Ha.
I would also like to thank all of my colleagues and fellow PhD students for the many
meaningful and entertaining discussions. Last but not least, I wish to thank my family for the
sacrifices that they have made and for all the love and encouragement that they have given
me during my PhD study.


Contents
Glossary

v

List of Figures

vii

List of Tables

ix

1

.
.
.
.
.
.
.

1
3
3
5
7
7
8
12

.
.
.
.
.

.
.
.
.

13
13
13
15
17
22
27
28
29
33

2

Introduction
1.1 Problem Statement . . . . . . . . . . . . .
1.1.1 Motivating Example . . . . . . . .
1.1.2 Domain-Driven Design Challenges
1.1.3 Research Statement . . . . . . . . .
1.2 Research Aim and Objectives . . . . . . . .
1.3 Research Approach . . . . . . . . . . . . .
1.4 Dissertation Structure . . . . . . . . . . . .

.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.

.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.

.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

State of the Art
2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Model-Driven Software Engineering . . . . . . . . . . . . . . .

2.1.2 Domain-Specific Language . . . . . . . . . . . . . . . . . . . .
2.1.3 Meta-Modelling with UML/OCL . . . . . . . . . . . . . . . .
2.1.4 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . .
2.1.5 Model-View-Controller Architecture . . . . . . . . . . . . . . .
2.1.6 Comparing and Integrating MDSE with DDD . . . . . . . . . .
2.1.7 A Core Meta-Model of Object-Oriented Programming Language
2.1.8 Using Annotation in MBSD . . . . . . . . . . . . . . . . . . .

i

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.


2.2

2.3
3

4

Domain-Driven Software Development with aDSL . . . . .
2.2.1 DDD with aDSL . . . . . . . . . . . . . . . . . . .
2.2.2 Behavioural Modelling with UML Activity Diagram
2.2.3 Software Module Design . . . . . . . . . . . . . . .
2.2.4 Module-Based Software Architecture . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .

Unified Domain Modelling with aDSL
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 DCSL Domain . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Essential State Space Constraints . . . . . . . . .
3.2.2 Essential Behaviour Types . . . . . . . . . . . . .
3.3 DCSL Syntax . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Expressing the Pre- and Post-conditions of Method
3.3.2 Domain Terms . . . . . . . . . . . . . . . . . . .
3.4 Static Semantics of DCSL . . . . . . . . . . . . . . . . .
3.4.1 State Space Semantics . . . . . . . . . . . . . . .
3.4.2 Behaviour Space Semantics . . . . . . . . . . . .
3.4.3 Behaviour Generation for DCSL Model . . . . . .
3.5 Dynamic Semantics of DCSL . . . . . . . . . . . . . . .
3.6 Unified Domain Model . . . . . . . . . . . . . . . . . . .
3.6.1 Expressing UDM in DCSL . . . . . . . . . . . . .
3.6.2 UD Modelling Patterns . . . . . . . . . . . . . . .
3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . .

Module-Based Software Construction with aDSL
4.1 Introduction . . . . . . . . . . . . . . . . . .
4.2 Software Characterisation . . . . . . . . . . .
4.2.1 An Abstract Software Model . . . . .
4.2.2 Instance-based GUI . . . . . . . . . .
4.2.3 Model reflectivity . . . . . . . . . . .
4.2.4 Modularity . . . . . . . . . . . . . .
4.2.5 Generativity . . . . . . . . . . . . . .

ii

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.

.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.

.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

35
36
36
40
41
45

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

46
46
47
47
48
49
56
57
57
58
64
68
71

72
73
76
87

.
.
.
.
.
.
.

88
88
89
90
91
92
92
94


4.3

4.4

4.5

4.6

5

Module Configuration Domain . . . . . . . . . . . . . . . . . .
4.3.1 One Master Module Configuration . . . . . . . . . . . .
4.3.2 The ‘Configured’ Containment Tree . . . . . . . . . . .
4.3.3 Customising Descendant Module Configuration . . . . .
MCCL Language Specification . . . . . . . . . . . . . . . . . .
4.4.1 Specification Approach . . . . . . . . . . . . . . . . . .
4.4.2 Conceptual Model . . . . . . . . . . . . . . . . . . . .
4.4.3 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . .
4.4.4 Concrete Syntax . . . . . . . . . . . . . . . . . . . . .
4.4.5 Semantics . . . . . . . . . . . . . . . . . . . . . . . . .
MCC Generation . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Structural Consistency between MCC and Domain Class
4.5.2 MCCGEN Algorithm . . . . . . . . . . . . . . . . . . .
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Evaluation
5.1 Implementation . . . . . . . . . . . . . . . . . . .
5.1.1 UD Modelling . . . . . . . . . . . . . . .
5.1.2 Module-Based Software Construction . . .
5.2 Case Study: ProcessMan . . . . . . . . . . . . .
5.2.1 Method . . . . . . . . . . . . . . . . . . .
5.2.2 Case and Subject Selection . . . . . . . . .
5.2.3 Data Collection and Analysis . . . . . . . .
5.2.4 Results . . . . . . . . . . . . . . . . . . .
5.3 DCSL Evaluation . . . . . . . . . . . . . . . . . .
5.3.1 Evaluation Approach . . . . . . . . . . . .
5.3.2 Expressiveness . . . . . . . . . . . . . . .
5.3.3 Required Coding Level . . . . . . . . . . .

5.3.4 Behaviour Generation . . . . . . . . . . .
5.3.5 Performance Analysis . . . . . . . . . . .
5.3.6 Discussion . . . . . . . . . . . . . . . . .
5.4 Evaluation of Module-Based Software Construction
5.4.1 Module Generativity Framework . . . . . .
iii

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.

.
.
.
.
.
.
.
.
.
.
.
.

95
95
95
96
97
97
98
104
110
114
114
114
116
118

.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

119
119
119
121
122
122
122
123
123
127
127
129
132
133

134
134
135
135


.
.
.
.
.

137
138
143
144
144

Conclusion
6.1 Key Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

145
146
147

5.5
6

5.4.2 M P1 : Total Generativity

5.4.3 M P2 –M P4 . . . . . . .
5.4.4 Analysis of MCCGen .
5.4.5 Discussion . . . . . . .
Summary . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.

.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.

.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.

.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.

.
.
.
.

.
.
.
.
.

.
.
.
.
.

Bibliography

150

Appendices
A Helper OCL Functions for DCSL’s ASM

158

B MCCL Specification
B.1 Library Rules of the MCCL’s ASM . . . . . . . . . . . . . . . . . . . . .
B.2 Two MCCs of ModuleEnrolmentMgmt . . . . . . . . . . . . . . . . . . . .

164
164
167

C DCSL Evaluation Data
C.1 Expressiveness Comparison Between DCSL and the DDD Frameworks . .
C.2 Level of Coding Comparison Between DCSL and the DDD Frameworks . .

171
171
173

iv


Glossary
aDSL

Annotation-Based DSL, page 36

ASM

Abstract Syntax Meta-model, page 17

AtOP

Attribute-Oriented Programming, page 35

BISL

Behaviour Interface Specification Language, page 35

CSM

Concrete Syntax Meta-model, page 17

DCSL

Domain Class Specification Language, page 51

DDD

Domain-Driven Design, page 22

DDDAL

DDD with aDSLs, page 8

DSL

Domain-Specific Language, page 15

JML

Java Modelling Language, page 36

MCC

Module Configuration Class, page 99

MCCL

Module Configuration Class Language, page 99

MDA

Model-Driven Architecture, page 13

MDD

Model-Driven Development, page 13

MDE

Model-Driven Engineering, page 13

MDSE

Model-Driven Software Engineering, page 13

v


MVC

Model-View-Controller, page 27

OCL

Object Constraint Language, page 18

OOPL

Object-Oriented Programming Language, page 29

PIM

Platform-Independent Model, page 14

PSM

Platform-Specific Model, page 14

SDM

Semantic Domain Meta-model, page 17

UDM

Unified Domain Model, page 76

UML

Unifield Modelling Language, page 18

UML/OCL UML made precise with OCL, page 18

vi

List of Figures
1.1
1.2

A partial domain model of CourseMan. . . . . . . . . . . . . . . . . . . .
An overview of DDDAL (with an emphasis on phases 1 and 2). . . . . . . .

2.1
2.2
2.3
2.4
2.5

The essential ASM of UML (synthesised from seven meta-models of UML [57]).
The OCL expression meta-model (Adapted from §8.3 [56]). . . . . . . . .
A UI class of the domain class Student (Source: [45]). . . . . . . . . . . .
The UML-based ASM of OOPL. . . . . . . . . . . . . . . . . . . . . . . .
The meta-model of UML activity modelling language (Adapted from §15.2.2
of the UML specification [57]). . . . . . . . . . . . . . . . . . . . . . . . .
The UML activity models of five basic variants of the CourseMan’s enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . .
The MOSA model of CourseMan. . . . . . . . . . . . . . . . . . . . . .
A ModuleEnrolmentMgmt’s view containing a child ModuleStudent’s view.

2.6
2.7
2.8
3.1
3.2
3.3

3.4
3.5
3.6
3.7

The abstract syntax model of DCSL. . . . . . . . . . . . . . . . . . . . . .
A DCSL model for a part of the CourseMan domain model. . . . . . . . .
(A: Left) The UML activity and class models of a CourseMan software
variant that handles the enrolment management activity; (B: Right) The
UDM that results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The sequential pattern form (top left) and an application to the enrolment
management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The sequential pattern form view of enrolment management activity. . . . .
The decisional pattern form (top left) and an application to the enrolment
management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The decisional pattern form view of enrolment management activity. . . . .
vii

3
9
18
20
28
30
38
39
43
44
50
55

75
77
78
79
80


3.8
3.9
3.10
3.11
3.12
3.13
4.1
4.2

The forked pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The forked pattern form view of enrolment management activity. . . . . . .
The joined pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The joined pattern form view of enrolment management activity. . . . . . .
The merged pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The merged pattern form view of enrolment management activity. . . . . .

81
82
83
84
85
86

4.6
4.7
4.8

A detailed view of DDDAL’s phase 2 with software module construction. .
89
An abstract UML-based software model: (core layer) domain model, (middle
layer) module and (top layer) software. . . . . . . . . . . . . . . . . . . . .
90
The GUI of CourseMan software prototype generated by jDomainApp: (1)
main window, (2-4) the UDM’s GUI for EnrolmentMgmt, Student, and
Enrolment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
The CM of MCCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
(A-shaded area) The transformed CM (CMT ); (B-remainder) Detailed design of the 105
key classes of CMT .
The annotation-based ASM. . . . . . . . . . . . . . . . . . . . . . . . . . 109
The view of a (stand-alone) ModuleStudent object. . . . . . . . . . . . . . 111
The customised view of ModuleEnrolmentMgmt (as configured in Listing 4.2).113

5.1
5.2
5.3
5.4
5.5

A partial CourseMan’s GUI that is generated by DomainAppTool. . . .
ProcessMan’s domain model. . . . . . . . . . . . . . . . . . . . . . . .

A partial MCC Model for process structure. . . . . . . . . . . . . . . . .
The view of ModuleEnrolmentMgmt of the software in Figure 5.1. . . . .
An example CourseMan software that has substantially been customised.

4.3

4.4
4.5

.
.
.
.
.

121
124
125
138
141

A.1 Utility class ExprTk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Utility class Tk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

158
160

viii

List of Tables
2.1

Meta-mapping between OOPL and UML/OCL . . . . . . . . . . . . . . .

33

3.1
3.2
3.3
3.4
3.5
3.6
3.7

The essential state space constraints . . . . . . . . . . . . . .
The essential behaviour types . . . . . . . . . . . . . . . . . .
Well-formedness constraints of DCSL . . . . . . . . . . . . .
The boolean state space constraints of DCSL . . . . . . . . .
The non-boolean state space constraints of DCSL . . . . . . .
The core structural mapping rules . . . . . . . . . . . . . . .
Translating Domain Field properties into JML’s class invariants

.
.
.
.
.
.
.

48
49
59
60
63
67
72

4.1

Mapping from CM to CMT . . . . . . . . . . . . . . . . . . . . . . . . . .

107

5.1
5.2

The expressiveness aspects and domain properties of interest . . . . . . . .
(A-left) Comparing DCSL to DDD patterns; (B-right) Comparing DCSL to
AL and XL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
(A-left) Summary of max-locs for DCSL, AL and XL; (B-right) Summary
of typical-locs for DCSL, AL and XL . . . . . . . . . . . . . . . . . . . .
BSpaceGen for CourseMan . . . . . . . . . . . . . . . . . . . . . . . . .
Module pattern classification . . . . . . . . . . . . . . . . . . . . . . . . .
Module generativity values of two CourseMan’s modules in M P2 –M P4 .

128

C.1 Comparing the expressiveness of DCSL to AL, XL . . . . . . . . . . . . .

C.2 Comparing the max-locs of DCSL to AL, XL . . . . . . . . . . . . . . . .
C.3 Comparing the typical-locs of DCSL to AL, XL . . . . . . . . . . . . . . .

171
173
174

5.3
5.4
5.5
5.6

ix

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.

.

130
132
133
135
140


Chapter 1
Introduction
There is no doubt that an important software engineering research area over the last two
decades is what we would generally call model-based software development (MBSD) – the
idea that a software can and should systematically be developed from abtractions, a.k.a models,
of the problem domain. MBSD brings many important benefits, including ease of problem
solving and improved quality, productivity and reusability. Perhaps a most visible and novel
software engineering development that falls under the MBSD umbrella is model-driven
software engineering (MDSE) [9, 16, 38, 67]. Another more modest and direct development
method is domain-driven design (DDD) [22, 62, 75].
Very early on, Czarnecki [16] stated that MDSE is a type of generative software development (GSD). The key benefits of MDSE are to significantly improve reusability and productivity in producing software for different implementation platforms. These are basically
achieved by constructing the high-level (platform-independent) software models before-hand
and then very efficiently, typically with the help of proven automated techniques and tools,
applying these models to a new platform to generate the software for it. This application
step makes extensive use of reusable assets, including software frameworks, components,
architectures and models [16].
While the MDSE’s goal is ambitiously broad and encompassing, DDD [22] focuses
more specifically on the problem of how to effectively use models to tackle the complexity
inherent in the domain requirements. DDD’s goal is to develop software based on domain
models that not only truly describe the domain but are technically feasible for implementation.
According to Evans [22], object-oriented programming language (OOPL) is especially suited

for use with DDD. This is not surprising, given that Booch [8] had ealier pointed out two
1


main reasons why OOPL would result in domain models that are inherently expressive and
feasible. First, object naturally represents the (abstract) entities that are conceived to exist in
real-world domains. Second, the construct of object used in OOPL is also a basic construct
of high-level analysis and design modelling languages that are used to conceptualise and
analyse the domain.
The domain model, which is primarily studied under DDD and a type of model engineered
in MDSE, is in fact the basis for specifying what had been called in the language engineering
community as domain-specific language (DSL) [74]. The aim of DSL is to express the
domain using concepts that are familiar to the domain experts. A key requirement in DSL
engineering is to enable the domain experts and the technical team to focus on building the
domain model, not having to worry about the technicality of language design.
A type of DSL, called annotation-based DSL (aDSL) [25, 54], appears to satisfy this
requirement. aDSL is an application of the annotation feature of modern OOPLs in DSL
engineering. Before this, however, annotation (called attribute in C# [33]) was used in
attribute-oriented programming (AtOP) [12, 13] to express meta-attributes and in behaviour
interface specification language (BISL) [32] to define the specification structure. A key
benefit of aDSL is that it is internal to the host OOPL and thus does not require a separate
syntax specification. This helps significantly reduce development cost and increase ease-oflearning.
In fact, simple forms of aDSL have been used quite extensively in both DDD and MDSE
communities. In DDD, annotation-based extensions of OOPLs have been used to develop
software frameworks (e.g. [17, 60]) that support the development of not only the domain
model but the final software. The design rules in these models are expressed by a set of
annotations. In MDSE, annotation sets are used to construct platform-specific models of
software [4, 76, 77, 78].
Our initial research started out with an MBSD-typed investigation into a practical problem
of how to improve the productivity of object-oriented software development [8, 43, 49, 51]

using a Java-based design language for the domain model [44] and a software architectural
model [45]. Placing these works in the context of DDD, MDSE and aDSL have given us
an opportunity to advance our research to tackle a broader and more important problem
concerning the DDD method for object-oriented software.

2


1.1

Problem Statement

In this section, we will discuss the key challenges facing DDD for the object-oriented problem
domains and define a research statement that is tackled in this disseration. We motivate our
discussion using a software example, which we will also use throughout the dissertation to
illustrate the concepts that are being presented.

1.1.1

Motivating Example

Figure 1.1: A partial domain model of CourseMan.
Our motivating example is a course management problem domain (abbr. CourseMan),
which describes a compact, yet complete, domain that includes both structural and behavioural
aspects. Figure 1.1 shows a partially completed CourseMan domain model expressed in the
form of a UML class diagram [57]. Notationwise, in this dissertation, when it is necessary
3


to highlight the type of model element we will use a/an/the with name of the element type

to refer to a particular element, and the plural form of this name to refer to a collection
of elements. Further, we will use normal font for high-level concepts and fixed font for
domain-specific and technical concepts.
The bottom part of Figure 1.1 shows four classes and two association classes of CourseMan. Class Student represents the domain concept Student, who registers to study in an
academic instituition. Class CourseModule represents the Course Modules1 that are offered
by the institution. Class ElectiveModule represents a specialised type of CourseModule.
Class SClass represents the student class type (morning, afternoon, or evening) for students
to choose. Association class SClassRegistration captures details about the many-many
association between Student and SClass. Finally, association class Enrolment captures
details about the many-many association between Student and CourseModule.
The top part of Figure 1.1 (the area containing a star-like shape with this label “?”)
shows six other classes that are intended to capture the design of an activity called enrolment
management. We know some design details (the attributes shown in the figure) and the
following description about the six classes. We will give more details about the activity later
in Chapter 2.
– HelpRequest: captures data about help information provided to students.
– Orientation: captures data about orientation programs for newly-registered students.
– Payment: captures data about payment for the intuition fee that a student needs to
make.
– Authorisation: captures data about the decision made by an enrolment officer concerning whether or not to allow a student to undertake the registered course modules.
– EnrolmentApproval: captures data about the decision made by the enrolment officer
concerning a student’s enrolment.
– EnrolmentMgmt: represents the enrolment management activity. This activity involves
registering Students, enrolling them into CourseModules and registering them into
SClasses. In addition, it allows each Student to raise a HelpRequest.
1 we use class/concept name as countable noun to identify instances.

4

1.1.2

Domain-Driven Design Challenges

Let us now outline the key challenges facing domain modelling in DDD and software development from the domain model. Understanding these challenges leads us to formulate a set
of open issues for the research statement that we tackle in this dissertation.
Essential Constraints
The UML note boxes in Figure 1.1 shows examples of 11 kinds of constraints concerning class,
field and association. These constraints appear frequently in real-world domain models [34,
48, 49, 57]. We describe these constraints below:
1. Class Payment is immutable, i.e. all objects of this class are immutable.
2. Field Student.name is mutable, i.e. its value can be changed.
3. Student.name is not optional, i.e. its value must be specified for each object.
4. Student.name does not exceed 30 characters in length.
5. Student.name is not unique, i.e. its value may duplicate among objects.
6. Student.id is an id field.
7. Student.id is auto, i.e. its value is automatically generated.
8. The minimum value of CourseModule.semester is 1.
9. The maximum value of CourseModule.semester is 8.
10. The association constraint, e.g. with respect to the enrols-in association, a Student is
enrolled in zero or no more than 30 CourseModules, and a CourseModule is enrolled
in by zero or more Students.
11. The minimum value of CourseModule.semester in ElectiveModule is 3.
These constraints are primitive in the sense that they are applied independently to a single
model element (e.g. class Student and Student.id). The key design questions concerning
these constraints are: (i) are they essential to real-world domain models? and (ii) how do we
represent these constraints in the domain model using an aDSL?
5

Essential Behaviour Types
When we consider constraints in designing the domain model, we are effectively constraining
the state space of each domain class in the model. For this state space, two orthogonal design
questions that can be raised are: (i) what are the essential types of behaviour that operate on
a constrained state space? and (ii) how do we specify the behaviour types directly in each
domain class, in such a way that can help capture the relationship with the state space?
Let us take class Student in Figure 1.1 as an example. Given the constrained state
space that is structured around the class and its two attributes (id and name), what are the
essential operations that must be defined for this class? More specifically, is the constructor
Student(Student, String) shown in the figure sufficient for creating Student objects that
the software needs? What are the basis for defining the other three operations of the class,
namely getId, setName and getName? Are there any other essential operations that we need
to add to this class?
Regarding to modelling the behaviour type, how do we specify the behaviours of, say, the
constructor Student(Student, String) and the operations setName and getName so that
they make explicit the connections to the attribute Student.name? Clearly, such connections
help validate the essentiality of the behaviours, while making the design of Student easier
to comprehend.
Software Construction from the Domain Model
Software construction from the domain model requires this model to essentially support
both structural and behavioural modelling elements. UML [57] includes three behavioural
modelling languages: state machine and interaction and activity diagrams. The first challenge
is how to factor in the domain model the behavioural modelling structure (e.g. activity class
and activity graph structure of an activity)? For the CourseMan example in Figure 1.1, for
instance, how do we define the activity class EnrolmentMgmt and the activity graph structure
of the concerned activity? This would cover the area labelled ‘?’ in the figure.
Another challenge with software construction is what software architecture can be suitable
and how to use it to effectively construct software from the domain model? This challenge
needs to be addressed in the context of a well-accepted fact that software construction can
not be fully automated [26]. The generally accepted position is that a GUI-based tool is

employed to assist the development team in the construction process.
6