A unified view approach to software development automation

First, we propose an aDSL, named domain class specification language DCSL, whichconsists in a set of annotations that express the essential structural constraints and the essentialbehavi

Hanoi - 2020

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

ĐẠ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

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

ĐẠ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

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 DucHanh, at the Faculty of Information Technology, University of Engineering andTechnology, Vietnam National University, Hanoi All the research data and resultspresented in this dissertation are authentic and (to the best of my knowledge) have notpreviously been published in any academic publications by other authors

Le Minh Duc

An important software engineering methodology that has emerged over the past twentyyears is model-based software development At the heart of this methodology lies twocomplementary methods: model-driven software engineering (MDSE) and domain-drivendesign (DDD) While the aim of MDSE is ambitiously broad, DDD’s goal is more modestand direct but not less important – to apply model-based engineering techniques to tacklethe complexity inherent in the domain requirements The state-of-the-art DDD methodincludes a set of principles for constructing a domain model that is feasible forimplementation in a target programming language However, this method lacks thesolutions 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 byusing annotation-based domain-specific language (aDSL), which is internal to OOPL, to notonly express an essential and unified domain model but generatively construct modularsoftware from this model

First, we propose an aDSL, named domain class specification language (DCSL), whichconsists in a set of annotations that express the essential structural constraints and the essentialbehaviour of a domain class We carefully select the design features from a number ofauthoritative software and system engineering resources and reason that they form a minimumdesign space of the domain class

Second, we propose a unified domain (UD) modelling approach, which uses DCSL toexpress both the structural and behavioural modelling elements We choose UML activitydiagram language for behavioural modelling and discuss how the domain-specificconstructs of this language are expressed in DCSL To demonstrate the applicability of theapproach we define the UD modelling patterns for tackling the design problems posed byfive core UML activity flows

Third, we propose a 4-property characterisation for the software that are constructeddirectly from the domain model These properties are defined based on a conceptuallayered software model that includes the domain model at the core, an intermediate modulelayer 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-basedsoftware architecture An MCC provides an explicit class-based definition of a set ofmodule con- figurations of a given class of software modules The MCCs can easily bereused to create different variants of the same module class, without having to change themodule class design Fifth, we develop a set of software tools for DCSL, MCCL and thegenerators associated with these aDSLs We implement these tools as components in a

software framework, namedjDoMaInApp, which we have developed in our research

To evaluate the contributions, we first demonstrate the practicality of our method byapplying it to a relatively complex, real-world software construction case study, concerningorganisational process management We then evaluate DCSL as a design specification lan-guage and evaluate the effectiveness of using MCCL in module-based softwareconstruction We focus the latter evaluation on module generativity

We contend that our contributions help make the DDD method more concrete and morecomplete for software development On the one hand, the method becomes more concretewith solutions that help effectively apply the method in OOPL platforms On the otherhand, the method is more complete with solutions for the design aspects that were notoriginally included

Tóm tat

Trong vòng hai th p ký gan đây, phương pháp lu n phát trien phan mem dụa trên mô hình noi lên là m t phương pháp lu n quan trong trong kỹ ngh phan mem Ő trung tâm của phương pháp lu n này có hai phương pháp có tính bo tro nhau là: kỹ ngh phan mem hưóng mô hình (model-driven software engineering (MDSE)) và thiet ke hưóng mien (domain-driven design (DDD)) Trong khi MDSE mang m t mục tiêu

r ng và khá tham vong thì mục tiêu của DDD lại khiêm ton và thục te 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 đe giải quyet sụ phức tạp von có trong yêu cau mien Phương pháp DDD hi n tại bao gom m t t p các nguyên lý đe xây dụng m t mô hình mien ỏ dạng khả thi cho trien khai viet mã trên m t ngôn ngữ l p trình đích Tuy nhiên phương pháp này còn thieu các giải pháp can thiet giúp giải đáp hai câu hỏi quan trong mà ngưòi phát trien phan mem thưòng g p phải khi áp dụng DDD vào các nen tảng ngôn ngữ l p

trình hưóng đoi tưong (object oriented programming language (OOPL)): (i)

những thành phan nào cau tạo nên m t mô hình mien có mức đ dien đạt thiet yeu?

và (ii) xây dụng m t cách hi u quả phan mem từ mô hình mien như the nào? Lu n

án này đ t mục đích khac phục hạn che trên của DDD bang cách sử dụng ngôn ngữ chuyên bi t mien dụa trên ghi chú (annotation-based domain-specific language (aDSL)), đưoc phát trien trong OOPL, đe không chỉ bieu dien m t mô hình mien hop nhat thiet yeu mà còn đe xây dụng phan mem có tính mô-đun từ mô hình mien này.

