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:
࿿࿿࿿H࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿I࿿ಾ࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿J࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿K࿿⚠࿿࿿࿿࿿࿿࿿࿿࿿࿿L࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿
M࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿N࿿მ࿿࿿࿿࿿࿿࿿࿿࿿࿿O࿿‫ڗ‬࿿࿿࿿࿿࿿࿿࿿࿿࿿P࿿ۖ
Q࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿
R࿿࿿࿿࿿61Z࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿[࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿\࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿]࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿^࿿࿿
࿿࿿࿿࿿࿿࿿࿿࿿࿿_࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿`࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿a࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿b⡰࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿c࿿࿿
࿿࿿࿿࿿࿿࿿࿿࿿࿿d⢊࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿e࿿ۖ
f࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿g࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿h࿿࿿
࿿࿿࿿࿿࿿࿿࿿࿿࿿i࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿j࿿࿿
࿿࿿࿿࿿࿿࿿࿿࿿࿿k࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿l
Assoc. Prof.,
Dr. Nguyen Viet Ha


H࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿I࿿ಾ࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿J࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿K࿿⚠࿿࿿࿿࿿࿿࿿࿿࿿࿿L࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿
M࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿N࿿მ࿿࿿࿿࿿࿿࿿࿿࿿࿿O࿿‫ڗ‬࿿࿿࿿࿿࿿࿿࿿࿿࿿P࿿ۖQ࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿R࿿࿿࿿࿿
62Z࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿[࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿\࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿]࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿^࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿
_࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿`࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿a࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿b⡰࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿c࿿࿿
࿿࿿࿿࿿࿿࿿࿿࿿࿿
d⢊࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿e࿿ۖf࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿g࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿h࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿i࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿

j࿿࿿
࿿࿿࿿࿿࿿࿿࿿࿿࿿k࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿࿿l
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 lan-guage and evaluate the effectiveness of using MCCL in modulebased 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 e ffectively 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

23 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
List of Figures

v
vii

List of Tables

ix

1 Introduction

1

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 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

3
3
5
7
7

8
12
13
13
13
15
17
22
27
28
29
33


2.2 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 . . . . . . . . . . . . . . . .
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Unified Domain Modelling with aDSL

35
36
36
40
41
45
46

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Module-Based Software Construction with aDSL

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

72
73
76
87
88

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

88
89
90
91
92
92
94


4.3 Module Configuration Domain . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 One Master Module Configuration . . . . . . . . . . . . . . . . . .
4.3.2 The ‘Configured’ Containment Tree . . . . . . . . . . . . . . . . .
4.3.3 Customising Descendant Module Configuration . . . . . . . . . . .
4.4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 MCC Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1 Structural Consistency between MCC and Domain Class . . . . . .
4.5.2 MCCGEN Algorithm . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 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


5.4.2 M P1
5.4.3 M P2
5.4.4
5.4.5

: Total Generativity . . . . . . . . . . . . . . . . . . . . . . . 137
–MP4.............................. 138
Analysis of MCCGen . . . . . . . . . . . . . . . . . . . . . . . . 143
Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 Conclusion

144
145

6.1 Key Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bibliography

146
147
150

Appendices
A Helper OCL Functions for DCSL’s ASM

158

B MCCL Specification

164

B.1 Library Rules of the MCCL’s ASM . . . . . . . . . . . . . . . . . . . . .
B.2 Two MCCs of ModuleEnrolmentMgmt . . . . . . . . . . . . . . . . . . . .
C DCSL Evaluation Data

164
167
171

