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
- Xem thêm -