Thứ nhat, lu n án đe xuat m t aDSL, tên là ngôn ngữ đ c tả lóp mien (domain class specification language (DCSL)), bao gom m t t p các ghi chú đe bieu dien các ràng bu c cau trúc thiet yeu và các hành vi thiet yeu của lóp mien Tác giả đã can th n lụa chon các đ c trưng thiet ke từ m t so nguon tài li u hoc

kỹ ngh phan mem và kỹ ngh h thong và l p lu n rang các đ c trưng này tạo thành

m t không gian thiet ke toi giản cho lóp mien.

Thứ hai, lu n án đe xuat m t phương thức tiep c n mô hình hóa mien hop nhat, trong đó sử dụng DCSL đe bieu dien các thành phan mô hình hóa cau trúc và hành

vi Lu n án đã chon ngôn ngữ bieu đo hoạt đ ng UML cho mô hình hóa hành vi và trình bày cách bieu dien các đ c trưng chuyên bi t trạng thái của ngôn ngữ này bang DCSL Đe chứng tỏ tính thục tien của cách tiep c n, lu n án định nghĩa m t t

p mȁu mô hình hóa mien hop nhat cho các bài toán thiet ke liên quan trục tiep đen năm luong hoạt đ ng UML cơ bản.

Thứ ba, lu n án đe xuat m t mô tả đ c điem gom bon tính chat cho phan mem đưoc xây dụng trục tiep từ mô hình mien Bon tính chat này đưoc định nghĩa dụa trên

mô hình khái ni m phan mem dạng phân lóp, bao gom mô hình mien ỏ lóp lõi, m

t lóp mô-đun trục tiep bao quanh lóp lõi và m t lóp phan mem ỏ ngoài.

Thứ tư, lu n án đe xuat m t aDSL thứ hai, tên là ngôn ngữ lóp cau hình mô-đun (module configuration class language (MCCL)), dùng đe thiet ke các lóp cau hình mô-đun (module configuration classes (MCCs)) trong m t kien trúc phan mem dụa trên mô-đun Mői MCC cung cap m t định nghĩa dạng lóp cho m t t p các cau hình mô-đun của m t lóp mô-đun Các MCC có the de dàng sử dụng lại đe tạo ra các bien the của m t lóp mô-đun mà không can sửa thiet ke bên trong của mô- đun.

Thứ năm, lu n án phát trien 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 phan của m t phan mem khung, tên là JDOMAINAPP Đe đánh giá các ket quả trên, lu n án trưóc het trình dien tính thục tien của phương pháp bang cách áp dụng vào m t trưòng hop nghiên cứu tương đoi phức tạp ve phát trien phan mem, liên quan đen quản lý quy trình to chức Tiep 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 phan mem m t cách tụ đ

ng Chúng tôi cho rang, các đóng góp của lu n án giúp phương pháp DDD trỏ nên

cụ the và đay đủ hơn M t m t, phương pháp trỏ nên cụ the 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 nen tảng OOPL M t khác, phương pháp trỏ nên đay đủ hơn vói các giải pháp cho các khía cạnh thiet ke chưa đưoc xem