C.1 Expressiveness Comparison Between DCSL and the DDD Frameworks . . 171
C.2 Level of Coding Comparison Between DCSL and the DDD Frameworks . . 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 A partial domain model of CourseMan. . . . . . . . . . . . . . . . . . . .
3
1.2 An overview of DDDAL (with an emphasis on phases 1 and 2). . . . . . . . 9
2.1 The essential ASM of UML (synthesised from seven meta-models of UML [57]). 18
2.2 The OCL expression meta-model (Adapted from §8.3 [56]). . . . . . . . . 20
2.3 A UI class of the domain class Student (Source: [45]). . . . . . . . . . . .
28
2.4 The UML-based ASM of OOPL. . . . . . . . . . . . . . . . . . . . . . . .
2.5 The meta-model of UML activity modelling language (Adapted from §15.2.2
of the UML specification [57]). . . . . . . . . . . . . . . . . . . . . . . . .
2.6 The UML activity models of five basic variants of the CourseMan’s enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 The MOSA model of CourseMan. . . . . . . . . . . . . . . . . . . . . .
2.8 A ModuleEnrolmentMgmt’s view containing a child ModuleStudent’s view.

30

3.1 The abstract syntax model of DCSL. . . . . . . . . . . . . . . . . . . . . .

50

3.2 A DCSL model for a part of the CourseMan domain model. . . . . . . . .
3.3 (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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4 The sequential pattern form (top left) and an application to the enrolment
management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 The sequential pattern form view of enrolment management activity. . . . .
3.6 The decisional pattern form (top left) and an application to the enrolment
management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 The decisional pattern form view of enrolment management activity. . . . .

55

vii

38
39
43
44

75
77
78
79
80


3.8 The forked pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 The forked pattern form view of enrolment management activity. . . . . . .
3.10 The joined pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11 The joined pattern form view of enrolment management activity. . . . . . .
3.12 The merged pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.13 The merged pattern form view of enrolment management activity. . . . . .
4.1 A detailed view of DDDAL’s phase 2 with software module construction. .

4.2 An abstract UML-based software model: (core layer) domain model, (middle
layer) module and (top layer) software. . . . . . . . . . . . . . . . . . . . .
4.3 The GUI of CourseMan software prototype generated by jDomainApp: (1)
main window, (2-4) the UDM’s GUI for EnrolmentMgmt, Student, and

81
82
83
84
85
86
89

90

Enrolment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
4.4 The CM of MCCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
4.5 (A-shaded area) The transformed CM (CM T ); (B-remainder) Detailed design of the105
4.6 key classes of CMT .
109
The annotation-based ASM. . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 The view of a (stand-alone) ModuleStudent object. . . . . . . . . . . . . .
111
4.8 The customised view of ModuleEnrolmentMgmt (as configured in Listing 4.2).113
5.1 A partial CourseMan’s GUI that is generated by DomainAppTool. . . . . 121
5.2 ProcessMan’s domain model. . . . . . . . . . . . . . . . . . . . . . . . .
5.3 A partial MCC Model for process structure. . . . . . . . . . . . . . . . . .
5.4 The view of ModuleEnrolmentMgmt of the software in Figure 5.1. . . . . .

124
125
138

5.5 An example CourseMan software that has substantially been customised. .
A.1 Utility class ExprTk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

141
158

A.2 Utility class Tk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

160

viii


List of Tables
2.1 Meta-mapping between OOPL and UML/OCL . . . . . . . . . . . . . . .
3.1 The essential state space constraints . . . . . . . . . . . . . . . . . . . . .
3.2
3.3
3.4
3.5
3.6
3.7
4.1

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 . . . . . . .
Mapping from CM to CMT . . . . . . . . . . . . . . . . . . . . . . . . . .

33
48
49
59
60
63
67
72
107

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

132
133
135
140

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

171

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

173
174

ix

130


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
devel-opment (GSD). The key benefits of MDSE are to significantly improve reusability
and pro-ductivity in producing software for di fferent 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 metaattributes 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-of-learning.
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 o fficer 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:
23Class Payment is immutable, i.e. all objects of this class are immutable.
24Field Student.name is mutable, i.e. its value can be changed.
25Student.name is not optional, i.e. its value must be specified for each object.
26Student.name does not exceed 30 characters in length.
27Student.name is not unique, i.e. its value may duplicate among objects.
28Student.id is an id field.
29Student.id is auto, i.e. its value is automatically generated.
30The minimum value of CourseModule.semester is 1.
31The maximum value of CourseModule.semester is 8.
32 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.
33 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