I am deeply grateful for my home university (Hanoi University) for providing the PhDstudentship and a gracious teaching arrangement, that has enabled me to have the time tocomplete the required course works and research I am also very grateful for the financialsupport that I have additionally received from the MOET’s 911 fund and the NAFOSTEDproject (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 manymeaningful and entertaining discussions Last but not least, I wish to thank my family forthe sacrifices that they have made and for all the love and encouragement that they havegiven me during my PhD study

1.1 Problem Statement 3

1.1.1 Motivating Example 3

1.1.2 Domain-Driven Design Challenges 5

1.1.3 Research Statement 7

1.2 Research Aim and Objectives 7

1.3 Research Approach 8

1.4 Dissertation Structure 12

2 State of the Art 13 2.1 Background 13

2.1.1 Model-Driven Software Engineering 13

2.1.2 Domain-Specific Language 15

2.1.3 Meta-Modelling with UML/OCL 17

2.1.4 Domain-Driven Design 22

2.1.5 Model-View-Controller Architecture 27

2.1.6 Comparing and Integrating MDSE with DDD 28

2.1.7 A Core Meta-Model of Object-Oriented Programming Language 29 2.1.8 Using Annotation in MBSD 33

2.2 Domain-Driven Software Development with aDSL 35

2.2.1 DDD with aDSL 36

2.2.2 Behavioural Modelling with UML Activity Diagram 36

2.2.3 Software Module Design 40

2.2.4 Module-Based Software Architecture 41

2.3 Summary 45

3 Unified Domain Modelling with aDSL 46 3.1 Introduction 46

3.2 DCSL Domain 47

3.2.1 Essential State Space Constraints 47

3.2.2 Essential Behaviour Types 48

3.3 DCSL Syntax 49

3.3.1 Expressing the Pre- and Post-conditions of Method 56

3.3.2 Domain Terms 57

3.4 Static Semantics of DCSL 57

3.4.1 State Space Semantics 58

3.4.2 Behaviour Space Semantics 64

3.4.3 Behaviour Generation for DCSL Model 68

3.5 Dynamic Semantics of DCSL 71

3.6 Unified Domain Model 72

3.6.1 Expressing UDM in DCSL 73

3.6.2 UD Modelling Patterns 76

3.7 Summary 87

4 Module-Based Software Construction with aDSL 88 4.1 Introduction 88

4.2 Software Characterisation 89

4.2.1 An Abstract Software Model 90

4.2.2 Instance-based GUI 91

4.2.3 Model reflectivity 92

4.2.4 Modularity 92

4.2.5 Generativity 94

4.3 Module Configuration Domain 95

4.3.1 One Master Module Configuration 95

4.3.2 The ‘Configured’ Containment Tree 95

4.3.3 Customising Descendant Module Configuration 96

4.4 MCCL Language Specification 97

4.4.1 Specification Approach 97

4.4.2 Conceptual Model 98

4.4.3 Abstract Syntax 104

4.4.4 Concrete Syntax 110

4.4.5 Semantics 114

4.5 MCC Generation 114

4.5.1 Structural Consistency between MCC and Domain Class 114

4.5.2 MCCGEN Algorithm 116

4.6 Summary 118

5 Evaluation 119 5.1 Implementation 119

5.1.1 UD Modelling 119

5.1.2 Module-Based Software Construction 121

5.2 Case Study: PRocEssMan 122

5.2.1 Method 122

5.2.2 Case and Subject Selection 122

5.2.3 Data Collection and Analysis 123

5.2.4 Results 123

5.3 DCSL Evaluation 127

5.3.1 Evaluation Approach 127

5.3.2 Expressiveness 129

5.3.3 Required Coding Level 132

5.3.4 Behaviour Generation 133

5.3.5 Performance Analysis 134

5.3.6 Discussion 134

5.4 Evaluation of Module-Based Software Construction 135

5.4.1 Module Generativity Framework 135

5.4.2 MP1: Total Generativity 137

5.4.3 MP2–MP4 138

5.4.4 Analysis of MCCGEn 143

5.4.5 Discussion 144

5.5 Summary 144

6 Conclusion 145 6.1 Key Contributions 146

6.2 Future Work 147

Bibliography 150 Appendices A Helper OCL Functions for DCSL’s ASM 158 B MCCL Specification 164 B.1 Library Rules of the MCCL’s ASM 164

B.2 Two MCCs of ModuleEnrolmentMgmt 167

C DCSL Evaluation Data 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

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 35CSM Concrete Syntax Meta-model, page 17

DCSL Domain Class Specification Language, page 51DDD 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 99MDA Model-Driven Architecture, page 13

MDD Model-Driven Development, page 13

MDE Model-Driven Engineering, page 13

MDSE Model-Driven Software Engineering, page 13

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

List of Figures

1.1 A partial domain model of CoURsEMan 3

2.3 A UI class of the domain class Student (Source: [45]) 28

2.4 The UML-based ASM of OOPL 30

2.5 The meta-model of UML activity modelling language (Adapted from §15.2.2

of the UML specification [57]) 38

enrol-ment manageenrol-ment activity 39

2.7 The MOSA model of CoURsEMan 43

2.8 A ModuleEnrolmentMgmt’s view containing a child ModuleStudent’s view

44

3.1 The abstract syntax model of DCSL 50

3.2 A DCSL model for a part of the CoURsEMan domain model 55

variant that handles the enrolment management activity; (B: Right) The

UDM that results 75

3.4 The sequential pattern form (top left) and an application to the enrolment

management activity 77

3.6 The decisional pattern form (top left) and an application to the enrolment

management activity 79

3.8 The forked pattern form (top left) and an application to the enrolment man-

agement activity 81

3.9 The forked pattern form view of enrolment management activity 82

3.10 The joined pattern form (top left) and an application to the enrolment man- agement activity 83

3.11 The joined pattern form view of enrolment management activity 84

3.12 The merged pattern form (top left) and an application to the enrolment man- agement activity 85

3.13 The merged pattern form view of enrolment management activity 86

4.1 A detailed view of DDDAL’s phase 2 with software module construction 89

4.2 An abstract UML-based software model: (core layer) domain model, (middle layer) module and (top layer) software 90

4.3 The GUI of CoURsEMan software prototype generated by jDoMaInApp: (1) main window, (2-4) the UDM’s GUI for EnrolmentMgmt, Student, and Enrolment 91

4.4 The CM of MCCL 98

4.5 (A-shaded area) The transformed CM (CMT ); (B-remainder) Detailed design of the105 key classes of CMT 4.6 The annotation-based ASM 109

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 124

5.3 A partial MCC Model for process structure 125

5.4 The view of ModuleEnrolmentMgmt of the software in Figure 5.1 138

5.5 An example CoURsEMan software that has substantially been customised 141

A.1 Utility class ExprTk 158

A.2 Utility class Tk 160

List of Tables

2.1 Meta-mapping between OOPL and UML/OCL 33

3.1 The essential state space constraints 48

3.2 The essential behaviour types 49

3.3 Well-formedness constraints of DCSL 59

3.4 The boolean state space constraints of DCSL 60

3.5 The non-boolean state space constraints of DCSL 63

3.6 The core structural mapping rules 67

3.7 Translating Domain Field properties into JML’s class invariants 72

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

5.3 (A-left) Summary of max-locs for DCSL, AL and XL; (B-right) Summary of typical-locs for DCSL, AL and XL 132

5.4 BSpacEGEn for CoURsEMan 133

5.5 Module pattern classification 135

5.6 Module generativity values of two CoURsEMan’s modules in MP2–MP4 140

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

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

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

Chapter 1

Introduction

There is no doubt that an important software engineering research area over the last twodecades 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 problemsolving and improved quality, productivity and reusability Perhaps a most visible andnovel software engineering development that falls under the MBSD umbrella is model-driven software engineering (MDSE) [9 16, 38, 67] Another more modest and directdevelopment

method is domain-driven design (DDD) [22, 62, 75]

Very early on, Czarnecki [16] stated that MDSE is a type of generative software opment (GSD) The key benefits of MDSE are to significantly improve reusability and pro-ductivity in producing software for different implementation platforms These are basicallyachieved by constructing the high-level (platform-independent) software models before-hand and then very efficiently, typically with the help of proven automated techniques andtools, applying these models to a new platform to generate the software for it Thisapplication step makes extensive use of reusable assets, including software frameworks,components, architectures and models [16]

devel-While the MDSE’s goal is ambitiously broad and encompassing, DDD [22] focusesmore specifically on the problem of how to effectively use models to tackle the complexityinherent in the domain requirements DDD’s goal is to develop software based on domainmodels that not only truly describe the domain but are technically feasible for implementation.According to Evans [22], object-oriented programming language (OOPL) is especially suitedfor use with DDD This is not surprising, given that Booch [8] had ealier pointed out two

main reasons why OOPL would result in domain models that are inherently expressive andfeasible 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 basicconstruct of high-level analysis and design modelling languages that are used toconceptualise 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 languageengineering community as domain-specific language (DSL) [74] The aim of DSL is toexpress the domain using concepts that are familiar to the domain experts A keyrequirement in DSL engineering is to enable the domain experts and the technical team tofocus on building the domain model, not having to worry about the technicality oflanguage 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 inattribute-oriented programming (AtOP) [12, 13] to express meta-attributes and inbehaviour 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 aseparate syntax specification This helps significantly reduce development cost andincrease ease-of- learning

In fact, simple forms of aDSL have been used quite extensively in both DDD andMDSE communities In DDD, annotation-based extensions of OOPLs have been used todevelop software frameworks (e.g [17, 60]) that support the development of not only thedomain model but the final software The design rules in these models are expressed by aset of annotations In MDSE, annotation sets are used to construct platform-specificmodels 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 architecturalmodel [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 problemconcerning the DDD method for object-oriented software

1.1 Problem Statement

In this section, we will discuss the key challenges facing DDD for the object-oriented problemdomains and define a research statement that is tackled in this disseration We motivate ourdiscussion using a software example, which we will also use throughout the dissertation toillustrate 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 behaviouralaspects Figure 1.1 shows a partially completed CoURsEMan domain model expressed inthe form of a UML class diagram [57] Notationwise, in this dissertation, when it is

necessary

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 fordomain-specific and technical concepts

The bottom part of Figure 1.1 shows four classes and two association classes of

CoURsE- Man Class Student represents the domain concept Student, who registers tostudy 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 capturesdetails about the many-many association between Student and SClass Finally,association class Enrolment captures details about the many-many association betweenStudent 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 calledenrolment 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 theactivity 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 tomake

– Authorisation: captures data about the decision made by an enrolment officercon- cerning whether or not to allow a student to undertake the registered coursemodules

– EnrolmentApproval: captures data about the decision made by the enrolmentofficer concerning a student’s enrolment

– EnrolmentMgmt: represents the enrolment management activity This activityinvolves registering Students, enrolling them into CourseModules andregistering them into SClasses In addition, it allows each Student to raise aHelpRequest

1 we use class/concept name as countable noun to identify instances.

1.1.2 Domain-Driven Design Challenges

Let us now outline the key challenges facing domain modelling in DDD and softwaredevel- opment from the domain model Understanding these challenges leads us toformulate 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 asingle 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?

Essential Behaviour Types

When we consider constraints in designing the domain model, we are effectively constrainingthe 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 thestate space?

Let us take class Student in Figure 1.1 as an example Given the constrained statespace 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 creatingStudent objects that the software needs? What are the basis for defining the other threeoperations of the class, namely getId, setName and getName? Are there any otheressential 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 thedesign of Student easier to comprehend

Software Construction from the Domain Model

Software construction from the domain model requires this model to essentially supportboth structural and behavioural modelling elements UML [57] includes three behaviouralmodelling 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 activityclass 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 activitygraph structure of the concerned activity? This would cover the area labelled ‘?’ in thefigure

Another challenge with software construction is what software architecture can be suitableand how to use it to effectively construct software from the domain model? This challengeneeds to be addressed in the context of a well-accepted fact that software construction cannot be fully automated [26] The generally accepted position is that a GUI-based tool isemployed to assist the development team in the construction process

The constructed software plays two important roles First, it is used during domainmodel development to enable the development team to iteratively and interactively buildthe domain model As discussed in [22], this phase is central to DDD For the CoURsEManexample, for instance, the software would need to present a GUI that truly reflects thedomain model structure Further, it should support partially completed models, such asthe one shown in Figure 1.1, and should evolve with the model as it is updated through thedevelopment iterations.

Second, the software is reused during production software development to quickly developthe production-quality software For instance, the production-quality CoURsEMan softwarewould be constructed not only from the finalised domain model but from the softwarecomponents (e.g architectural components, view layouts and view fields) that were usedduring the development of the domain model

1.1.3 Research Statement

DDD is a design method that tackles the complexity that lies at the heart of software velopment However, in the context of the challenges presented above, we argue that thereare still important open issues concerning the object-oriented problem domains that need

de-to be addressed These issues fall inde-to two main areas: domain modelling and softwaredevelopment from the domain model First, the domain model does not define the essentialstructural elements and lacks support for behavioural modelling Second, there has been

no formal study of how aDSL is used in DDD This is despite the fact that annotation isbeing used quite extensively in implementations of the method in the existing DDDsoftware frameworks Third, there has been no formal study of how to construct softwarefrom the domain model In particular, such a study should investigate generativetechniques (similar to those employed in MDSE) that are used to automate softwareconstruction

1.2 Research Aim and Objectives

In this dissertation, we aim to address the issues mentioned in the research statement above

by formally using aDSL to not only construct an essential and unified domain model butgeneratively construct modular software from this model We claim that attaining this aimwould help make the DDD method not only more concrete but more complete for object-

oriented software development purposes On the one hand, the method would becomemore concrete with specific solutions that help the technical team effectively apply themethod in the OOPL platforms On the other hand, the method would become morecomplete with solutions for the design aspects that were not originally included Weorganise our research with the following objectives:

1 To investigate and design a unified domain model that includes the essential

elements for both the structural and behavioural modelling aspects

2 To investigate and characterise the software that is constructed from the domain model.This should include properties that are specific to software construction with DDD

3 To investigate and define a generative and modular software construction approach

4 To investigate and design suitable aDSL(s) for the unified domain model and forsoftware construction

5 To implement a support tool, which includes the aDSL(s) and their generators

1.3 Research Approach

We take the view that software is a system and apply the system approach [14, 19] to bothengineer the software and to tackle the stated research problem Churchman [14]generically defines system as “ a set of parts coordinated to accomplish a set of goals”.This definition means that system refers to both object and abstract construct of the humanmind [19]

First, to engineer complex software requires a software engineering approach, which,according to Dekkers [19], is a type of system engineering approach A complex software

is one whose behaviour and interaction between the software components are initially notwell-defined A main characteristic of the system engineering approach for such software

is that it is broken down into stages, which are performed in a disciplined manner to buildthe system We adapt the iterative software engineering method [43, 70] to define anenhanced DDD method, shown in Figure 1.2 and which we call DDD with aDSLs (DDDAL).

In principle, DDDAL consists of three phases that are performed in sequence and eratively All three phases are supported by a software framework named jDoMaInApp 2

it-2 paper 5 listed in the Publications section.

Figure 1.2: An overview of DDDAL (with an emphasis on phases 1 and 2).

Phases 1 and 2 are the two key phases of the method and are depicted in Figure 1.2 with

more details The elements that are drawn using dashed lines in the figure are not within

the research scope of this dissertation Conceptually, phase 1 takes as input the (typicallyincomplete) structural and behavioural requirements from the domain experts and produce

as output a domain model, called UDM The purpose of phase 2 is to generate a softwareprototype that reflects the domain model in such a way that the project team can, in phase

3, intuitively review the model, the software and the associated requirements Thesubsequent iterations repeat at phase 1 with an update on the domain model The process isstopped when the domain model satisfies the requirements From here, it is used to developthe production software The generated software prototype is reusable for thisdevelopment

Consequently, our research approach in this dissertation is a system meta-approach, whoseaim is to define a subset of elements for the first two phases of DDDAL We consider thesetwo phases as two sub-problems of our research problem (defined in Section 1.1), whichare tackled by carrying out the research objectives (defined in the previous section) Wewill discuss in more detail below our research approach for tackling these two sub-problems

Sub-Problem 1: Unified Domain Modelling with aDSL

This sub-problem is tackled by performing the research objectives 1 4 and 5 We conduct

a literature survey on the essential structural and behavioural features of the domain classand apply modelling and abstraction [19] to construct a unified domain model (UDM) that incorporates both types of features We call the process for constructing UDM UD

modelling In the spirit of DDD, we encourage but do not force the use of any

high-level modelling languages for expressing the input requirement sets In our method, thedesigner works closely with the domain expert to map the input requirements, togetherwith any accompanied high-level models, to the UDM and expresses this UDM in anaDSL This collaboration is performed iteratively with the help of a GUI-based softwareprototype that is constructed directly from the UDM We design the structural aspect of theUDM using UML class diagram and the behavioural aspect using UML activity diagram

We choose UML activity diagram because it has long been demonstrated to be expert- friendly [20] and that it is tightly linked to the other two UML behaviouraldiagrams (state machine and interaction diagram [57]) To express UDM, we propose an

domain-aDSL named Domain Class Specification Language (DCSL) We apply modelling to specify

DCSL and implement this language as part of the jDoMaInApp framework We evaluateDCSL in terms of expressiveness, required coding level and constructibility

Sub-Problem 2: Module-Based Software Construction with aDSL

This sub-problem is addressed by performing the objectives 2, 3, 4 and 5 It consists of

two smaller problems: (2.a) to construct the software modules from the UDM and (2.b)

to construct software from these modules We perform a literature survey on DDD, DDDframeworks and software design properties We then characterise a software in terms of

four essential properties We focus primarily on tackling problem (2.a) We conduct a

literature survey on modular software development and adopt a module-based softwarearchitecture to explicitly model software in terms of a set of modules Software modules areinstantiated from module classes The core component of each module class is a domain class

To automatically construct the module class, we focus on the module configurations and

capture their design in a module configuration class (MCC) We then apply modelling and abstraction to specify an aDSL, named Module Configuration Class Language (MCCL),

to express the MCCs We implement MCCL as a component of the jDoMaInApp

software construction with MCCL.

The jDoMaInApp framework has an implementation for the sub-problem (2.b)

However, we do not discuss sub-problem (2.b) in detail in this dissertation.

Contributions

We summarise below five main contributions of our dissertation that concern the two problems presented above As the contributions will show, the term “unified view” in thedissertation’s title refers to our aDSL-centric view of automated software construction

sub-from the domain model: (i) domain model is expressed using an aDSL, named DCSL; (ii)

software module construction is automated by using another aDSL, named MCCL

Unified domain modelling with aDSL:

© Domain Class Specification Language (DCSL): an aDSL for designing domain

class in the domain model It consists in a set of annotations that express the essentialstructural constraints and essential behaviour of domain class

A unified domain modelling approach: uses DCSL to construct a unified domain

model that incorporates state-specific modelling elements of UML activity diagram

Module-based software construction with aDSL:

© A 4-property software characterisation: to provide a structured guidance for the

construction of software from the domain model

№ Module Configuration Class Language (MCCL): an aDSL for designing the

config-uration classes for software modules Each of these classes serves as a template forcreating the configurations of a module class

③ Tool support: to evaluate the aforementioned contributions and to ease the adoption of our

overall DDDAL method in real-world software projects, we implement DCSL, MCCL andthe associated generators as components in the jDoMaInApp software framework

1.4 Dissertation Structure

This dissertation is organised into 6 chapters that closely reflect the stated contributions InChapter 2, we systematically present the background knowledge concerning the concepts,methods, techniques and tools that are most relavant to the research problem and necessary forexplaining our contributions in the rest of this dissertation We also highlight thelimitations of the existing DDD method and the works concerning the use of aDSL withMDSE and DDD

In Chapter 3, we describe our contributions concerning UD modelling Taking the viewthat domain class design is the basis for UDM construction, we first specify DCSL forexpressing the essential structural and behavioural features of the domain class We thenuse DCSL to define UDM After that, we present a set of generic UD modelling patternsthat can be applied to construct UDMs for real-world domains

In Chapter 4, we explain our contributions concerning module-based softwareconstruc- tion We first set the software construction context by defining a softwarecharacterisation scheme We then specify MCCL for expressing the MCCs and present agenerator for generating the MCCs

In Chapter 5, we present an evaluation of our contributions We first describe an mentation of the research contributions as components in the jDoMaInApp framework Wethen describe a real-world software development case study which we have developedusing the implemented components After that, we present two evaluations: one is forDCSL and the other is for module-based software construction

imple-In Chapter 6, we conclude the dissertation with a summary of the research problem, thecontributions that we made and the impacts that these have on advancing the DDD method

We also highlight a number of ideas and directions for future research in this area

Chapter 2

State of the Art

In this chapter, we present a methodological study of the literatures that are relevant to thisdissertation We have two main objectives The first objective is to gather authoritativeguidance for and to define the relevant foundational concepts, methods, and techniques.The second objective is to identify significant, unresolved issues that can be addressed inour research In particular, we highlight the limitations of the existing DDD method andthe works concerning the use of aDSL with MDSE and DDD

2.1 Background

We begin in this section with a review of the relevant background concepts, methods andtechniques concerning MDSE, DDD and OOPL In particular, we highlight the role ofaDSL (which is derived from OOPL) as the underlying theme that connects MDSE andDDD

2.1.1 Model-Driven Software Engineering

Historically, model-driven software engineering (MDSE) evolves from a general system engineering method called model-driven engineering (MDE) MDE in turn was invented

on the basis of model-driven architecture (MDA) [55] Early works, especially by Kent

et al [38] and Schmidt [67], use the term MDE A recent book by Brambilla et al [9]defines MDSE as a more specialised term In particular, they relate MDSE to a form ofMDE and highlights the differences between the latter and two other related terms (MDA and

model-driven development (MDD)) that are also commonly used in the literature.

Basically,

MDD is smaller in scope than MDE (the letter ‘D’ means development, while ‘E’ meansengineering) MDA, on the other hand, is a particular realisation of MDD by the ObjectManagement Group (OMG)1.

Since our aim in this dissertation is to study the development of software systems, we will

limit our focus to just MDSE Before reviewing the related work, let us clarify the meaning

of two basic and related terms: domain and domain model We adopt the following recent

definition of both terms from Brambilla et al [9]

Definition 2.1 Domain (a.k.a problem domain) is a field of expertise that needs to be

examined to solve a problem Domain model is the conceptual model of the domain.

The work by Kent et al [38] serves as a good light-weight introductory background forMDSE, not only because of the timing of its publication but because it broadly coversMDE and does so on the basis of an initial draft specification of the MDA by OMG Theydefine MDA as “ an approach to IT system specification that separates the specification

of system functionality from the specification of the implementation of that functionality

on a specific technology platform” [55] This means that the same system model of thefunctionality can be applied to different implementation platforms The two types of

specification in the above definition are represented by two types of model:

platform-independent model (PIM) (the system functionality) and platform-specific model

(PSM) (the platform).

MDA defines four types of model transformations between PIM and PSM and

suggests that, to ease maintenance, these transformations be automated as much aspossible The first model transformation type is PIM-to-PIM, which is used for designrefinement The second type is PIM-to-PSM, which is for realising PIM in a particularplatform The third type is PSM-to-PSM, which is for platform model refinement Thefourth type is PSM-to-PIM, which is for reverse engineering PIMs from PSMs of anexisting platform

Next, Kent et al suggest that meta-modelling be used to specify the languages that

are used to express models This is attractive because it effectively reuses MDE to define

itself A meta-model is a model that expresses the shared structure of a set of related

models Among the key points about meta-modelling are: (i) language definitions are just models (called meta-models) with mappings defined between them, (ii) meta-modelling

can be used to specify the abstract and concrete syntax, and the semantics of a language

and (iii) meta-modelling is achievable with an object-oriented modelling language (e.g.

MOF [58]).

Schmidt [67] both reinforces the work by Kent et al and discusses another importantcontribution of MDE to software development He argues that MDE had a potential for

addressing the abstraction gap problem, through effective domain modelling This

prob-lem arised from a fact that software languages were primarily concerned with the solutionspaces and, thus, were inadequate for effectively expressing the domain concepts Schmidt

next states that MDE technologies should be developed to use domain-specific modelling

language (DSML) (a type of domain-specific language (DSL) [39] that is defined

through meta-modelling) to construct models and transformation engine and generator

to auto- matically produce other software development artefacts from the models BeforeSchmidt, Czarnecki [16] also stated that MDA/MDD is a form of generative softwaredevelopment We will discuss DSL shortly in Section 2.1.2

More recently, Brambilla et al [9] has studied MDSE as a method and how it is applied toengineering software They define MDSE as “ a methodology for applying the advantages

of modelling to software engineering activities” The key concepts that MDSE entails

are models and transformations (or “manipulation operations” on models) This definition

then serves as the basis for integrating MDSE into four well-known software developmentprocesses MDSE may be integrated into the traditional development processes (such aswaterfall, spiral, and the like) by making models the primary artefacts and by using modeltransformation techniques to automate (at least partially) the activites that are performedwithin and at the transition between different phases

MDSE can also be integrated into agile, domain-driven design (DDD) and test-driven

development processes Within the scope of this dissertation, we are interested in theintegration capability of MDSE into DDD We will discuss this capability in Section 2.1.6

2.1.2 Domain-Specific Language

In general, DSL [40, 50, 74] is a software language that is specifically designed for expressingthe requirements of a problem domain, using the conceptual notation suitable for the domain

An important benefit of DSL is that it raises the level of abstraction of the software model

to the level suitable for the domain experts and thus help them participate more activelyand productively into the development process Despite the fact that different DSLs aredesigned for different domains, they share some underlying properties that can be used toclassify them DSLs can be classified based on domain [39] or on the relationship with

the target

(a.k.a host) programming language [25, 50, 74] From the domain’s perspective, DSLs areclassified as being either vertical or horizontal DSL [39] A vertical DSL, a.k.a business-

oriented DSL, targets a bounded real-world domain For example, course management is areal-world domain of CoURsEMan and the completed domain model of the one shown inFigure 1.1 would form the domain model of a vertical DSL for expressing this domain

In contrast, a horizontal DSL (a.k.a technical DSL) targets a more technical domain,

whose concepts describe the patterns that often underlie a class of vertical domains whichshare common features Examples of horizontal DSLs include Structured Query Language(SQL), used for writing executable queries for relational databases, and Hypertext Mark-upLanguage (HTML), used for writing the source code of web pages

Regarding to the relationship with the host language [25, 40, 50, 74], DSLs areclassified as being internal or external In principle, internal DSL has a closer relationshipwith the host language than external DSL A typical internal DSL is developed using eitherthe syntax or the language tools of the host language In contrast, a typical external DSLhas its own syntax and thus requires a separate compiler to process

MDSE with DSL

It is a little surprising that the idea of combining MDSE with DSL [16, 67] only came outabout five years after the OMG’s proposal for MDA/MDD A plausible explanation forthis, as Czarnecki [16] pointed out, is that the MDSE effort until then had only beenfocusing on addressing the platform complexity issue It had paid almost no attention to thedomain complexity problem A recent DSL survey [40] reveals that this issue still remains:there has been insufficient focus in DSL research on domain analysis and languageevaluation and on the integration of DSL engineering into the overall software engineeringprocess

The general method for combining MDSE with DSL is formulated in [9] A technicaldiscussion on how to use meta-modelling to engineer DSLs is presented in [39] The workin

[39] proposes two variants of the meta-modelling process: for vertical DSLs, it is thedomain modelling process (discussed in detail in [25]); for horizontal DSLs, it is a pattern-based modelling process

In practice, one of the very early works [77, 78] had experimented with combining MDSEand DSL in a layered, service-oriented architecture, named SMART-Microsoft A key

feature of this work is that it defines a framework for identifying and combining the DSLsthat form