A Unified View Approach to Software Development Automation

A Unified View Approach to Software Development Automation A Unified View Approach to Software Development Automation A Unified View Approach to Software Development Automation luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

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: Assoc Prof., Dr Nguyen Viet Ha 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: PGS TS Nguyễn Việt Hà 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 mơ hình lên phương pháp luận quan trọng kỹ nghệ phần mềm Ở trung tâm phương pháp luận có hai phương pháp có tính bổ trợ là: kỹ nghệ phần mềm hướng mơ hình (model-driven software engineering (MDSE)) thiết kế hướng miền (domain-driven design (DDD)) Trong MDSE mang mục tiêu rộng tham vọng mục tiêu DDD lại khiêm tốn thực tế hơn, tập trung vào cách áp dụng kỹ thuật kỹ nghệ dựa mơ hình để giải phức tạp vốn có yêu cầu miền Phương pháp DDD bao gồm tập ngun lý để xây dựng mơ hình miền dạng khả thi cho triển khai viết mã ngơn ngữ lập trình đích Tuy nhiên phương pháp thiếu 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 áp dụng DDD vào tảng ngơn ngữ lập trình hướng đối tượng (object oriented programming language (OOPL)): (i) thành phần cấu tạo nên mơ hình miền có mức độ diễn đạt thiết yếu? (ii) xây dựng cách hiệu phần mềm từ mơ hình miền nào? Luận án đặt mục đích khắc phục hạn chế DDD cách sử dụng ngôn ngữ chuyên biệt miền dựa ghi (annotation-based domain-specific language (aDSL)), phát triển OOPL, để không biểu diễn mơ hình miền hợp 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 Thứ nhất, luận án đề xuất aDSL, tên ngôn ngữ đặc tả lớp miền (domain class specification language (DCSL)), bao gồm tập ghi để biểu diễn ràng buộc cấu trúc thiết yếu hành vi thiết yếu lớp miền Tác giả cẩn thận lựa chọn đặc trưng thiết kế từ số nguồn tài liệu học thuật có uy tín kỹ nghệ phần mềm kỹ nghệ hệ thống lập luận đặc trưng tạo thành không gian thiết kế tối giản cho lớp miền Thứ hai, luận án đề xuất phương thức tiếp cận mơ hình hóa miền hợp nhất, sử dụng DCSL để biểu diễn thành phần mơ hình hóa cấu trúc 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 trình bày cách biểu diễn đặc trưng chuyên biệt trạng thái ngơn ngữ DCSL Để chứng tỏ tính thực tiễn cách tiếp cận, luận án định nghĩa tập mẫu mơ hình hóa miền hợp cho toán thiết kế liên quan trực tiếp đến năm luồng hoạt động UML Thứ ba, luận án đề xuất mơ tả đặc điểm gồm bốn tính chất cho phần mềm xây dựng trực tiếp từ mơ hình miền Bốn tính chất định nghĩa dựa 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, lớp mô-đun trực tiếp bao quanh lớp lõi lớp phần mềm Thứ tư, luận án đề xuất aDSL thứ hai, tên ngôn ngữ lớp cấu hình mơ-đun (module configuration class language (MCCL)), dùng để thiết kế lớp cấu hình mơ-đun (module configuration classes (MCCs)) kiến trúc phần mềm dựa mô-đun Mỗi MCC cung cấp định nghĩa dạng lớp cho tập cấu hình mơ-đun lớp mơ-đun Các MCC dễ dàng sử dụng lại để tạo biến thể lớp mô-đun mà không cần sửa thiết kế bên mô-đun Thứ năm, luận án phát triển công cụ dành cho DCSL, MCCL sinh mã ngôn ngữ này, dạng thành phần phần mềm khung, tên JDOMAINAPP Để đánh giá kết trên, luận án trước hết trình diễn tính thực tiễn phương pháp cách áp dụng vào trường hợp nghiên cứu tương đối phức tạp 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 ngơn ngữ đặc tả đánh giá hiệu việc sử dụng MCCL xây dựng mô-đun phần mềm cách tự động Chúng cho rằng, đóng góp luận án giúp phương pháp DDD trở nên cụ thể đầy đủ Một mặt, phương pháp trở nên cụ thể với giải pháp giúp áp dụng cách hiệu vào tảng OOPL Mặt khác, phương pháp trở nên đầy đủ với giải pháp cho khía cạnh thiết kế chưa 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 3 7 12 13 13 13 15 17 22 27 28 29 33 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 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 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 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 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 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 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 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 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 main reasons why OOPL would result in domain models that are inherently expressive and feasible First, object naturally represents the (abstract) entities that are conceived to exist in real-world domains Second, the construct of object used in OOPL is also a basic construct of high-level analysis and design modelling languages that are used to conceptualise and analyse the domain The domain model, which is primarily studied under DDD and a type of model engineered in MDSE, is in fact the basis for specifying what had been called in the language engineering community as domain-specific language (DSL) [74] The aim of DSL is to express the domain using concepts that are familiar to the domain experts A key requirement in DSL engineering is to enable the domain experts and the technical team to focus on building the domain model, not having to worry about the technicality of language design A type of DSL, called annotation-based DSL (aDSL) [25, 54], appears to satisfy this requirement aDSL is an application of the annotation feature of modern OOPLs in DSL engineering Before this, however, annotation (called attribute in C# [33]) was used in attribute-oriented programming (AtOP) [12, 13] to express meta-attributes and in behaviour interface specification language (BISL) [32] to define the specification structure A key benefit of aDSL is that it is internal to the host OOPL and thus does not require a separate syntax specification This helps significantly reduce development cost and increase ease-oflearning In fact, simple forms of aDSL have been used quite extensively in both DDD and MDSE communities In DDD, annotation-based extensions of OOPLs have been used to develop software frameworks (e.g [17, 60]) that support the development of not only the domain model but the final software The design rules in these models are expressed by a set of annotations In MDSE, annotation sets are used to construct platform-specific models of software [4, 76, 77, 78] Our initial research started out with an MBSD-typed investigation into a practical problem of how to improve the productivity of object-oriented software development [8, 43, 49, 51] using a Java-based design language for the domain model [44] and a software architectural model [45] Placing these works in the context of DDD, MDSE and aDSL have given us an opportunity to advance our research to tackle a broader and more important problem concerning the DDD method for object-oriented software 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 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 – HelpRequest: captures data about help information provided to students – Orientation: captures data about orientation programs for newly-registered students – Payment: captures data about payment for the intuition fee that a student needs to make – Authorisation: captures data about the decision made by an enrolment officer concerning whether or not to allow a student to undertake the registered course modules – EnrolmentApproval: captures data about the decision made by the enrolment officer concerning a student’s enrolment – EnrolmentMgmt: represents the enrolment management activity This activity involves registering Students, enrolling them into CourseModules and registering them into SClasses In addition, it allows each Student to raise a HelpRequest 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 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: Class Payment is immutable, i.e all objects of this class are immutable Field Student.name is mutable, i.e its value can be changed Student.name is not optional, i.e its value must be specified for each object Student.name does not exceed 30 characters in length Student.name is not unique, i.e its value may duplicate among objects Student.id is an id field Student.id is auto, i.e its value is automatically generated The minimum value of CourseModule.semester is The maximum value of CourseModule.semester is 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 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 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 constraining the state space of each domain class in the model For this state space, two orthogonal design questions that can be raised are: (i) what are the essential types of behaviour that operate on a constrained state space? and (ii) how we specify the behaviour types directly in each domain class, in such a way that can help capture the relationship with the state space? Let us take class Student in Figure 1.1 as an example Given the constrained state space that is structured around the class and its two attributes (id and name), what are the essential operations that must be defined for this class? More specifically, is the constructor Student(Student, String) shown in the figure sufficient for creating Student objects that the software needs? What are the basis for defining the other three operations of the class, namely getId, setName and getName? Are there any other essential operations that we need to add to this class? Regarding to modelling the behaviour type, how we specify the behaviours of, say, the constructor Student(Student, String) and the operations setName and getName so that they make explicit the connections to the attribute Student.name? Clearly, such connections help validate the essentiality of the behaviours, while making the design of Student easier to comprehend Software Construction from the Domain Model Software construction from the domain model requires this model to essentially support both structural and behavioural modelling elements UML [57] includes three behavioural modelling languages: state machine and interaction and activity diagrams The first challenge is how to factor in the domain model the behavioural modelling structure (e.g activity class and activity graph structure of an activity)? For the CourseMan example in Figure 1.1, for instance, how we define the activity class EnrolmentMgmt and the activity graph structure of the concerned activity? This would cover the area labelled ‘?’ in the figure Another challenge with software construction is what software architecture can be suitable and how to use it to effectively construct software from the domain model? This challenge needs to be addressed in the context of a well-accepted fact that software construction can not be fully automated [26] The generally accepted position is that a GUI-based tool is employed to assist the development team in the construction process The constructed software plays two important roles First, it is used during domain model development to enable the development team to iteratively and interactively build the domain model As discussed in [22], this phase is central to DDD For the CourseMan example, for instance, the software would need to present a GUI that truly reflects the domain model structure Further, it should support partially completed models, such as the one shown in Figure 1.1, and should evolve with the model as it is updated through the development iterations Second, the software is reused during production software development to quickly develop the production-quality software For instance, the production-quality CourseMan software would be constructed not only from the finalised domain model but from the software components (e.g architectural components, view layouts and view fields) that were used during 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 development However, in the context of the challenges presented above, we argue that there are still important open issues concerning the object-oriented problem domains that need to be addressed These issues fall into two main areas: domain modelling and software development from the domain model First, the domain model does not define the essential structural 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 is being used quite extensively in implementations of the method in the existing DDD software frameworks Third, there has been no formal study of how to construct software from the domain model In particular, such a study should investigate generative techniques (similar to those employed in MDSE) that are used to automate software construction 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 but generatively construct modular software from this model We claim that attaining this aim would help make the DDD method not only more concrete but more complete for object7 oriented software development purposes On the one hand, the method would become more concrete with specific solutions that help the technical team effectively apply the method in the OOPL platforms On the other hand, the method would become more complete with solutions for the design aspects that were not originally included We organise our research with the following objectives: To investigate and design a unified domain model that includes the essential elements for both the structural and behavioural modelling aspects 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 To investigate and define a generative and modular software construction approach To investigate and design suitable aDSL(s) for the unified domain model and for software construction 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 both engineer 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 human mind [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 not well-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 build the system We adapt the iterative software engineering method [43, 70] to define an enhanced 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 iteratively All three phases are supported by a software framework named jDomainApp 2 paper listed in the Publications section Figure 1.2: An overview of DDDAL (with an emphasis on phases and 2) Phases and 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 takes as input the (typically incomplete) structural and behavioural requirements from the domain experts and produce as output a domain model, called UDM The purpose of phase is to generate a software prototype 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 The subsequent iterations repeat at phase with an update on the domain model The process is stopped when the domain model satisfies the requirements From here, it is used to develop the production software The generated software prototype is reusable for this development Consequently, our research approach in this dissertation is a system meta-approach, whose aim is to define a subset of elements for the first two phases of DDDAL We consider these two phases as two sub-problems of our research problem (defined in Section 1.1), which are tackled by carrying out the research objectives (defined in the previous section) We will 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, and We conduct a literature survey on the essential structural and behavioural features of the domain class and 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 not force the use of any highlevel modelling languages for expressing the input requirement sets In our method, the designer works closely with the domain expert to map the input requirements, together with any accompanied high-level models, to the UDM and expresses this UDM in an aDSL This collaboration is performed iteratively with the help of a GUI-based software prototype that is constructed directly from the UDM We design the structural aspect of the UDM 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 domain-expertfriendly [20] and that it is tightly linked to the other two UML behavioural diagrams (state machine and interaction diagram [57]) To express UDM, we propose an aDSL named Domain Class Specification Language (DCSL) We apply modelling to specify DCSL and implement this language as part of the jDomainApp framework We evaluate DCSL 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, and 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, DDD frameworks 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 software architecture to explicitly model software in terms of a set of modules Software modules are instantiated 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 framework and evaluate module-based 10 software construction with MCCL The jDomainApp framework has an implementation for the sub-problem (2.b) However, we 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 subproblems presented above As the contributions will show, the term “unified view” in the dissertation’s title refers to our aDSL-centric view of automated software construction 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 essential structural 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 configuration classes for software modules Each of these classes serves as a template for creating 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 and the associated generators as components in the jDomainApp software framework 11 1.4 Dissertation Structure This dissertation is organised into chapters that closely reflect the stated contributions In Chapter 2, we systematically present the background knowledge concerning the concepts, methods, techniques and tools that are most relavant to the research problem and necessary for explaining our contributions in the rest of this dissertation We also highlight the limitations of the existing DDD method and the works concerning the use of aDSL with MDSE and DDD In Chapter 3, we describe our contributions concerning UD modelling Taking the view that domain class design is the basis for UDM construction, we first specify DCSL for expressing the essential structural and behavioural features of the domain class We then use DCSL to define UDM After that, we present a set of generic UD modelling patterns that can be applied to construct UDMs for real-world domains In Chapter 4, we explain our contributions concerning module-based software construction We first set the software construction context by defining a software characterisation scheme We then specify MCCL for expressing the MCCs and present a generator for generating the MCCs In Chapter 5, we present an evaluation of our contributions We first describe an implementation of the research contributions as components in the jDomainApp framework We then describe a real-world software development case study which we have developed using the implemented components After that, we present two evaluations: one is for DCSL and the other is for module-based software construction In Chapter 6, we conclude the dissertation with a summary of the research problem, the contributions 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 12 Chapter State of the Art In this chapter, we present a methodological study of the literatures that are relevant to this dissertation We have two main objectives The first objective is to gather authoritative guidance for and to define the relevant foundational concepts, methods, and techniques The second objective is to identify significant, unresolved issues that can be addressed in our research In particular, we highlight the limitations of the existing DDD method and the 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 and techniques concerning MDSE, DDD and OOPL In particular, we highlight the role of aDSL (which is derived from OOPL) as the underlying theme that connects MDSE and DDD 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 of MDE 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, 13 MDD is smaller in scope than MDE (the letter ‘D’ means development, while ‘E’ means engineering) MDA, on the other hand, is a particular realisation of MDD by the Object Management 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 for MDSE, not only because of the timing of its publication but because it broadly covers MDE and does so on the basis of an initial draft specification of the MDA by OMG They define 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 the functionality 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 as possible The first model transformation type is PIM-to-PIM, which is used for design refinement The second type is PIM-to-PSM, which is for realising PIM in a particular platform The third type is PSM-to-PSM, which is for platform model refinement The fourth type is PSM-to-PIM, which is for reverse engineering PIMs from PSMs of an existing 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]) http://www.omg.org 14 Schmidt [67] both reinforces the work by Kent et al and discusses another important contribution of MDE to software development He argues that MDE had a potential for addressing the abstraction gap problem, through effective domain modelling This problem arised from a fact that software languages were primarily concerned with the solution spaces 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 automatically produce other software development artefacts from the models Before Schmidt, Czarnecki [16] also stated that MDA/MDD is a form of generative software development 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 to engineering 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 development processes MDSE may be integrated into the traditional development processes (such as waterfall, spiral, and the like) by making models the primary artefacts and by using model transformation techniques to automate (at least partially) the activites that are performed within 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 the integration 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 expressing the 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 actively and productively into the development process Despite the fact that different DSLs are designed for different domains, they share some underlying properties that can be used to classify them DSLs can be classified based on domain [39] or on the relationship with the target 15 (a.k.a host) programming language [25, 50, 74] From the domain’s perspective, DSLs are classified as being either vertical or horizontal DSL [39] A vertical DSL, a.k.a businessoriented DSL, targets a bounded real-world domain For example, course management is a real-world domain of CourseMan and the completed domain model of the one shown in Figure 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 which share common features Examples of horizontal DSLs include Structured Query Language (SQL), used for writing executable queries for relational databases, and Hypertext Mark-up Language (HTML), used for writing the source code of web pages Regarding to the relationship with the host language [25, 40, 50, 74], DSLs are classified as being internal or external In principle, internal DSL has a closer relationship with the host language than external DSL A typical internal DSL is developed using either the syntax or the language tools of the host language In contrast, a typical external DSL has 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 out about five years after the OMG’s proposal for MDA/MDD A plausible explanation for this, as Czarnecki [16] pointed out, is that the MDSE effort until then had only been focusing on addressing the platform complexity issue It had paid almost no attention to the domain 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 language evaluation and on the integration of DSL engineering into the overall software engineering process The general method for combining MDSE with DSL is formulated in [9] A technical discussion on how to use meta-modelling to engineer DSLs is presented in [39] The work in [39] proposes two variants of the meta-modelling process: for vertical DSLs, it is the domain 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 MDSE and 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 DSLs that form 16 a complete software model More specifically, this entails a 3-step development method: (i) determine the application architecture, (ii) develop the DSLs that fit this architecture and (iii) combine the DSLs by defining transformations between them In this method, the DSLs are designed to address different parts of the architecture and each DSL is used to create not one monolithic model but multiple partial models 2.1.3 Meta-Modelling with UML/OCL As discussed above, meta-modelling is a modelling approach that is applied to defining DSL More generally, Kleppe [39] suggests that meta-modelling is applicable to any software language This includes both DSL and general purpose language (e.g Java [28] and C# [33]) In meta-modelling, a language specification consists in three meta-models and the relations between them The first meta-model describes the abstract syntax and is called abstract syntax meta-model (ASM) The second meta-model describes the concrete syntax and is called concrete syntax meta-model (CSM) The third meta-model describes the semantics and is called semantic domain meta-model (SDM) According to Kleppe [39], the ASM describes the conceptual structure that exists in the language’s domain, while the CSM describes the linguistic structure that helps present the conceptual structure to a pre-determined population of language users The SDM makes clear the semantic structure of the concepts Technically, if we consider the Kleppe’s view that a (modelling or programming) language is a set of mograms (a mogram is either a model or a program (resp.) written in the language) then SDM describes “ what happens in the computer when a mogram of the language is executed” Here, “what happens in the computer” is defined based on a representation of the computer’s run-time This representation must allow for a precise description of the run-time state when a mogram is executed As a general modelling approach, there are a variety of meta-modelling languages that can be applied A de facto language is Unifield Modelling Language (UML) [57] UML consists in a family of languages, one of which is UML class diagram This language, which we will refer to in this dissertation as class modelling language, is made more precise when combined with the Object Constraint Language (OCL) [56] This combination forms an enriched language, which we will generally refer to in this dissertation as UML/OCL In fact, UML/OCL is used in the UML specification itself [56] to define the abstract syntaxes of the languages in the UML family Later in Section 2.2.2, we will discuss an example of 17 how UML/OCL is used to specify the activity modelling language In the remainder of this section, we present an essential review of UML/OCL Our focus is on the abstract syntax of a core meta-modelling structure of UML/OCL The meta-concepts that form this structure will be used later in this dissertation to define aDSLs The informal semantics of the meta-concepts are given in [56, 57] In the spirit of meta-modelling, we adopt the approach used in the UML specification to use UML/OCL to define itself Specifically, we first construct the ASM of UML and introduce very briefly the graphical syntax After that, we discuss OCL and, as an example, explains how OCL is used to express some syntax rules of the ASM We conclude with a brief review of the approaches for specifying SDM The Essential ASM of UML Figure 2.1: The essential ASM of UML (synthesised from seven meta-models of UML [57]) The essential ASM for UML consists of the following meta-concepts: Class, Attribute, Association, Association End, Operation, Parameter, Association Class and Generalisation This ASM, which is shown in Figure 2.1, suffices for our research purpose in this dissertation A meta-concept is represented in the figure by a labelled rectangle A relationship between two meta-concepts is represented by a line segment that connects the two corresponding rectangles On the one hand, the ASM is derived from a combination of the core structures of seven relevant UML meta-models presented in the UML specification [57] On the other hand, it adds two new, more specialised, meta-concepts (Attribute and Association End) for modelling the class structure 18 The referenced meta-models come from the following sections of the UML specification: – Abstract syntax of the root (foundational) concepts of UML (see §7.2.22) – Abstract syntax of Classifiers (the base concept of UML’s classification) (see §9.2.2) – Abstract syntax of Feature which includes the Parameter concept (see §9.4.2) – Abstract syntax of Property and the related concepts (see §9.5.2) – Abstract syntax of Operation and the related concepts (see §9.6.2) – Abstract syntax of Class – a type of Classifier – and the related concepts (see §11.4.2) – Abstract syntax of Association and the related concepts (see §11.5.2) To ease look-up, we label each key element of the ASM with the section reference, within whose meta-model the element is defined For instance, meta-concept Class is defined in the meta-model of §11.4.2 The ASM presented in Figure 2.1 includes two new meta-concepts: Attribute and Association End These meta-concepts, whose rectangles are filled in gray, are sub-types of the meta-concept Property We use the two meta-concepts to differentiate between properties that are attributes and those that serve as association ends of associations The former participate in the containment relationship between Class and Attribute, while the latter participate in the containment relationship between Association and Association End Further, Class has a containment relationship with Association The Essential OCL According to the OCL specification [56], OCL is a user-friendly, typed, formal language for constructing expressions on UML models OCL expressions are side-effect-free and each has a type Typical examples of OCL expressions are invariants and queries over a UML model The OCL specification consists in two packages: type (§8.2) and expression (§8.3) The former defines the valid types for the expressions in the latter In the type package, all OCL types are derived from Classifier3 (see UML specification §9.2.2) Two core OCL types we use the symbol § to denote sections in the UML specification we use fixed font here to be consistent with the OCL’s notation style below 19 Figure 2.2: The OCL expression meta-model (Adapted from §8.3 [56]) that are commonly used are CollectionType and TupleType CollectionType has four sub-types, namely SetType, OrderedSetType, SequenceType and BagType, representing sets, order sets, sequences, and bags (resp.) CollectionType is parameterised with an element type and can be nested A nested CollectionType is one whose element type is another CollectionType The TupleType conveniently combines different types to form an aggregate type, called tuple Each part of a tuple is represented by an attribute An attribute is typed and is uniquely identified by a name Similar to CollectionType, TupleType is also nested This means that the attributes in a tuple can have their types defined as TupleTypes The expression package, whose meta-model is shown in Figure 2.2, specifies the structure of OCL expression Every OclExpression is typed, which is usually not explicitly stated but derived The core structure of OclExpression is described by VariableExp and the CallExp’s type hierarchy VariableExp is an expression that involves the declaration and (possibly initialisation) of a variable The initialisation consists in another OclExpression, which is typically a LiteralExp (for writing a value) or a CallExp CallExp is used to “call”, i.e set up, another expression that either, for the subtype named FeatureCallExp, references the value of a model’s feature (e.g attribute, operation and association end) or, for the subtype named LoopExp, performs a loop over a collection This loop involves a 20 Variable that points to each element of the collection and one or more OclExpressions that define a condition against which the elements are checked An OclExpression is defined in a context of a model element (e.g a class, an attribute, a method, etc.) It is via this element that an OclExpression can navigate the model, through association chains, to access other model elements that are of interest A special keyword self is available in every OclExpression for referring to the contextual element To ease writing, this keyword is implicit if omitted Example 2.1 Let us illustrate OCL by showing how it is used to express an invariant on the UML’s ASM in Figure 2.1 The invariant is taken from §11.8.1.8 of the UML specification [57], which states that an aggregation is a binary association: context Association inv : self memberEnd - > exists ( e | e aggregation AggregationKind :: none ) implies ( memberEnd - > size () = and memberEnd - > exists ( aggregation = AggregationKind :: none ) ) Line uses the keyword context to specify the context of the invariant (keyword inv) to be an Association The invariant is interpreted as being true for every Association instance (at all times) Lines 2–6 form the body of the invariant It is an implication A → B, where A is specified at lines 2–3 and B is specified at lines 5–6 The keyword implies means → Lines 2–3 form a CallExp that performs an operation called exists over the collection self.memberEnd This operation returns true or false depending on whether there exists an element of the collection that satisfies the condition: e.aggregation AggregationKind::none In this condition, e is a Variable that points to each collection element and AggregationKind::none means ‘not-an-aggregation’ Thus, the condition effectively means to find all Association Ends of the current Association instance that is an aggregation of some kind Lines 5–6 state two conditions that hold for memberEnd (which is a short-form of self.memberEnd): (line 5) it contains exactly two elements (hence the association is binary) and (line 6) at least one other Association End of the current Association is not an aggregation The second condition consists in a negated expression of the one used in A 21 Approaches for Specifying SDM Kleppe [39] states four general approaches to defining the SDM of a language The first approach is denotational, which uses a mathematics-based formalism The second approach is translational, which translates the language into another language whose semantics is known The third approach is pragmatic, which uses a reference implementation of the language as a way of describing semantics This is a special form of the translational approach, in which the implementation language’s semantics is known The fourth approach is operational, which defines the run-time state structure using some form of state-transition system and maps the mogram execution to the transition actions (or operations) in this system It is worth mentioning that Kleppe’s view of the SDM amounts to what is called in the programming language community as dynamic semantics (Chapter of [39]) It is dynamic in the sense that the semantics relies on the run-time state change From the programming language’s perspective, there is also a static semantics of a language, which does not rely on the run-time This semantics describes the well-formedness of the language mograms and thus can be checked at compile-time In principle, a mogram’s concrete representation (e.g a piece of text or a graphical form) is processed to produce the mogram’s abstract form Static semantic analysis is performed at the end of this process to check the well-formedness (including valid binding and typing) of the mogram 2.1.4 Domain-Driven Design The general goal of domain-driven design (DDD) [22, 75] is to develop software iteratively around a realistic model of the application domain, which both thoroughly captures the domain requirements and is technically feasible for implementation According to Evans [22], objectoriented programming languages (OOPLs), such as Java [3, 28], are a natural fit for 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 and feasible First, object naturally represents the (abstract) entities that 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 In this dissertation, we use DDD to refer specifically to object-oriented DDD Domain modelling is concerned with building a domain model for each subject area of interest of a domain DDD considers domain model to be the core (or “heart” [22]) of software, which 22 is where the complexity lies DDD has two key tenets [22, 75]: (1 - feasibility) a domain model is the code and vice versa, and (2 - satisfiability) the domain model satisfies the domain requirements that are captured in a shared language, called the ubiquitous language This language is developed by both the domain experts and the technical members of the project team, in an iterative and agile process of investigating and analysing the domain requirements In our view, these tenets are the motivation behind the main research thread in DDD that had led to the development of contemporary object-oriented DDD software frameworks (e.g Apache-ISIS [17] (successor of Naked Objects [62]) and OpenXava [60]) The modelling languages of these works are constructed from some annotation-based extensions of OOPL DDD Patterns The DDD method [22, 52] provides a set of eight design patterns that address two main problem types: (i) constructing the domain model (5 patterns) and (ii) managing the life cycle of domain objects (3 patterns) The five patterns of the first problem type include four patterns originally proposed by Evans [22] and one emerging pattern (named domain events) reported by Millet and Tune [52] The four original patterns are: entities, value objects, services (a.k.a domain services [52]) and modules The three patterns of the second problem type are: aggregates, factories and repositories We argue that, unlike the pattern aggregates, the two patterns factories and repositories are strictly not specific to domain modelling They are adaptations of well-known generic technical solutions that help improve the design quality of a software model For these reasons, in this dissertation, the term “DDD patterns” will exclude the two patterns factories and repositories entities This pattern discusses how the concept of entity, which originates from conceptual modelling [34], should be treated with special care in DDD The key design consideration is that entity is an object defined fundamentally by its identity This identity, which is typically represented by an identity attribute, gives the entity a “thread of continuity” thoughout its life time Each entity has a unique identity value, which typically does not change throughout its life time Other types of attributes, associations and other features that are associated with an entity are defined based on the identity For example, the 12 domain classes of the CourseMan domain model in Figure 1.1 are entity types A domain object of each class is an entity Although the designs of these classes are incomplete, each class is defined with an identity attribute All but the 23 two classes CourseModule and ElectiveModule are defined with an identity attribute named id CourseModule’s identity attribute is named code, which is inherited down to ElectiveModule value objects This pattern discusses a special type of object called value object that “represents a descriptive aspect of the domain that has no conceptual identity” [22] What value object describes (its value) is more important than its identity An example given in [22] is the Color object provided by Java Each object has a distinct colour value that describes a specific colour We argue, based on this and other similar examples in [22], that it would be better (for domain modelling purposes) to treat value object as a special type of entity that has an identifier, but this identifier is the only attribute of interest The identifier values carry domain-specific information that are significant for a particular modelling purpose We are not concerned with the associations that value object has with other entities, regardless of the fact that these associations typically exist in the domain model Understanding value object this way helps easily relate the two patterns For example, in the CourseMan’s domain model of Figure 1.1 there are two types of value objects Both are modelled in UML as enumeration types The first type is named PaymentStatus, which describes a fixed set of distinct status values for the Payment transaction Two typical payment status values are approved and rejected The second type is AuthorzStatus, which describes a fixed set of distinct status values for Authorisation of enrolment Similar to Payment, the typical authorisation status values are also approved and rejected services (a.k.a domain services [52]) This pattern describes system behaviours that not fit the responsibility of entity These behaviours operate on entities but typically not need to maintain state information like entities Therefore, these behaviours are defined in a special concept named services Evans [22] notes that services actually exist not only in the domain model but in other parts of the software For example, there would be infratructure services responsible for providing such low-level, shared behaviours as networking and data communication There are also application services responsible for coordinating behaviours of domain objects from different domain classes The distinction between this type of service and domain service is very subtle, because both service types involve coordinating the domain objects in some fashion Basically, Evans states that if a service’s coordination logic is domain-specific then it is a domain service; otherwise it is an application service 24 In the CourseMan’s domain model of Figure 1.1, for example, class EnrolmentMgmt is a type of service It performs a domain-specific, activity-based logic which requires coordinating the behaviours defined by other domain classes in the model domain events This pattern describes when and how domain-specific events are modelled in the domain model A domain event is an important occurrence that typically involves performing some domain logic over two or more entities (such as that performed by services) Our view is that, regarding to domain service design, services is the core pattern and domain events enhances this core behaviour In an event, one (publisher) entity announces the event and other (subscriber) entities, who are interested in the event, are informed of the event and, in response, carry out the relevant pieces of the domain logic The invocation of this logic can be carried out either synchronously or asynchronously (via messages) We argue that domain event may not be needed in the former case, because it simply provides an optional layer of indirection to services (at the cost of additional code) In the latter case, domain event is necessary because the publisher must not know the subscriber(s) directly There are two main design solutions for domain events: (i) rely on the language support for events (e.g C#’s event) and (ii) define a separate event management model that provides the publish and subscribe interface operations for entities to use The latter solution is more generic as it can be applied regardless of the implementation language feature support To illustrate domain events, let us consider an event that occurs when a particular Enrolment has a “Fail” finalGrade, which means the concerned Student has failed a CourseModule In this case, Enrolment is the publisher and EnrolmentMgmt would be a suitable subscriber of the event The latter is because EnrolmentMgmt, as explained in the services pattern, performs the domain service logic concerning the enrolment matters modules This pattern describes how the traditional concept of module in programming [51] is applied to the domain model Evans [22] defines module as a sub-structure of the domain model that “brings together elements of the model with particularly rich conceptual relationships” If the modules of a domain model are designed with high cohesion and low coupling then the domain model can scale to handle more complex domain requirements Evans generally suggests to use package to define modules, but allows the designer to have the flexibility of deciding what to place in each package For example, we would place each domain class of the CourseMan’s domain model in Figure 1.1 into its own module The auxiliary domain classes of a domain class (e.g PaymentStatus is auxiliary to Payment) are placed in the domain class’s module 25 aggregates This pattern describes a stronger logical object grouping than module in that the object group is treated as a single unit In an aggregate, there is a root entity that acts as the access point for other objects that are internal to the aggregate Strong dependency associations exist between the root and the internal objects, so that outside objects only need to rely on the root to obtain information about the aggregate Outside objects may only hold transient references to internal objects (obtained from the root) These references are used only within an operation In addition to achieving enhanced modularity, aggregates helps enforce model integrity on the object group of the aggregate For example, in the domain model of the CourseMan software, if we suppose that all the SClassRegistrations not make sense outside the context of their SClasses then we could form an aggregate consisting of these two domain classes SClass is the root entity, while SClassRegistration is internal to the aggregate factories This pattern is an adaptation of the well-known software design pattern named factory [27] A factory takes the object creation responsibility burden away from both entities and the client This helps reduce coupling between these two components, thereby enhancing the modularity of the model repositories This pattern is both an adaption and a generalisation of the object-relational mapping solution [35] First, it is an adaption in the sense of taking the object-relational mapping and applying it to the domain model In particular, it handles how an entity is stored in an underlying database and how to manage access to this database Second, the pattern generalises the mapping in that it defines an abstraction layer on top of the underlying database and a set of generic operations for querying the entities The abstraction takes the form of a repository – a space where the entities “live” and can be searched for DDD with DSL The idea of combining DDD and DSL to raise the level of abstraction of the target code model has been advocated in [25] by both the DDD’s author and others However, [25] does not discuss any specific solutions for the idea Other works on combining DDD and DSL (e.g Sculptor [68]) focus only on structural modelling and use an external rather than an internal DSL A deeper analysis of the related works concerning DDD and DSL reveals two main reasons why internal DSL is particularly suited for DDD First, designing the domain model 26 in an internal DSL helps determine the implementation feasibility of the domain model in a target OOPL An external DSL requires a separate syntax specification and ensuring the correctness of this specification is a non-trivial task Second, a domain model specified in an internal DSL can be treated as a program in the target OOPL This allows the development team to leverage the capabilities of the language platform to not only process the model but to develop the software generator This helps significantly reduce the development effort, compared to using an external DSL 2.1.5 Model-View-Controller Architecture To construct software from the domain model requires an architectural model that conforms to the generic layered architecture [22, 75] A key requirement of such model is that it positions the domain model at the core layer, isolating it from the user interface and other layers Evans [22] suggests that the Model-View-Controller (MVC) architecture model [41, 70] is one such model The existing DDD frameworks [17, 60, 62] support this suggestion by employing some form of MVC architecture in their designs More generally in practical software development, MVC or its variants are adopted so that the software can have some sort of GUI to assist the development team in constructing it This GUI is essential to getting the user feedback, because, at least up to recently and due primarily to the human factor of the development process, software construction can not be fully automated [26] Our position in this dissertation is that the MVC architecture is the backbone of any DDD method that adopts the layered architecture Technically, MVC is considered in [11] to be one of several so-called agent-based design architectures The main benefit of MVC is that it helps make software developed in it inherently modular and thus easier to maintain Software that are designed in MVC consists of three components: model, view and controller The internal design of each of the three components is maintained independently with minimum impact on the other two components Modularity can further be enhanced by applying the architecture at the module level An example of this design is an agent-based design architecture named PAC [15] This design creates a hierarchical design architecture, in which a software is composed from a hierarchy of software modules A software module (called PAC object in [15] and agent in [11]) realises a coherent subset of the software functions in terms of the architectural components 27 Conceptually, in a software designed with MVC and the DDD method, the model component is the domain model It includes a set of domain classes that capture data about the entities of interest in the application domain For example, the CourseMan domain model in Figure 1.1 includes 11 domain classes (excluding EnrolmentMgmt) that represent 11 entities of interest The view component of a software is a set of user interface (UI) classes that are used to present the domain classes Each class presents to the user a coherent view of a domain class and to make it easy for her Figure 2.3: A UI class of the domain class to interact with this view For instance, Fig- Student (Source: [45]) ure 2.3 shows an example of a UI class for capturing data about Student objects For each UI class, there is a controller class responsible for selecting (and causing the display of) the user interface and for handling the events that are caused by user actions performed on it When an event occurs, the controller maps it to suitable state change operation(s), such as create and update, and invokes these to yield result For example, if the user action is to create an object (e.g the action induced by clicking the button labelled Create in Figure 2.3) then the controller would map it to an object instantiation operation of the concerned domain class and invoke this operation to create the object The arguments of this invocation, if any, are the data that the user entered on the user interface In Figure 2.3, for example, data include the values “Le Van Sau”, “1/1/1990”, “Ho Chi Minh”, “sau@gmail.com”, and “1c13” that the user input in the data fields of the UI class of Student When the state of a domain object is changed, a change notification is sent to the corresponding UI class to request it to update the display This class can query the model for details of this change before making the update 2.1.6 Comparing and Integrating MDSE with DDD Understanding the comparison between MDSE and DDD helps determine the most suitable strategy for integrating the two methods In principle, Brambilla et al [9] suggest that MDSE 28 complements DDD by providing techniques (e.g domain modelling and DSL engineering) which can help the development team benefit more from the domain model They state that DDD and MDSE has two main similarities First, both enforce the use of model in developing software Second, both methods support models at different levels of abstraction (e.g platform-independent and platform-dependent) However DDD differs from MDSE in three aspects First, DDD follows a more agile approach to domain modelling, particularly that which relies on modern advance in OOPLs Second, while DDD focuses primarily on the design and implementation phases, MDSE’s scope is wider and covers the entire development process Third, although DDD acknowledges the role of model engineering, it also highlights the importance of a ubiquitous language that is used by all the human actors in the process 2.1.7 A Core Meta-Model of Object-Oriented Programming Language It is clear that a DDD method for object-oriented software needs to use an object-oriented programming language (OOPL) as the target language for implementation In his book [22], Evans uses Java [3, 28] to demonstrate the DDD method We argue that because Java and another, also very popular, OOPL named C# [33] share the core features, we will generalise these features to form what we term a “generalised” OOPL To ease notation, we will refer to this language simply as OOPL We take the Kleppe’s view (see Section 2.1.3) that metamodelling is applicable to any software language and apply it to review the OOPL’s ASM In particular, we will focus on discussing the annotation feature The concrete syntax and semantics of Java and C# are described in [28] and [33] (resp.) Abstract Syntax Figure 2.4 shows a UML-based ASM of OOPL This ASM includes the core meta-concepts that are supported by Java and C# It excludes the meta-concepts that describe the structure of the method body Our scope of interest is on the class structure, not the code Note, in particular, the following three design features of the OOPL ASM shown in the figure First, meta-concept Class represents both class and interface (an interface is a class that has no fields) Second, meta-concept AnnotatedElement is modelled as supertype of four non-annotation meta-concepts: Class, Field, Method and Parameter The association between AnnotatedElement and Annotation helps capture a general rule that 29 Annotation can be attached to any of the non-annotation meta-concept Third, meta-concept Generalisation, which is adapted from UML/OCL (discussed in Section 2.1.3), captures the subclass-superclass relationship between classes Basically, a class may consist of one or more generalisations, each of which must be related to exactly one superclass Figure 2.4: The UML-based ASM of OOPL Definition 2.2 An OOPL model (or model for short) is a structure that conforms to (or is an instance of) the OOPL’s meta-model Denote by e : T a model element (or instance) e of some meta-concept T For example, a Java model for expressing a domain sub-model of CourseMan (discussed in Section 1.1.1) would include the following three Classes: Student, CourseModule and Enrolment These classes are instances of the meta-concept Class of Java Annotation Because Annotation plays a key role in the construction of aDSL (discussed later in Section 2.1.8), we devote this section to discussing this meta-concept in detail Annotation borrows its name from Java [3, 28] The similar meta-concept in C# is called attribute [33] Although annotation is syntactically defined as a Java interface it actually behaves like a class This same view is also held for C#’s attribute In this dissertation, we will promote Annotation to be a generic meta-concept that is applicable to both Java and C# The reason that we choose the Java’s term will become clear shortly below 30 Definition 2.3 Annotation (short for annotation type) is a meta-concept behaviourally equivalent to Class, that is designed for the purpose of being applied to other meta-concepts to present information about them in a uniform and structured fashion The annotation instances are created at run-time for each model element to whose meta-concept the annotation is applied The application of annotation is intuitively called annotation attachment An annotation A may be attached to more than one non-annotation meta-concepts T = {T1 , , Tn } We write this as AT When the context either does not require to identify or is clear as to what T in AT is, we will omit it and simply write AT as A Example 2.2 To model that a domain class, such as Student, requires another resource to perform its behaviour, we would attach to it an annotation named Resource For the sake of the example, we will borrow this annotation from the Java’s built-in annotation of the same name (javax.annotation.Resource) This annotation defines a reference to the target (actual) resource type In fact, the annotation is attachable also to Field and Method So we write: Resource{Class, Field, Method} An annotation consists of properties A property is called an annotation element in Java and a parameter in C# Definition 2.4 An annotation property is characterised by name, data type, and default value Data type is one of the followings: primitive type, string, enum, class, annotation, an array of one of the previous types We call a property an annotation-typed property if its data type is defined from annotation (i.e is an annotation or an array thereof) Notationwise, we use the dot notation to write annotation property; e.g A.p denotes property p of an annotation A An important note about Definition 2.4 is that the notion of annotation-typed property does not directly exist in C# This is because in C# an annotation property cannot take an annotation as its data type Fortunately, this shortcoming can be overcome by a simple transformation that involves “promoting” an annotation-typed property to an annotation and attaching this directly to the target meta-concept We explain this transformation in detail in paper 4, which is listed in the Publications section In this dissertation, we will use annotation 31 property as presented in Definition 2.4, because this definition helps bring a modular structure to annotation Example 2.3 To specify the name of the resource that the domain class Student (discussed in Example 2.2) requires, we use the property Resource.name The data type of this property is String and its default value is the empty string “” It follows from Definition 2.4 that there exists a reference relationship between the annotations We say that an annotation A directly references an annotation B if there exists one annotation-typed property of A such that the data type of this property is defined from B Further, we say that annotation A indirectly references annotation B if there exists another annotation C such that: A directly or indirectly references C and C directly references B In both cases, A is the referencing annotation (of B) and B is the referenced annotation (by A) The next definition makes clear the meaning of annotation instance and its connection to the assignment of annotation to non-annotation element Definition 2.5 Given a model M and an annotation AT , an annotation element a of A in M is an instance of A that is assigned to an element e : Ti ∈ M (for some Ti ∈ T ) We say that a is created by assigning ATi to e, and write ATi (e) = a Conversely, we say that the model element e is assigned with an element of A, or e is a target element of A When we are only interested in whether or not A(e) is defined, we write def(A(e)) and undef(A(e)), respectively Example 2.4 Continuing on from the previous examples, assigning Resource to Student results in the annotation element Resource(Student) being created Assuming that all CourseMan’s domain classes need to know the user-interaction language, then the annotation element has the property name set to “language” In Java, we write the assignment as follows: @Resource ( name = " language " ) public class Student {} Mapping OOPL to UML/OCL We conclude our review of OOPL with a brief discussion of the mapping between this language and UML/OCL We call this mapping meta-mapping, because it maps the ASMs of the two languages In practice, this mapping is essential for transforming a UML/OCL design 32 Table 2.1: Meta-mapping between OOPL and UML/OCL Map# OOPL meta-concepts UML/OCL meta-concepts M1 Class Class M2 Field Attribute M3 Field Association End M4 (pair of ) Field Association M5 Generalisation Generalisation M6 Method Operation M7 Parameter Parameter into the code model of a target OOPL (e.g Java and C#) We present the mapping in Table 2.1, which we adapted from [1, 31] In essence, the mapping consists in a set of correspondences between the meta-concepts of the two ASMs Each table row describes a correspondence between a pair of meta-concepts To different between meta-concepts in the same pair (which may have the same name), we write them in the table using different font styles The DCSL’s meta-concepts are written using fixed font For example, meta-concept Class of DCSL is mapped to the meta-concept Class of UML/OCL 2.1.8 Using Annotation in MBSD After more than a decade since (annotation-supported) OOPL was introduced, three noticable methodological developments concerning the use of annotation in MBSD began to form The first development concerns the use of annotation in programming It occured very early on and results in a programming paradigm called attribute-oriented programming (AtOP) Another early methodological development, which also concerns code model design, revolves round behaviour interface specification language (BISL) The third and more recent development concerns the use of annotation to define annotation-based DSLs, which are internal to the host OOPL Attribute-Oriented Programming In principle, AtOP [4, 12, 13, 72] extends a conventional program with a set of attributes, which capture application- or domain-specific semantics [13], [12] These attributes are 33 represented in OOPL as annotations It is shown in [72], with empirical evidence and based on an observation, that programmers’ mental models overlap and that the practice of recording the programmer’s intention of the program elements using annotations is rather natural Further, the use of purposeful annotations in programs helps not only increase program correctness and readability [72] but raise its level of abstraction [4] MDSE with AtOP Because of the ability to add attributes to the code model, AtOP has been found to help provide a bridge for the abstraction gap (discussed in Section 2.1.1) between OOPL-based PSM and PIM in MDSE A conventional OOPL-based code model (i.e a model constructed only from the built-in OOPL meta-concepts) lacks the necessary elements required to express the domain-specific design rules AtOP can overcome this by allowing domain-specific concepts to be represented directly in the program A representative development model for MDSE/AtOP is reported in the development of a model-driven development framework, called mTurnpike [76] This framework combines AtOP with model-driven development in a top-down fashion, with an aim to define domainspecific concepts at both the modelling and programming levels More recently, a bottom-up MDSE approach is proposed in [4], which entails a formalism and a general method for defining annotation-based embedded models Behaviour Interface Specification Language BISL [5, 32, 47, 69, 71] is a class of languages for specifying software behaviour Of particular interest to this dissertation are BISLs that (i) express functional behaviour properties for object oriented source code and (ii) use some form of annotation to structure the specification These BISLs are concerned with defining a specification structure for the code model elements (e.g a Class or a Method) that can be used to capture the domain-specific requirements concerning those elements At the unit level, one specifies the behaviour for either a Class or a Method A behaviour specification includes two parts: interface definition and behaviour description The former consists in the information needed by other software units The latter specifies one or more state transformations that result from executing the behaviour The supported behaviour properties are typically concerned with the transformation from the pre-condition state to the post-condition state of a method and the consistency criteria (invariant) of class There are two popular BISLs supporting these properties that are associated with the two OOPLs Java and C# (resp.): Java Modelling Language (JML) [47] 34 and Spec# [5] Both JML and Spec# use annotation to structure the specification However, these BISLs are general-purpose languages and, as such, not define rules specifically for constructing domain models in a target OOPL Annotation-Based DSL An important problem 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 technical details of the language design itself A type of internal DSL, called annotation-based DSL, presents a solution to this problem Annotation-Based DSL (aDSL) [54] is an application of the annotation feature of modern OOPLs in DSL engineering The name “annotation-based DSL” has been coined and studied only recently by Nosal et al [54] A few years earlier, however, Fowler and White [25] had classified this type of language as “fragmentary, internal DSL” Nosal et al defined annotation-based DSL based on three types of its composition The first type is language unification, in which annotation in the host language is used to define the domain concepts The annotation attachments help ‘unify’ the domain with the host language The second type is language referencing by extension, in which annotation in the host language defines references to the concepts in another language These references effectively extend the host language with new concepts The third type is language extension, in which annotation in the host language defines new concepts, but these concepts not exist independently from the host However, Nosal et al only provide a general framework and not provide technical insights for how to construct aDSL In particular, they not discuss how meta-modelling (such as using UML/OCL) is used to define the language syntax Further, questions can be raised about the extent to which the aDSL’s syntax matches with the abstraction level required by the domain that it expresses If the aDSL’s syntax is of the host OOPL then it inherits the abstraction gap problem, which was identified earlier by Schmidt [67] (see Section 2.1.1) Thus, more research is needed to determine the suitable abstraction levels for aDSL 2.2 Domain-Driven Software Development with aDSL The core idea of DDD is domain modelling for software development Recently, we observe, based on our detailed analysis of the foundational works [22, 62] and the state-of-the-art 35 DDD frameworks [17, 60], that a current trend in DDD is to utilise the domain model for software construction Given a domain model, other parts of software, including graphical user interface (GUI), are constructed directly from it Further, this construction is automated to a certain extent 2.2.1 DDD with aDSL In DDD, a form of annotation-based language extension of OOPL, has been used to develop the software frameworks (ApacheIsis [17, 62] and OpenXava [60]) The design rules in a domain model are expressed by a set of annotations These frameworks support the development of a software from its domain model We observe that aDSL is suited for DDD because it is a type of internal DSL that has the characteristics described earlier in Section 2.1.4 of a DSL for DDD Another reason is because the practice of using annotations has been around for quite some time, especially in AtOP, and proved useful However, the exiting DDD works mentioned above have several limitations First, they not formalise their extensions into a language Second, their extensions, though include many annotations, not identify those that express the minimal (absolutely essential) annotations Third, they not investigate what DSLs are needed to build a complete software model and how to engineer such DSLs 2.2.2 Behavioural Modelling with UML Activity Diagram In his book [22], Evans does not explicitly consider behavioural modelling as part of DDD This shortcoming remains, inspite of the fact that the method considers object behaviour as an essential part of the domain model and that UML interaction diagrams would be used to model this behaviour For example, in Chapter of the book, when discussing the use of documents and diagrams (i.e models) in the ubiquitous language, Evans states the followings: – “the attributes and relationships are only half the story of an object model But the behavior of those objects and the constraints on them are not so easily illustrated Object interaction diagrams can illustrate some tricky hotspots in the design ” – “Behavioral responsibilities of an object can be hinted at through operations names, and implicitly demonstrated with object interaction (or sequence) diagrams.” 36 In UML [57] (§13.2.1), interaction diagrams (such as sequence diagram) are only one of three main diagram types that are used to model the system behaviour The other two types are state machine (§14) and activity diagram (§15, 16) Although in the book, Evans only uses sequence diagram as an example, in the ApacheIsIs framework [17] that directly implements the DDD’s philosophy, a simple action language is used to model the object behaviour This language is arguably a specific implementation of the action sub-language (§16) of UML activity diagram It leverages the annotation construct of OOPL (see Section 2.1.7) to specify a class operation with a pre-defined behaviour type More generally in practice, UML activity diagram has been argued to be suitable for domain experts to use [20] Further, we observe that it is tightly linked to the other two UML behavioural diagrams In principle, UML activity diagram and state machine represent two sides of the same coin, while the UML activity’s action language [57] forms a basis in interaction diagram For these reasons, we will focus in this dissertation on the use of UML activity diagram for behavioural modelling To standardise the language terminology used throughout the dissertation, we will call this the (UML) activity modelling language In the remainder of this section, we will present a brief technical review of this language We apply the metamodelling approach with UML/OCL (see Section 2.1.3) to define an essential ASM of the activity modelling language The ASM, shown in Figure 2.5, is essential in the sense that it contains the core meta-concepts of the language As shown in the figure, Activity itself is a sub-type of Behaviour, which, according to §13.2.2 of the UML specification, is a sub-type of Class These mean two things: (i) activity is a type of behaviour (and thus can be used to model system behaviour) and (ii) we can model activities directly as classes in the domain model Structurally, an Activity consists of an activity graph that is made up of ActivityNodes and ActivityEdges These compositions are displayed in the shaded rectangle that lies at the heart of the ASM ActivityEdge is a binary directed edge, that consists of a source and a target ActivityNode ActivityNode and ActivityEdge are specialised into various subtypes and descendant types that together give a complete meaning to the activity graph Meta-concept ActivityEdge defines either data or control flows and, thus, consists of two sub-types: ObjectFlow and ControlFlow (resp.) ObjectFlow (ControlFlow) models the flow of data (control resp.) tokens that pass through an edge as the result of the execution of the nodes connected to the edge The tokens are not explicitly modelled To regulate the 37 Figure 2.5: The meta-model of UML activity modelling language (Adapted from §15.2.2 of the UML specification [57]) token flow, an ActivityEdge can be associated with one guard and one weight condition Both conditions are modelled by the meta-concept named ValueSpecification A guard condition is used to filter tokens that are offered to an ActivityEdge (by the source node), while a weight condition sets the minimum number of tokens that can pass through an ActivityEdge at a time The ActivityNode’s type hierarchy defines various node types that are connected to the above two activity flow types A sub-type of ActivityNode called ObjectNode is exclusively connected to ObjectFlow Connected to ControlFlow and ObjectFlow are ExecutableNode, ControlNode and six sub-types of ControlNode These sub-types are: InitialNode, FinalNode, ForkNode, JoinNode, MergeNode and DecisionNode As of this writing, Action (§16 [57]) is the only concrete sub-type of ExecutableNode Example 2.5 In order to illustrate the activity modelling language and to understand its graphical notation (defined in the UML specification), let us consider an example in which we use this language to model the enrolment management activity of CourseMan We deliberately left out the details of this activity from the description in Section 1.1.1, so that we can discuss different modelling scenarios for it here Figure 2.6 shows the activity models of five basic variants of the enrolment management activity These models demonstrate five fundamental activity flows of the activity modelling 38 Figure 2.6: The UML activity models of five basic variants of the CourseMan’s enrolment management activity language Navigating from left to right and top to bottom, the first scenario results in what we term a sequential activity model, which demonstrates the sequential activity flow This model consists in two Actions that are performed in sequence The first action is “Register a student” and the second is “Register student into classes” There is an ObjectFlow (represented in the figure as an arrowed line) that connects the first to the second action This flow carries a Student object, which is created as the result of the first action, through to the second action The second scenario results in a decisional activity model, which demonstrates the activity flow of the DecisionNode This node is represented by a diamond and has one incoming edge and two or more outgoing edges The outgoing edges represent the alternative decision outcomes The decision input, if any, is represented by a note box connected to the decision node by a dashed, gray line Compared to the sequential model example, the decisional activity model consists of an additional Action, named “Handle help request”, which together with the action “Register student into classes” are two alternative outcome actions The 39 decision input is attribute Student.helpRequested, whose value is used by the decision node to determine if the registering Student is requesting help from the enrolment officer If help was requested then control flows through the left outgoing edge to “Handle help request”; otherwise it flows through the right edge to “Register student into classes” The third scenario results in a forked activity model, which demonstrates the activity flow of the ForkNode This node is represented in the model by a line segment with parallel, orthogonal branches, representing the incoming and outgoing edges from and to the surrounding nodes A fork node has one incoming edge and two or more outgoing edges In the example model, after performing “Register a student”, control flows into the fork node and exits out below this node, branching into two other Actions: (i) “Make payment” and (ii) “Authorise registration” The first action involves requesting the registering Student to make Payment, the second action involves an enrolment officer performing Authorisation’s routine against the Student’s registration The fourth scenario results in a joined activity model, which demonstrates the activity flow of the JoinNode In the model, this node has a similar representation to the fork node, but an opposite arrangement of the incoming and outgoing edges Specifically, it has one outgoing edge and one or more incoming edges In the example model, the join node joins two Actions (“Make payment” and “Authorise registration”) before passing control to action “Approve enrolment” This action decides whether to accept or reject the enrolment The fifth and final scenario results in a merged activity model, which demonstrates the activity flow of the MergeNode In the model, this node has a similar diamond-representation to the decision node, but an opposite arrangement of the incoming and outgoing edges from and to the surrounding nodes Specifically, it has two or more incoming edges and one outgoing edge In the example model, the merge node merges the action “Register student into classes” with the action “Attend orientation” such that they both end in an action named “Conclude enrolment” Here, “Attend orientation” means to attend an orientation program for new students 2.2.3 Software Module Design Traditionally, in object oriented software design [48, 49, 51], it is well understood that large and complex software requires a modular structure According to Meyer [51], software module is a self-contained decomposition unit of a software Meyer suggested that, in an 40 OOPL, module be represented by class For large and complex software that is developed using the DDD method, the domain model needs to be designed in such a way that can easily cope with the growth in size and complexity After all, tackling domain modelling complexity is the main objective of DDD As discussed in Section 2.1.4, Evans [22] proposed using the pattern modules to group closely-related domain classes In this section, we use the term “domain module” instead of Evan’s module in order to make a distinction with “software module” In object oriented design language terminology [57], a domain module is a package According to the general software design wisdom [48, 49], a domain model should have the quality of high cohesion and low coupling To the best of our knowledge, although the existing works in DDD [17, 22, 60, 62, 75] support domain module, they not address how to use it to form software module Further, they not consider modules as first-class objects and, thus, lack a method for their development Not only that, they not precisely characterise the software that is developed from the domain model These shortcomings would surely hinder DDD adopters in their efforts to apply the method in practice From the OOPL’s perspective, a recent development in Java [29] introduces a modulebased design for Java software A Java software module is more than a class or a package It is a named, configurable group of one or more related packages The primary aim is to provide stronger code encapsulation [37, 61] that would help ease the construction of large software More specifically, instead of the usual keyword class that is used to define data types, Java module configuration is defined with the keyword module and is written in a special Java file Each configurable element is written in a code statement of the module’s body However, Java software module has a number of limitations First, it only supports module configuration and not the module concept Second, it does not provide a mechanism for defining a domain-specific module structure Third, module configuration requires a different syntax from the one used to write standard Java programs This increases learning and requires additional tool support Fourth, the module syntax is not easily extendable 2.2.4 Module-Based Software Architecture In this dissertation, we adopted a module-based software architecture (MOSA), which we developed in a previous work [45], for software development in DDD We chose MOSA because it was developed based on the MVC architecture and specifically for domain-driven 41 software development MOSA is inherently module-based In this section, we will review the key concepts of MOSA and illustrate them using CourseMan MOSA realises the DDD’s layered architecture (discussed in Section 2.1.5) It positions the domain model at the core and (currently) incorporates the UI concern into a layer around this core A software module in MOSA forms a micro, functional software The modules can be combined to form a complete software MOSA is built upon two key concepts: MVC-based module class and module containment tree Definition 2.6 Module class is a structured class [57] that describes the structure of modules in terms of three MVC components: model (a domain class), a view class and a controller class Given a domain class C, the view and controller classes are the parameterised classes View T → C and Controller T → C (resp.); where View T and Controller T are two library template classes, T is the template parameter To ease discussion, we name a module class after its domain class, using the prefix “Module”; e.g ModuleStudent is a module class created from Student Further, we use the notation View C to denote the view of a ModuleC Now, every module class has a state scope, which is a sub-set of the attributes of the domain class that are relevant to the module Relevancy is determined based on the module’s specification Module classes in a MOSA model are associated by virtue of the fact that their domain classes are associated in the domain model These associations form the basis for module containment and containment tree Module containment is a relation on the set of modules Containment tree is a rooted tree that results from combining the module containments of a composite module Definition 2.7 Given two domain classes C and D, a module M = ModuleC (called composite module) contains another module N = ModuleD (called child module), if – C participates in a binary association (denoted by A) with D – C is at the one end (if A is one-many), at the mandatory one end (if A is one-one) or at either end (if otherwise) – Exists a subset of N ’s state scope, called containment scope, that satisfies M ’s specification 42 Definition 2.8 Containment tree is a rooted tree that has the following structure: – Root node is a composite module (called the root module) Other nodes are descendant modules that are contained directly or indirectly in the root module – Tree edge from a parent node to a child node represents a module containment Example 2.6 The bottom part of Figure 2.7 shows a more detailed sub-model of the CourseMan’s domain model presented in Figure 1.1 This sub-model, which is created in the package courseman.model, consists of five classes and three new associations For brevity, we exclude attributes and operations from the class boxes The first two associations associate EnrolmentMgmt to Student and SClass, the third associates Student to HelpRequest Figure 2.7: The MOSA model of CourseMan The entire Figure 2.7 is a MOSA model of CourseMan It is drawn using the graphical notation described in [45] A binding is depicted by a dashed line, whose Controller’s end is drawn with the symbol ‘ ’ The model consists of four module classes Among these, ModuleEnrolmentMgmt is a composite module, whose containment tree first contains a child module ModuleStudent (because of the one-many association from EnrolmentMgmt to Student) This child module would in turn be the parent of a ModuleCourseModule if Student is preferred to CourseModule over the many-many association between them The state scope of ModuleStudent includes two attributes Student.id, name and another attribute, named modules, that realises the Student’s role in the many-many association to CourseModule The containment scope of ModuleStudent in the containment tree of 43 ModuleEnrolmentMgmt is the same as its state scope In the containment trees of other modules (e.g ModuleClass’s), however, ModuleStudent’s state scope may contain only a proper subset of the state scope Module Configuration Method We view module configuration at two levels [45] At the module level, a configuration specifies the model, view and controller components of the module class If the module is composite then the configuration also specifies the containment tree At the component level, the configuration specifies properties of each of the three components First, the model configuration specifies properties of the domain class (the model) Second, the view configuration specifies such properties as the view’s layout and the label, style and dimension of view fields There are two types of view field: subview and data field A subview is a container containing other view fields A subview presents the view of a descendant module A data field, on the other hand, is a non-composite component, which does not contain other view fields Third, the controller configuration specifies behavioural properties of the controller through a set of basic actions that are performed in response to the user commands In particular, the controller configuration specifies the default action that is executed when the view is first displayed Further, it specifies the policy for an open action, which is executed when the user performs the data openning command This action connects to the object store of the domain class and prepares the view ready for user to start manipulating the stored objects Other controller actions are also supported Example 2.7 To configure ModuleEnrolmentMgmt of CourseMan, whose view is shown in Figure 2.8, we first need to specify three components: model := EnrolmentMgmt, view := View EnrolmentMgmt and controller := Controller EnrolmentMgmt In addition, since this module is composite we need to specify a containment tree which details the containment scopes of the modules of Figure 2.8: A ModuleEnrolmentMgmt’s view the following three domain classes that are containing a child ModuleStudent’s view 44 associated to EnrolmentMgmt: SClass, Student and HelpRequest As for the three component configurations, the model configuration contains the model property specified above The view configuration specifies that the overall layout is a tab layout In addition, it contains labels for the three view fields that render three associative fields that realise EnrolmentMgmt’s ends of the associations to the other three domain classes The labels are used to name the three tabs shown in the figure Each view field is a subview that displays the view of one child module For instance, the subview shown in the figure displays the view of a child module that is typed ModuleStudent This subview contains four view fields that render four attributes of Student (id, name, helpRequested and modules) that are listed in ModuleStudent’s containment scope These four view fields are data fields The controller configuration in this case does not require any specific customisation 2.3 Summary In this chapter, we reviewed the concepts, methods, techniques and tools that are relevant to the research problem of this dissertation Our exposition helps paint a knowledge map of the relevant and connected works in three main areas of related work: MDSE, DDD and OOPL We identified aDSL to be the underlying research thread that connects these areas To understand aDSL, we reviewed it in a broader context of annotation usage in MBSD A key observation that we can draw from our review is that there is a need to extend existing OOPLs with more expressive power, with an aim to bridge the conceptual gap with the high-level modelling languages (such as UML/OCL) that are commonly used to express the domain model Intuitively, this extension makes sense and is necessary if OOPL is to become the preferred executable language of choice for the domain model A general approach that the state-of-the-art approaches in aDSL takes to address this need is to leverage the annotation meta-concept to define a set of domain-specific annotations and combine these with other non-annotation meta-concepts However, we argued that there are still significant open issues in two main problem areas The first area concerns what an ‘essential’ aDSL is and how it can be used to express both the structural and behavioural aspects of the domain model The second concerns how to modularly construct the software from the domain model In particular, how we can also leverage aDSL for this construction The rest of the dissertation will present our contributions for these two problem areas 45 Chapter Unified Domain Modelling with aDSL In this chapter, we describe our first two contributions concerning unified domain (UD) modelling Taking the view that domain class design is the basis for unified domain model (UDM) construction, we first specify a horizontal aDSL, called DCSL, for expressing the essential structural and behavioural features of the domain class We discuss how DCSL enables an automatic technique for constructing the domain class design specification We then use DCSL to define UDM In this, we present a set of generic UD modelling patterns that can be used to construct UDMs for real-world problem domains 3.1 Introduction In principle, UDM extends the traditional domain model (proposed by Evans [22]) with elements that capture the state-specific structure of the activity modelling language It is clear that an aDSL for expressing the UDMs of different real-world domains needs to be a horizontal DSL Ideally, the underlying modelling patterns that are expressed in this language would cover both structural and behavioural modelling aspects This is achievable if we learnt from Chapter how UML/OCL was used as a horizontal, high-level meta-modelling language to define the abstract syntaxes of both structural and behavioural modelling languages We argue that, at the lowest level of abstraction, the desired aDSL’s scope would reuse all the OOPL’s meta-concepts (see Section 2.1.7) and focus on defining the commonly-used constraints and behaviour types that are often imposed on instances of these meta-concepts in a domain model For example, a common constraint that is often imposed on a class 46 (e.g Student) is whether or not it is (i.e all objects of the class are) mutable A similar constraint that is often imposed on a field (e.g Student.name) is whether or not it is mutable An example of a behaviour type is setter, which is assigned to a method (e.g Student.setName) that updates the value of a mutable field using some input argument(s) There are three main questions facing the design of such aDSL The first question concerns the constraints and behaviour types that are accepted as being essential The second concerns the represention of these constraints and behaviour types as meta-concepts in an aDSL The third question concerns the meta-modelling language used to specify the aDSL Existing works in DDD [17, 22, 60] have addressed the second question by using annotations to represent constraints and behaviour types However, they have so far not tackled the first and third questions In this chapter, we will define a horizontal aDSL, named Domain Class Specification Language (DCSL), to address all three questions An added benefit of DCSL is that it enables a techique to automatically generate the complete domain class specification from just the state space specification The rest of the chapter is structured as follows Section 3.2 defines the domain of DCSL Section 3.3 specifies the abstract syntax of DCSL using UML/OCL Section 3.4 presents the static semantics of DCSL Section 3.5 discusses the dynamic semantics of DCSL Section 3.6 uses DCSL to define UDM and a set of generic UD modelling patterns Section 3.7 concludes the chapter 3.2 DCSL Domain The DCSL’s domain is a horizontal (technical) domain that is described in terms of the OOPL meta-concepts and a number of essential state space constraints and essential behaviours that operate under these constraints 3.2.1 Essential State Space Constraints The structural constraint examples listed in Section 1.1.2 are examples of 11 types of constraints that, in our view, are essential to the conception of domain class Together, they help practically shape the state space of domain class and, thus, make it suitable for domain modelling real-world software In the remainder of this dissertation, we will use the term 47 state space constraints to refer to the constraints, and the term domain state space1 (or state space for short) to refer to the state space restricted by them The state space defines the valid object states at any given point in time Table 3.1: The essential state space constraints Constraints Object OM mutability Field FM mutability Field FO optionality FL FU IF YV XV TF YL XL Field length Field uniqueness Id field Min value of a field Max value of a field Auto field Min number of linked objects Max number of linked objects Type Boolean Boolean Boolean Non-Boolean Descriptions Whether or not the objects of a class are mutable [48, 49] Whether or not a field is mutable (i.e its value can be changed) [34] Whether or not a field is optional (i.e its value needs not be initialised when an object is created) [34] The maximum length (if applicable) of a field (i.e the field’s values must not exceed this length) [34] Boolean Whether or not the values of a field are unique [34] Boolean Whether or not a field is an object id field [34] The value (if applicable) of a field (i.e the field’s values must not be lower than it) [34] The maximum value (if applicable) of a field (i.e the field’s values must not be higher than this) [34] Whether or not the values of a field are automatically generated (by the system) [34] Non-Boolean Non-Boolean Boolean Non-Boolean The minimum number of objects to which every object of a class can be linked [57] Non-Boolean The maximum number of objects to which every object of a class can be linked [57] Table 3.1 lists the names and natural language descriptions of the constraints, together with reference(s) to the works in which they are discussed or used For the sake of exposition, we group the constraints into two types: (i) boolean constraint and (ii) non-boolean constraint The type of each constraint is indicated in the table 3.2.2 Essential Behaviour Types An essential behaviour type specifies a pattern of behaviour that is essential for each domain class baring the essential state space constraints stated above to differentiate from the term “system state space” used in formal methods 48 Table 3.2: The essential behaviour types Names Type names Required constructor RequiredConstructor Object form constructor ObjectFormConstructor Auto-attribute value generator Link count getter Link count setter Link adder Link adder new Link remover AutoAttributeValueGen LinkCountGetter LinkCountSetter LinkAdder LinkAdderNew LinkRemover LinkUpdater LinkUpdater Getter Setter Getter Setter Descriptions creates a new object whose state is initialised to hold values only for the non-optional fields This is the absolute minimum constructor behaviour creates a new object whose state is initialised to hold values for both optional and non-optional fields This behaviour is needed to handle object-creation requests from the user generates a new value for an auto-field observes the current number of object links that an object has with objects of another class sets the current number of object links that an object has with objects of another class adds an object link to an object of another class adds an object link to a newly-created object of another class removes an object link to an object of another class update an object based on changes to a linked object of another class observes the value of a field sets the value of a field In order to identify the behaviour types, we analysed the state space constraints in Table 3.1 in the context of these three core operation types [49]: creator, mutator and observer We then specialised these operation types for the constraints to yield the 11 essential behaviour types listed in Table 3.2 Each behavioural type is characterised by a type name and two essential attributes that are used to specify the pre- and post-conditions of the behaviour We say that the behaviour types form the behaviour space of a domain class This space concerns with the allowable changes in the object state that occur over time 3.3 DCSL Syntax In this section, we specify the syntax of Domain Class Specification Language (DCSL) In our specification, we will focus on the ASM This ASM includes the core OOPL metaconcepts described in Section 2.1.7 and a number of annotations (called meta-attributes) that express the essential state space constraints and the essential behaviour types that were 49 Figure 3.1: The abstract syntax model of DCSL described previously in Section 3.2 The concrete syntax is a subset of that of the host OOPL, which is applied to the meta-concepts in the ASM Definition 3.1 A meta-attribute AT is an annotation whose properties structurally describe the non-annotation meta-concepts T to which it is attached Figure 3.1 shows an UML/OCL model for the ASM It consists of five core meta-attributes, one auxiliary annotation and three enums The five meta-attributes are DClass{Class} , DAttr{Field} , DAssoc{Field} , DOpt{Method} and AttrRef{Method, Parameter} The auxiliary annotation is Associate The two enums AssocType and AssocEndType specify the association type and end type (resp.) The enum OptType captures the type names of the 11 essential behaviour types Graphically, an annotation is represented in the figure by a 2-compartment class box; a property is represented by a class field The default value of a property (if any) is written within brackets and appears after the property type 50 The two meta-attributes DClass and DAttr together possess properties that directly model the first nine state space constraints listed in Table 3.1 The other two constraints (YL and XL) are modelled by the third meta-attribute named DAssoc The remaining two meta-attributes (DOpt and AttrRef) model the essential behaviour of Method To model YL and XL, we design DAssoc to capture the association link context within which these two constraints are applied The base property is DAssoc.associate (type: Associate), which captures the associated class (property Associate.type), together with the range of the number of linked objects of this class This range is specified by the two properties Associate.cardMin (for YL) and cardMax (for XL) In addition to these, we also introduce a number of other contextual properties that are required to identify the different associations realised by the same class These include property DAssoc.ascName, which specifies the association name, property ascType (type: AssocType, specifying three association types: OneOne, OneMany and ManyMany), property role (specifies the role of the link end) and property endType (type: AssocEndType, specifying two link end types: One and Many) Meta-attribute DOpt in Figure 3.1 is used to specify the method behaviour, while metaattribute AttrRef is used to specify the reference to a field whose value is manipulated by a method Property DOpt.type defines the behaviour type, which is taken from the values captured by the enum OptType Two properties requires and effects express the pre- and post-conditions of a method The expression language used for these two conditions is OCL and we will explain more about these in Section 3.3.1 Example 3.1 (CourseMan specification) Listing 3.1 shows a complete DCSL specification of the class Student of CourseMan, written in Java Listing 3.2 shows a partial DCSL specification for the domain class Enrolment This specification omits the behavioural specification We will use both listings to illustrate DCSL and to explain a graphical notation that we use for its specifications in the remainder of this dissertation As shown in Listing 3.1, class Student is specified with DClass.mutable = true, because at least one of its domain fields (name) is mutable The domain field name is mutable (DAttr.mutable = true), not optional (DAttr.optional = false) and has max length (DAttr.length) = 30 The domain field id is an identifier field (DAttr.id = true), whose value is automatically generated (auto = true) The former also means that id is not optional, while the latter means that this field is immutable Finally, the domain field enrolments is an associative field Its DAssoc assignment specifies that the field realises 51 the one end of a one-many association to the associate class Enrolment (Associate.type = Enrolment) The and max cardinalities of the Enrolment’s end are and 30 (resp.) Listing 3.1: Specification for the domain class Student in Java @ DClass ( mutable = true ) public class Student { /* ** STATE SPACE * */ @ DAttr ( name = " id " , type = Type Integer , id = true , auto = true , mutable = false , optional = false ) private int id ; @ DAttr ( name = " name " , type = Type String , mutable = true , optional = false , length =30) private String name ; 10 11 12 13 14 15 @ DAttr ( name = " enrolments " , type = Type Collection ) @ DAssoc ( ascName = " std - has - enrols " , role = " std " , ascType = AssocType One2Many , endType = AssocEndType One , associate = @Associate ( type = Enrolment class , cardMin =0 , cardMax =30) ) private Collection < Enrolment > enrolments ; private int enrolmentCount ; private static int idCounter ; 16 17 18 19 20 21 /* ** BEHAVIOUR SPACE ( partial ) * */ @ DOpt ( type = DOpt Type ObjectFormConstructor , requires = " n null and n size () idCounter then idCounter = id and result = id " + " else result = id endif endif " ) @ AttrRef ( " id " ) private static int genId ( Integer id ) ; 29 30 31 32 33 34 35 36 37 38 // add links ( this , e ) for all e in enrols @ DOpt ( type = DOpt Type LinkAdder , requires = " enrolmentCount + " + " enrols - > select ( o | enrolments - > excludes ( o ) ) -> size () asSet () -> union ( enrols - > asSet () ) " + " and enrolmentCount = enrolmentCount@pre + ( enrolments - > size () - " + " enrolments@pre - > size () ) " ) @ AttrRef ( " enrolments " ) public boolean addEnrol ( Collection < Enrolment > enrols ) ; 39 52 40 // add link ( this , e ) @ DOpt ( type = DOpt Type LinkAdder , requires = " if enrolments - > excludes ( e ) then enrolmentCount + asSet () -> union ( Set { e }) and " + " enrolmentCount = enrolmentCount@pre + ( enrolments - > size () enrolment@pre - > size () ) " ) @ AttrRef ( " enrolments " ) public boolean addEnrol ( Enrolment e ) ; 41 42 43 44 45 46 47 48 // remove link ( this , e ) for all e in enrols @ DOpt ( type = DOpt Type LinkRemover , requires = " enrolmentCount - " + " enrols - > select ( o | enrolments - > includes ( o ) ) -> size () >= " , effects = " enrolments = enrolments@pre - > asSet () - enrols - > asSet () and " + " enrolmentCount = enrolmentCount@pre - ( enrolments@pre - > size () - " + " enrolments - > size () ) " ) @ AttrRef ( " enrolments " ) public boolean removeEnrol ( Collection < Enrolment > enrols ) throws C o n s t r a i n t V i o l a t i o n E x c e p t i o n ; 49 50 51 52 53 54 55 56 57 58 59 // remove link ( this , e ) @ DOpt ( type = DOpt Type LinkRemover , requires = " if enrolments - > includes ( e ) then enrolmentsCount - >= else true endif " , effects = " enrolments = enrolments@pre - > asSet () - Set { e } and " + " enrolmentCount = enrolmentCount@pre - ( enrolments@pre - > size () - " + " enrolments - > size () ) " ) @ AttrRef ( " enrolments " ) public boolean removeEnrol ( Enrolment e ) throws ConstraintViolationException ; 60 61 62 63 64 65 66 67 68 // getter for name @ DOpt ( type = DOpt Type Observer , effects = " result = name " ) @ AttrRef ( " name " ) public String getName () ; 69 70 71 72 // setter for name @ DOpt ( type = DOpt Type Mutator , requires = " n null and n size () students ; 15 16 17 @ AttributeDesc ( label = " helpDesks " ) private List < HelpRequest > helpDesks ; 18 19 20 @ AttributeDesc ( label = " sclassRegists " ) private Collection < SClassRegistration > sclassRegists ; 21 22 4.6 } Summary In this chapter, we presented a module-based approach for constructing software from the UDM We first characterised the software in terms of four essential properties Two of these properties (instance-based GUI and model reflectivity) arised specifically from the need to construct software from the UDM The other two properties (modularity and generativity) were derived from well-known design properties After that, we focused on a key step in software development, which concerns creating software modules from the UDM Taking the view that a module is an object of a module class and that this class is constructed from three component classes (model, view and controller) and a module configuration, we defined an aDSL named MCCL for defining the module configuration classes (MCCs) We specified the ASM and CSM of MCCL using UML/OCL class diagrams and discussed the language semantics Futhermore, to ease the construction of MCC, we presented an algorithm (MCCGen) for automatically generating the owner MCC of a domain class We argue that MCCL helps treat module configurations as first-class objects, making their development and maintenance easier Further, the MCCs are reusable to create different software variants But to what extent does MCCL and MCCGen help to achieve the aim of module-based software construction? The answer will come in the next chapter when we evaluate the technical contributions of the dissertation The content of this chapter is published in the following papers (listed in the Publications section) The software characterisation scheme is published in the SCIE journal paper MCCL and the associated generator are published in two conference papers and and in the SCIE journal paper 118 Chapter Evaluation In this chapter, we present our evaluation of the contributions made in this dissertation We first describe an implementation of the research contributions as components in the jDomainApp framework We then describe a real-world software development case study which we have developed using the implemented components After that, we present two separate evaluations: one is for DCSL and the other is for module-based software construction with MCCL We conclude each evaluation with a number of discussion points 5.1 Implementation In order to evaluate our claims about UD modelling and module-based software construction and to ease the adoption of our contributions in developing real-world software projects, we implemented DCSL, MCCL and the generators and tools associated with these aDSLs as components of the jDomainApp framework The implementation language is Java version In addition, we use a number of third-party libraries to handle basic language manipulation tasks To ease discussion, we will refer to the UDM generally as “domain model” 5.1.1 UD Modelling Because DCSL plays the central role in our method, we implemented this language as part of the modelling component of jDomainApp As for the BSpaceGen function, we implemented it as an add-on component of jDomainApp Developers who wish to use this component would import it into their projects as a library 119 Our implementation uses the following core third-party libraries: – JavaParser [73]: to parse the Java code model of the domain model into a syntax tree for manipulation – Eclipse’s libraries for OCL [30] and EMF [21]: to generate and validate the OCL preand post-conditions of the domain methods A documentation of our implementation together with its demonstration with the CourseMan example is available online1 In this document, we also describe how to generate and execute the CourseMan software examples of the UDM patterns discussed in Section 3.6.2 Further, we implemented a software tool, named DomainAppTool, whose aims are twofold: (i) to enable the use of DCSL in developing the domain model and (ii) to provide a basic level of support for the three phases of the DDDAL method In principle, the tool takes as input a (possibly incomplete) domain model and automatically generates a set of software modules and a GUI-based software composing of these modules For this reason, the tool can be used in early development runs of the DDDAL method to construct the domain model Specifically, DomainAppTool enables the three key stakeholders of the DDDAL process to collaboratively and iteratively build a domain model The designer uses the tool to iteratively work with the domain expert to capture the domain requirements in the model The programmer participates in the iterations by initially coding the domain model in DCSL and subsequently updating it, based on changes to the requirements that she has received from the domain expert The model is processed automatically by the tool to generate the software In each iteration, the tool automatically generates an interactive software prototype directly from the domain model This software’s GUI shows an object form that realises a module’s view and a desktop for organising these forms The object form provides an interface for the user to view and to manipulate the domain objects of a domain class For example, Figure 5.1 shows a partial software GUI of CourseMan, which is generated by the tool It includes object forms for three domain classes: Student, SClass and SClassRegistration We have been using DCSL and DomainAppTool to teach in a software engineering course module at the Faculty of IT2, Hanoi University In teaching, students and teachers play the stakeholders’ roles https://github.com/vnu-dse/dcsl http://fit.hanu.vn 120 Figure 5.1: A partial CourseMan’s GUI that is generated by DomainAppTool 5.1.2 Module-Based Software Construction We implemented MCCL as part of the module modelling component of jDomainApp We implemented MCCGen as an add-on component of jDomainApp This implementation also uses JavaParser to parse an MCC into a syntax tree for manipulation A documentation of our implementation and a demonstration with the CourseMan example is available online In addition to MCCGen, we also implemented a software generator in jDomainApp This generator generalises the functionality provided by DomainAppTool It basically takes as input a set of MCCs that are defined from a domain model and generates as output a software We use this software generator to generate all the software examples that are used this dissertation https://github.com/vnu-dse/mccl 121 5.2 Case Study: ProcessMan In this section, we present a relatively complex case study, named ProcessMan (process management) The aim is to investigate how our proposed DDDAL method would help a university faculty to effectively manage its organisational processes A key objective is to construct a process model and an MCC model that are sufficiently expressive for the faculty’s purpose 5.2.1 Method According to Runeson and Höst [66], case study research (CSR) is “an empirical method aimed at investigating contemporary phenomena in their context” CSR is applicable to software engineering because software development activities are performed by human stakeholders under different conditions, especially where the boundaries between the phenomena and contexts are unclear The type of case study that we conduct is explanatory In particular, we seek a confirmation for the applicability of DDDAL to relatively complex, real world environments The subsequent subsections will report the method’s steps and findings 5.2.2 Case and Subject Selection We chose the Faculty of IT (FIT) at Hanoi University4 as the case for investigation FIT is a relatively young faculty that has been undergoing significant organisational changes One of these changes involves standardising the organisational processes in accordance with the ISO’s quality management standard5 We thus chose organisational process management as the particular subject of our investigation As an educational institution, the core processes that FIT performs are teaching subjects (a.k.a course modules) to students every semester and formally assessing the students’ performances Conceptually, a process is a sequence of tasks, each of which is a sequence of actions A process is created once, by an organisation unit, and is periodically applied to the same unit and possibly to other organisational units that have similar needs For certain processes, task and action would need to be specialised in order to specify more details For example, in the assessment process, a subject is created only once but is taught in the same http://fit.hanu.vn/course/index.php https://www.iso.org/iso-9001-quality-management.html 122 semester every year This periodic delivery of a subject is called subject-by-semester The type of tasks that is applied specifically to subject-by-semester is called task-for-subject Each task-for-subject consists of a sequence of action-for-subject, which is a specialisation of action 5.2.3 Data Collection and Analysis Because of the nature of DDDAL, data collection and analysis for the case study naturally coincide with software requirement capturing and analysis (resp.) We collected qualitative data, which include technical documents that describe and expert opinions about the processes For these two data types, we applied two requirement capturing techniques: document review and semi-structured interview (resp.) We obtained the process documents directly from their authors, which are also members of the teaching staff To obtain further information about the documents, we conducted informal interviews with the document authors and, in some cases, with the faculty’s dean We analysed the requirements using DDDAL, with the help of the software tool described in Section 5.1 In the CSR’s terminology, our analysis follows the template approach [66], whereby the collected data are coded using pre-defined domain- and module-specific terms The coded data is used to construct the domain and MCC models Further, the analysis is performed iteratively until both models are satisfactory (as explained in Section 1.3) 5.2.4 Results Our analysis results in a domain model and an MCC model, which we will describe in this section In addition, we will discuss threats to the validity of our approach Process Domain Model Figure 5.2 shows the domain model that expresses the ProcessMan’s requirements The model consists of four domain modules, which are represented in the figure as four packages These domain modules are all named model, each of which is placed inside the directory structure of a software module To ease discussion, we will refer to the domain module by the software module’s name The software module’s name is written in the figure in brackets, that appear below the domain module For example, the domain module processstructure 123 Figure 5.2: ProcessMan’s domain model (shown at the top-right of the figure) is placed in the package processstructure.model of the software module named processstructure As shown in the figure, the domain module processstructure consists of three domain classes (Process, Task, Action) that together describe the general structure of a process, and two other domain classes (Task4Subject, Action4Subject) that describe a specialised structure for the teaching and assessment processes Task4Subject specialises Task, while Action4Subject specialises Action The reason that we only specialise Task and Action and not Process is because class Process suffices for use as a common abstraction for all types of processes At the process level, there is no real distinction between the processes The domain module processapplication consists of four domain classes: two of which (OrgUnit and ProcessApplication) represent the periodic application of a Process, while the other two (SubjectTask and SubjectAction) serve as intermediate classes that resolve the two many-many associations between Task4Subject and Action4Subject and SubjectBySemester (resp.) Note that class OrgUnit plays another role, which is the creator 124 of a Process The two classes SubjectBySemester and Subject belong to the domain module teaching The former represents the periodic delivery of the latter in a semester of each academic year Last but not least, the domain module hr (which stands for “human resource”) contains a class named Teacher, which is one of numerous types of domain users that are managed by the system Teacher has a many-many association to SubjectBySemester, which models the ownership of each subject delivery by a teacher MCC Model Figure 5.3: A partial MCC Model for process structure In ProcessMan, MCCs are created and managed within each domain module’s boundary Each domain class in a domain module is used to create one MCC The MCCs are placed in the software module’s package (which is at the same level as the module’s model package) The owner MCC of a domain subclass is modelled as a subclass of the owner MCC of the domain superclass This helps not only promote configuration reuse but ease configuration extensibility To illustrate, the left hand side of Figure 5.3 shows five MCCs of the domain module processstructure Among these, two pairs are the subject of 125 subclass-superclass association: ModuleTask4Subject is a subclass of ModuleTask and ModuleAction4Subject is a subclass of ModuleAction Using the DDDAL’s software tool and iterative analysis, we were able to incrementally construct and verify the domain and MCC models with the domain experts Thus, we conclude, with a high degree of confidence, that DDDAL is applicable to ProcessMan Threats to Validity We organise threats according to the following four categories of validity that were suggested by Runeson and Höst [66]: construct validity, internal validity, external validity and reliability Construct validity This is the extent to which “ the operational measures that are studied really represent what the researcher have in mind and what is investigated according to the research questions” In our case study, we have assumed that there are no misinterpretations of the process requirements that would lead to unsatisfactory representations in the models Our DDDAL (see Section 1.3) helped mitigate the threat of misinterpretation by allowing software protototypes to be constructed quickly and incrementally from the models Using these prototypes, the domain experts can intuitively work with the technical team to verify the models against the process requirements Internal validity This refers to the extent to which causal relations between the investigated factors are carefully examined DDDAL, being a DDD method, assumes that a software’s core is its domain model However, there may be other aspects of the software (e.g concerning such non-functional requirements as security, distributed processing, usability and the like) that also need to be taken into consideration Indeed, the stake-holders involved have suggested that security and usability are two aspects that are particularly relevant to ProcessMan We argue that DDDAL can potentially mitigate this threat because the base MOSA architecture is extensible with new layers that express the new requirement types Further, MCCL is easily extensible to support new annotations that realise the configuration concerning these types External validity This is the extent to which the findings can be generalised and be of interest to other cases that have similar characteristics This is a threat to our case study because it was carried out over just one case We would argue, however, that our choice of the generic process model within this case would help mitigate the threat To the best of 126 our knowledge, the process document was developed in accordance with the ISO standard, making it possible to generalise the resulted models for other cases that adopt the same standard Reliability This refers to the reliability of the data collection and analysis that were performed Ideally, these should be reliable to the extent that if replicated (typically by another researcher) then the same result would be obtained A threat to the reliability in our approach arises from the fact that the process document that we collected had not formally been certified by an ISO-certification agency As such, it may not completely conform to the ISO standard We would thus argue that an application of our approach to an ISO-certified process environment may require some adjustments to the data collection and/or analysis (e.g more data would need to be collected and a combination of analysis techniques may need to be applied) 5.3 DCSL Evaluation As far as UD modelling is concerned, within the scope of this dissertation, we focus on evaluating DCSL We first discuss the overall evaluation approach that we adopt for DCSL After that, we present the evaluation results We conclude with a number of discussion points concerning the language and its use in software design 5.3.1 Evaluation Approach We evaluate DCSL from two main perspectives: language and generative capability Language Evaluation We consider DCSL as a specification language and adapt from [42] the following three criteria for evaluating it: expressiveness, required coding level and constructibility Constructibility is evaluated separately from the other two criteria We use DCSL’s terms as the base for evaluation because, as will be explained shortly below, they correspond to the essential terms that are used in the relevant modelling and OOPL literatures and there has been no other annotation-based DSL that supports a similar set of terms We discuss how the DCSL’s concepts and terms are mapped to the DDD patterns 127 Table 5.1: The expressiveness aspects and domain properties of interest Aspects Structural modelling Behavioural modelling Language definition Domain properties four DCSL’s terms (see Definition 3.2): domain class, domain field, associative field and domain method activity domain class (see Definition 3.9) constraint, structural mapping Further, we compare DCSL to the annotation-based extensions of two DDD frameworks and to the commonly-used third-party annotation sets To ease notation, we label the annotationbased extensions of the frameworks as follow: ApacheIsis [17] is labelled AL and OpenXAVA [60] is labelled XL Our approach is to analyse the relevant technical documentations of AL, XL and DDD patterns to identify the language constructs that are either the same as or equivalent to the primitives or combinations thereof that make up each DCSL’s term We also made an effort to quantify the correspondences Expressiveness This is the extent to which a language is able to express the properties of interest of its domain [42] Within the scope of this dissertation, we are interested in the essential properties of the domain We first argue for the minimality (a.k.a essentiality) of DCSL We then use this as the basis to structure the expressiveness evaluation around DCSL More specifically, we consider three modelling aspects and within each identify the domain properties of interest Table 5.1 lists the aspects and properties A single expressiveness criteria that we use to judge each property is coverage Required Coding Level Required coding level (RCL) is the extent to which the language allows “ the properties of interest to be expressed without too much hard coding” [42] Based on the expressiveness evaluation result, we judge RCL based on three domain properties, which coincide with following three domain terms that are supported by DCSL, AL and XL: domain class, domain field and associative field In addition, we use two criteria to measure the RCL for each domain property: max-locs (max number of lines of code) and typical-locs (typical number of locs) The lower the values of these the better Because DCSL, AL and XL are all internal to a base OOPL, we 128 consider annotation property as a loc Thus, max-locs (resp typical-locs) is the maximum (resp typical) number of properties needed to express a typical domain term The typical number of properties include only properties that either not have a default value or are typically assigned to a value different from the default For example, to specify in DCSL a typical domain field (say Student.name) maximally (resp typically) requires these (resp one of these) three DAttr’s properties: length, min, max Constructibility This is the extent to which the language provides “ facilities for building complex specifications in a piecewise, incremental way”[42] For DCSL, we define constructibility as generative capability for domain modelling and discuss this separately in the next section Generative Capability The objective of this evaluation is to measure the extent to which DCSL supports UDM generation We emphasise that this is generativity of the domain model, which is different from the software generativity property discussed in Section 4.2.5 Specifically, we evaluate function BSpaceGen (defined in Section 3.4.3) with respect to two properties: behaviour generation and performance The performance criteria that we use is time complexity, which was established for BSpaceGen in Theorem 3.2 For behaviour generation, we emphasise that the objective is about behaviour specification generation of domain method We not evaluate code generation for the method body We use two criteria: number of domain methods and quality The latter is measured in terms of the conformance to a de facto naming convention of the target OOPL (e.g JavaBean) To measure these criteria, we use Java as the target host OOPL and, for comparison, a compact CourseMan solution model that we had manually and independently developed for teaching This solution model consists of three classes (Student, Enrolment and CourseModule), which capture all the essential features of DCSL 5.3.2 Expressiveness We present in this section the evaluation of the expressiveness criterion 129 Table 5.2: (A-left) Comparing DCSL to DDD patterns; (B-right) Comparing DCSL to AL and XL Aspects Structural modelling Behavioural modelling Language definition DCSL concepts & terms Domain Class Domain Field Associative Field Domain Method Immutable Domain Class Activity Domain Class DDD patterns Entity, Domain Event, Aggregate Value Object ✓ Service Aspects Structural modelling Behavioural modelling Language definition Expressiveness criteria Domain Class Domain Field Associative Field Domain Method Activity Domain Class Constraint Structural mapping DCSL AL XL 1/1 8/8 7/7 1/1 4/8 0/7 0/1 5/8 1/7 ✓ ✓ ✓ ✓ ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘ ✘ On the Minimality of DCSL We reason that DCSL, as defined in this dissertation, is minimal with regards to the set of state space constraints and the essential behaviour that operate on them First, the state space constraints are identified, based on the authoritative system and software engineering sources [34, 48, 49, 57], as being the most fundamental Second, we have two arguments for why our proposed OptTypes constitute a minimum behaviour specification for domain class The first argument is that these OptTypes are a specialisation of three essential behavioural types defined in [48, 49], namely, creator, mutator and observer Clearly, we need at least these three types of operations in order to create and use objects at run-time The second argument is that these OptTypes are needed to accommondate the structural mapping to the aforementioned state space Comparing to the DDD Patterns The first three rows of Table 5.2(A) show a mapping between DCSL’s concepts and terms and the DDD patterns discussed in Section 2.1.4 The DCSL terms form a technical design language, which realises the high-level design structures described in the DDD patterns Specifically, the four DCSL’s terms are able to express three DDD patterns: Entity, Domain Event and Aggregate Regarding Domain Event, in particular, DCSL is able to express elements of the event management model However, DCSL does not (yet) address how the domain classes use these elements via the publish/subscribe interface operations We will investigate this as part of future work 130 Concept Immutable Domain Class in Table 5.2(A) is a special case of Domain Class in which DClass.mutable = false It is mapped to the Value Object pattern Concept Activity Domain Class is mapped to the Service pattern The last row of the table, however, shows a key difference: while we define DCSL as a design language, the DDD patterns not by themselves constitute a language Comparing to DDD Frameworks DCSL >essentially AL, XL Table 5.2(B) presents the evaluation table between DCSL and AL and XL The fractions in the table are ratios of the number of essential properties of the meta-attribute involved in a DCSL’s term/concept that are supported by AL or XL The denominator of a ratio is the total number of essential properties A detailed comparison data table is given in Appendix C.1 For example, the ratio 4/8 for AL w.r.t the term Domain Field means that AL only supports out of the total of properties of the meta-attribute DAttr (used in Domain Field) The four AL’s properties are: Column.allowsNull, Property.editing, PrimaryKey.value and Column.length Table 5.2(B) shows that DCSL is more expressive than AL and XL in both structural and behavioural modelling aspects These two languages only partially support structural modelling and they not support behavioural modelling using the activity domain class In particular, AL’s and XL’s support for Associative Field is very poor compared to DCSL Comparing to Third-Party Annotation Sets DCSL >essentially BV AL and XL support the use of third-party annotation sets, which between them include Java Persistence API (JPA) [59], Java Data Objects (JDO) [18], Hibernate Validator (HV) [64] and Bean Validation (BV) [63] BV is defined as a standard, of which HV is a reference implementation In the comparison in Table 5.2(B), we compared and contrasted DCSL with the comparable subset of the combined annotation set of the above annotation sets that are supported by AL and XL For the sake of completeness of the current comparison, we will compare DCSL to the full BV’s built-in annotation set We choose BV because it subsumes 131 HV and, similar to DCSL, it is storage-indendendent (JPA and JDO are technologies for mapping domain objects to a data source) Similar to DCSL, BV’s annotations specify constraints on class, field and method A number of built-in BV’s annotations are similar or comparable to DCSL For example, Null is expressible by DAttr.optional; Min, Max, Negative, NegativeOrZero, Positive and PositiveOrZero are expressible by DAttr.min, max; and Size (for String data type) is similar to DAttr.length The Size constraint for collection-typed field is subsumed by the property pair Associate.cardMin, cardMax of DCSL However, BV does not specify any annotations that are equivalent to the following properties of DCSL: DAttr.mutable, unique, id and auto On the other hand, BV specifies the following annotations that are not currently included in DCSL: Pattern and Email (for string type), AssertTrue and AssertFalse (for boolean type), Future and Past (for date type), and DecimalMin, DecimalMax and Digits (for numerical type) Since these annotations describe constraints that concern specific value subsets of the built-in data types, we argue that they would form an extension annotation set and be added when the need arises What we currently focus on in DCSL is the essential annotation set Apart from these, we observe three underlying limitations of BV compared to DCSL First, BV is not defined as a language As such, it is not clear what the underlying constraints mean in terms of the class structure Second, BV does not identify which constraints are essential and which are not Third, it does not modularise the annotations in terms of the state and behaviour spaces and thus lacks the identification of the structural mapping between the annotations in these two spaces This also means that, unlike DCSL, BV does not specify a technique for automatically generating the behaviour specification 5.3.3 Required Coding Level Table 5.3: (A-left) Summary of max-locs for DCSL, AL and XL; (B-right) Summary of typical-locs for DCSL, AL and XL DCSL AL XL Domain Class 2 Max-locs criteria Domain Associative Field Field Total DCSL AL XL 11 132 Domain Class 2 Typical-locs criteria Domain Associative Field Field 1 Total Tables 5.3(A) and 5.3(B) respectively show the values of max-locs and typical-locs for the three underlying DCSL’s terms that are supported by AL and XL The last columns of the tables show the total values The detailed comparison data are presented in Appendix C.2 DCSL >essentially AL, XL It can be observed from both tables that, compared to AL and XL, DCSL has the highest total max-locs (11) and typical-locs (9) However, a closer inspection shows that the DCSL’s subtotals for Domain Class and Domain Field (4 and resp.) are actually lower than the corresponding subtotals for AL (6 and 3) and XL (8 and 3) Hence, the single contributing factor to DCSL having the two highest totals is the set of mandatory properties needed to express Associative Field Since all properties are essential for representing this type of field, we conclude that the increase in DCSL’s required coding level is a reasonable price to pay for the extra expressiveness that the language enjoys over AL and XL 5.3.4 Behaviour Generation Table 5.4 presents the evaluation result of Table 5.4: BSpaceGen for CourseMan function BSpaceGen The two columns Number of methods Domain “Manual” and “Generated” show the numbers classes Generated Manual of domain methods in the CourseMan soluCourseModule 20 22 Enrolment 17 18 tion and generated models (resp.) We exclude Student 19 20 AL and XL from this evaluation because they not support behavioural generation The table shows that BSpaceGen is able to generate the behaviour specification of 100% of the domain methods in the solution model Qualitywise, the generated method headers follow the JavaBean convention Interestingly, compared to the solution model, the generated specification contains a few extra in all three domain classes of CourseMan These methods not have any domain-specific requirements Thus, the fact that the manual solution model does not contain these methods does not affect the completeness of the model For example, both CourseModule and Student are generated with a LinkUpdater-typed method named onUpdateEnrolments However, these methods not have any domain-specific logic defined for them, because neither CourseModule nor Student object state needs to be updated when a linked Enrolment is changed 133 The generative capability of DCSL is amplified by the fact that BSpaceGen is also applicable to generating the behavioural specification of the activity domain class 5.3.5 Performance Analysis Since AL and XL not support code generation, we focus our performance analysis on function BSpaceGen Based on the linear complexity result of Alg 3.1 (presented in Section 3.4.3), we conclude that BSpaceGen is practically capable of handling domain classes with large state spaces 5.3.6 Discussion Let us conclude the current evaluation with a number of remarks about the design and implementation of DCSL and its use in software design The granularity of domain method in DCSL is currently at the lowest, most basic level At this level, the domain methods are structurally mapped to a set of essential state space constraints The question then arises as to how to model more coarse-grain methods, such as those discussed in [22, 75] that realise the domain behaviours The UD modelling patterns that were discussed in Section 3.6.2 are a first important step towards addressing this question However, more research should be carried out in this direction The minimality, behaviour-essentiality and evolution of DCSL are tightly connected We judged minimality based on a set of fundamental constraint requirements and essential behaviours that are taken from a set of authoritative academic and practical resources However, we would not claim that these resources are universal to every researcher and practitioner in the field It is thus our hope that our proposed ‘minimality’ property would attract interests and feedbacks from those concerned, with an aim to come to an improved understanding Regarding to the behaviour-essentiality of DCSL We basically took the “behaviourallycomplete” property proposed in [62] for domain models in general, extracted a set of essential underlying features (called “behaviour essential”) and then used this as the starting point for DCSL This way, DCSL can be used to define many different behaviourally complete domain models As a language, DCSL starts out with only a set of essential features We expect that DCSL, as it is put into use, will evolve to incorporate more features Some of these features would surface as we investigate how to address other types of requirement 134 Domain model evolution is inevitable in real-world software development This happens specifically when the software is put into use and needs to undergo maintenance at some point Given that the software is developed using our proposed software model, software evolution can basically be handled as part of our overall DDDAL method as follows First, we identify the necessary software changes through interaction via the software GUI Then, we map out these changes (via the module layer structure of the software model) to the corresponding changes that need to be applied to the UDM However, more research need to be conducted concerning how to automate this procedure in our method 5.4 Evaluation of Module-Based Software Construction As stated in Section 4.1, existing works in DDD lack a method for software module construction Thus, we will not compare our our module-based software construction method with these works Our main objective here is to evaluate the extent to which MCCL helps automatically generate software modules To achieve this, we define a framework for developer-users of MCCL to precisely quantify module generativity for the application domains In the framework, we will identify the general module patterns and discuss how module generativity can be measured for each of them Further, we evaluate the correctness and performance of function MCCGen 5.4.1 Module Generativity Framework We first observe that the module genTable 5.5: Module pattern classification erativity procedure consists of two View Controller steps: (i) generate the MCC of the MPs Configuration Code Configuration Code module and (ii) generate the module Def Cust Cust Def Cust Cust from the MCC The first step is perM P1 ✓ ✓ formed semi-automatically by funcM P2 ✓ ✓ (✓) tion MCCGen The second step is M P3 ✓ (✓) ✓ performed semi-automatically by the M P ✓ (✓) ✓ (✓) module interpreter of jDomainApp We measure module generativity by taking a weighted average of the generativity values of these steps 135 Another observation is that the parts that need to be manually written by the developers in both steps can be identified through the module configuration in MCC This means that we can measure the generativity value of each step by the efforts taken to compose those parts We will call the parts generally by the name customised elements The customised elements in the first step are called customised configuration elements, while those in the second step are called customised components To facilitate the measurement, we further classify each type of elements by the component type: view elements and controller elements We omit the model component (the domain class) of each module from measurement because it is developed before hand Table 5.5 describes a classification of module patterns (MPs), which is based on valid customisation scenarios A valid customisation scenario correctly describes a combination of element types that need or need not be customised In the table, the former case is abbreviated as “Cust” (customised), while the latter case is abbreviated as “Def ” (default) Conceptually, an MP represents a set of module objects of one or more module classes that result from applying a particular customisation pattern on these classes The four MPs listed in the table cover the set of module objects of the module classes constructible by our method Note the followings about the MP classification First, the module objects that make up a containment tree can belong to different MPs For instance, a composite module may belong to M P1 , while its descendant modules belong to other MPs Second, we not need to consider the Def case for code because this is implied if no code customisation is performed Third, a customised configuration (of either view or controller) may require creating customised component(s) In the table, we show this causal relationship by writing (✓) in the Cust-Code column whenever we use a ✓in the Cust-Configuration column Fourth, we systematically define customised components around design patterns that extend the MOSA’s functionality This promotes code reuse and, hence, improves module generativity for new modules For controller, a customised component is a pattern-specific module action, which is an action whose behaviour is customised to satisfy a new design requirement Evans [23] proposed high-level patterns, while we defined in a recent work6 a number of concrete patterns For view, a customised component is a new view component that improves the usability of the module view This includes a view field class, a new view layout component and so on The last observation is that we can construct a shared formula for the generativity factors of both steps of the module generativity procedure The basis for this formula is that both paper listed in the Publications section 136 steps involve writing some form of code for view and/or controller (MCC is also code) Denote by V and C the amounts of code created for the view and controller components (resp.) and by V and C the amounts of customised code manually written for these same two components (resp.) That is, V + C is the amount of developer’s code input Further, let W = V + C be the total amount of code created for the view and controller Denote by m the generativity factor, then we measure m in (0,1] by the following formula: m= V +C (V − V ) + (C − C ) =1− W W (5.1) Denote by m1 , m2 the generativity factors of steps and (resp.) We use subscripts and to denote the components of m1 and m2 , resp.; e.g W1 , W2 , etc We measure the module generativity M (also in (0,1]) by taking a weighted average of m1 and m2 We compute two weights α and − α based on the relative extent of W1 and W2 : M = αm1 + (1 − α)m2 (where: α = W2 W1 ,1 − α = ) W1 + W2 W1 + W2 (5.2) In Formula 5.2, the higher the value of M , the higher the module generativity Our choice of weights means to give higher emphasis to the component (m1 or m2 ) that dominates in the impact on M In practice, the dominating factor is typically m2 , because W1 (configuration) is typically much smaller than W2 (actual code) This reflects a fact that the module generativity’s extent depends mostly on how many customised components to extend the MOSA’s core functionality that need to be created We will use Formula 5.2 as the basis to develop more specific formulas of M for the MPs We illustrate each formula and the MP(s) in question by a CourseMan software variant, that is constructed by our software tool 5.4.2 M P1 : Total Generativity In this special MP, we achieve 100% generativity, because V1 = V2 = and C1 = C2 = 0, which leads to M = m1 = m2 = A reference software that is constructed only by modules belonging to this MP is implemented by the DomainAppTool (see Section 5.1.1) The software generated by this tool has the same GUI as those described in the CourseMan examples in the earlier chapters of this dissertation, except that every view field (of a module’s view) is generated with a default configuration 137 Example 5.1 Figures 5.1 and 5.4 together show an example CourseMan software that is generated by DomainAppTool Figure 5.1 includes three views: View Student , View SClassRegistration and View SClass Note, in particular, how the view field View EnrolmentMgmt students in Figure 5.4 is a subview reflecting the associative field EnrolmentMgmt.students This subview has exactly the same content as View Student in Figure 5.1 This view has two list-typed view fields: sclasses and modules These fields reflect the two many-many associations between Student and SClass, CourseModule (resp.) The actual handling of user actions on these fields require customising some module actions This customisation will be discussed later as part of the fourth MP For this MP, these view fields are used by Figure 5.4: The view of ModuleEnrolmentMgmt of the software in Figure 5.1 the development team to visually review the domain class design 5.4.3 M P2 –M P4 These three MPs involve customising view and/or controller at various extents We thus first develop a shared formula for all three MPs After that, we discuss how it is applied to each MP Denote by W and w the numbers of customised configuration elements of a module and of a view field (resp.) Definition 5.1 The configuration customisation factor of a module, whose view contains s number of view fields, is: C = (W + si=1 wi ) Given that the module’s containment tree has n descendant modules, whose configurations are customised Let Ck be the configuration customisation factor of the k th descendant module We derive from Formula 5.1 the following formula for m1 : 138 m1 = − C+ n k=1 Ck (5.3) W1 Denote by P and p the numbers of lines of code (LOCs) for the customised components of a module and of a view field (resp.) Definition 5.2 Given that a module has T number of customised components at the module level, s number of view fields and ti number of customised components for the ith view field of the module view The code customisation factor of the module is: D= T i=1 Pi + s i=1 ti j=1 pij We derive from Formula 5.1 the following formula for m2 (n is the number of customised descendant modules, as in Formular 5.3): m2 = − D+ n k=1 W2 Dk (5.4) M P2 It can be observed in Table 5.5 that, for this MP, m1 is measured based only on counting the number of customised controller configuration elements If there exists a nonempty sub-set of these elements that require customising module actions, then m2 is measured based on counting the LOCs of the customised components of these actions M P3 It can be observed in Table 5.5 that, for this MP, m1 is measured based only on counting the number of customised view configuration elements If there exists a non-empty sub-set of these elements that require creating new view components, then m2 is measured based on counting the LOCs of these components M P4 It can be observed in Table 5.5 that, for this MP, m1 is measured based on counting the numbers of customised view and controller configuration elements If there exists a non-empty sub-set of these elements that require creating new components (view or module action), then m2 is measured based on counting the LOCs of these components An important insight that we draw from our evaluation framework is that module generativity is high (which is desirable) if m2 is high and dominates m1 This occurs if (i) existing MOSA’s capability (which includes the set of design patterns that have been constructed over time) is sufficient for constructing software modules in the domain and (ii) α is small As explained in Section 5.4.1, condition (ii) typically holds in practice Although condition 139 (i) can not be guaranteed to hold for a software module whose design requirements not match exactly with the existing MOSA’s capability, it can be made to hold for other software modules that have similar design requirements This is achieved through the design patterns Example 5.2 Table 5.6 shows the module generativity values of two CourseMan’s modules (ModuleStudent and ModuleEnrolmentMgmt) that were configured for each of the three MPs discussed in this section The last column (“M ”) lists the module generativity value Table 5.6: Module generativity values of two CourseMan’s modules in M P2 –M P4 MPs M P2 M P3 M P4 Modules ModuleStudent ModuleEnrolmentMgmt ModuleStudent ModuleEnrolmentMgmt ModuleStudent ModuleEnrolmentMgmt C 11 18 17 Configuration (Step 1) C1 , , Cn W1 m1 – 51 0.98 1, 1, 49 0.94 – 61 0.82 54 0.89 – 72 0.75 – 61 0.72 D 0 72 291 144 Code (Step 2) D1 , , D n W2 – 7500 – 7500 – 7572 – 7500 – 7791 – 7644 m2 1 0.99 0.96 0.98 α M 0.01 0.01 0.01 0.01 0.01 0.01 0.99 0.99 0.99 0.99 0.96 0.98 The two master columns (“Configuration” and “Code”) show statistics for step and step of the generativity procedure The sub-columns of these master columns show values of each component of Formula 5.3 (step 1) and of Formula 5.4 (step 2), respectively The two columns “C1 , , Cn ” and “D1 , , Dn ” list sequences of numbers for the configuration elements and LOCs (resp.) of the descendant modules of each module In the current example, column “D1 , , Dn ” does not contain any values, because none of the customisation that was made necessarily leads to code customisation in any descendant module For instance, we initially had D1 = 72 for ModuleEnrolmentMgmt of M P3 , but then discarded because the customisation could reuse the view component that was implemented as part of ModuleStudent The numbers of LOCs listed in column W1 are counted directly from each generated MCC The numbers in the column W2 , however, are calculated by adding the LOCS of the customised code to the base LOCs of 7500 This is the total LOCs of the View and Controller classes that are implemented in jDomainApp As can be seen from the table, M is very high for both modules in all three MPs This is because in all of these cases m2 is very high and dominates m1 (α is very small) Figure 5.5 shows the CourseMan software of M P4 , which contains the customised views and configurations of the modules We will use this view to illustrate both types of customisations We will make explicit for each customisation the MPs under which it is allowed First, regarding to view configuration customisation (M P3 , M P4 ), the figure shows 140 Figure 5.5: An example CourseMan software that has substantially been customised that all three views have been configured with custom view field labels and with more complex layout In particular, View Student is similar to the one presented in Figure 4.7 in that it excludes the view field helpRequested View EnrolmentMgmt has an overall tab layout In this layout, all the subviews reflecting the associative fields (e.g the subview for EnrolmentMgmt.students) are rendered within the tabs of a tab group Further, the label and content of every view field has been configured to contain user-friendly strings For instance, the view field View Student modules is now labelled “Enrols Into” Its content now lists values (“IPG”, “PPL”, “SEG”) of the ‘bounded’ domain field (CourseModule.name), as opposed to the CourseModule.ids as shown in Figure 5.1 As for controller configuration customisation (M P2 , M P4 ), we customise the open action of each module with a suitable policy We also customise this action for two descendant modules of ModuleEnrolmentMgmt of M P2 These explain the three one values (1, 1, 1) written in the column labelled C1 , , Cn in Table 5.6 of the module A useful policy that we use is to automatically load all the objects from the object store This policy is applicable when there are only a small number of objects of the concerned domain class or that these objects are required in order for the software to function We showed in the MCC 141 of ModuleStudent in Listing 4.1 how to configure the open policy of the open action Regarding to controller code customisation (M P2 , M P4 ), we customise the module actions in order to realise a pattern named many-many association normaliser7 This pattern involves specifying the many-many association type directly in the domain class, despite the fact that the underlying object store of this class only supports one-many association Given that the CourseMan software uses a relational database to store objects The domain model (shown in Figure 1.1) directly supports a many-many association between Student and CourseModule This requires the module action which handles the many-many association to conform to the pattern behaviour This behaviour basically involves transforming the manymany association (exposed on the module’s view) between the two participating domain classes into two one-many associations that are actually defined in the two classes Listing 5.1 shows a partial MCC of ModuleStudent (presented in Listing 4.1) that has been reconfigured with two customised module actions The customised view of this module was presented as part of Figure 5.5 In this, the actions allow the user to choose for each Student several CourseModules on the list The two module actions are specified in the two PropertyDescs that form the value of the property ModuleDesc.controllerDesc.props These specify the customised Create and Update actions to be the following classes (resp.): CreateObjectAndManyAssociatesDataControllerCommand and UpdateObjectAndManyAssociatesDataControllerCommand Listing 5.1: ModuleStudent’s MCC with customised actions for many-many associations 10 11 12 13 14 @ ModuleDesc ( name = " ModuleStudent " , modelDesc = @ ModelDesc ( model = Student class ) , viewDesc = @ ViewDesc ( omitted ) , controllerDesc = @ ControllerDesc ( controller = Controller class , i s D a ta F i e l dS t a t eL i s t en e r = true , props ={ // many - many assoc commands @ PropertyDesc ( name = PropertyName controller_dataController_create , valueIsClass = C r e a t e O b j e c t A n d M a n y A s s o c i a t e s D a t a C o n t r o l l e r C o m m a n d class , valueAsString = MetaConstants NullValue , valueType = Class class ) , @ PropertyDesc ( name = PropertyName controller_dataController_update , valueIsClass = U p d a t e O b j e c t A n d M a n y A s s o c i a t e s D a t a C o n t r o l l e r C o m m a n d class , valueAsString = MetaConstants NullValue , valueType = Class class ) }) omitted ) public class ModuleStudent { omitted } paper listed in the Publications section 142 5.4.4 Analysis of MCCGen In this section, we summarise the correctness and performance evaluation of function MCCGen We state two theorems and provide a proof for each Theorem 5.1 (Correctness) MCCGen correctly generates the owner MCC of the input domain class This MCC is structurally consistent with the domain class, as per Definition 4.3 Proof The proof consists of two parts First, the output MCC (m) is the owner MCC of the input domain class (c) This follows from the fact that ModuleDesc(m).modelDesc (do ) is initialised with model=c Second, m is structurally consistent (as per Definition 4.3) with c Condition (ii) is clearly satisfied because m has an empty containment tree (Alg 4.1 does not generate this tree) Condition (i) is satisfied due to the fact that the title field (fd ) is created as a field of m and that the for loop in function AddViewFields create other view fields (fd ) of m that reflect the domain fields f of c Each view field has the same visibility (“private”), name (nf ) and data type (tf ) as those of the corresponding domain field Performancewise, the main concern is worst-case time complexity In the theorem that follows, we will state the worst-case time complexity of function MCCGen To ease discussion, we will refer to this generally as complexity Theorem 5.2 (Complexity) MCCGen has a linear worst-case time complexity of O(F ), where F is the number of domain fields of the input domain class Proof The dominating part of Alg 4.1 is the invocation of function AddViewFields which occurs at the end of step The for loop of this function iterates over the set F of the domain fields of c The loop body consists of three primitive operations Thus, the time complexity of the algorithm is big-O of |F |, which is O(F ) Therefore, MCCGen is scalable to handle domain classes with large state spaces 143 5.4.5 Discussion We conclude the current evaluation with a brief remark about the usability of software GUI From the domain expert’s view-point, this usability plays a role in the usability of our method We would argue in favour of two aspects of the software GUI, namely simplicity and consistency, which contribute towards its learnability [24] First, the GUI design is simple because, as discussed in Proposition 4.1, the module view reflects the domain class structure Clearly, model reflectivity is the most basic representation of the domain model Second, the GUI is consistent in its presentation of the module view and in handling the user actions performed on it Consistent presentation is due to the application of the reflective layout to all module views Consistent handling is due to the fact that a common set of module actions (see Section 4.2.1) are made available on the module view 5.5 Summary In this chapter, we conducted an evaluation of our contributions with an aim to measure the extent to which they achieve the objectives that were set in Chapter We briefly described an implementation of DCSL and MCCL as part of a software framework This implementation was used to conduct the experiments needed for the evaluation We first evaluated DCSL from the perspective of a specification language The evaluation shows that DCSL is essentially more expressive and, thus, necessarily requires (a little) more coding compared to two other similar languages Further, behaviour specifications of all the domain methods can be automatically generated and the generation can scale to support domain classes with large state spaces We then evaluated the extent to which MCCL helps automatically generate the software modules that are configured by it We first defined a module generativity framework and four generic module patterns that classify the all the modules generatable using MCCL We also analysed the correctness and performance of function MCCGen This showed that the function is scalable with the domain class’s state space The content of this chapter is published in the following papers (listed in the Publications section) The DCSL’s evaluation is published in the SCIE journal paper The evaluation for module-based software construction is published in the SCIE journal paper The DDD patterns used in this evaluation are published in the conference paper The implemented jDomainApp framework is published in the conference paper 144 Chapter Conclusion The advent of model-based software development has, over the past twenty years, drastically changed the way software is engineered Two closely-related MBSD methods that arguably have firmly cemented their place in the industry are MDSE and DDD The DDD method aims to address the problem of how to effectively use models to tackle the domain’s complexity which it considers to be at the heart of software The domain models should not only express the domain requirements well but be technically feasible for implementation Despite the fact that a substantial body of work has been written and a number of software frameworks have been developed for DDD, there are still significant open issues to be addressed These issues became clear to us when we analysed DDD from the perspectives of a number of closely-related software engineering paradigms and methods (which include not only MDSE but OOPL, AtOP, BISL and aDSL) They motivated us to conduct this research, whose aim is to develop solutions for tackling the identified issues The underlying theme of our approach is to use aDSL in DDD to design the core domain model and the modules that make up software constructed from the model The solutions that we have presented in this dissertation form an enhanced DDD method, which we believe makes the original method not only more concrete but more complete for software development purposes After summarising the key contributions of this dissertation, we will discuss a number of directions for future development 145 6.1 Key Contributions This dissertation makes five key contributions towards enhancing the DDD method The first contribution is an aDSL, named DCSL, which consists in a set of annotations that express the essential structural constraints and the essential behaviour of domain class We have carefully selected the design features from a number of authoritative software and system engineering resources and have shown that they form a minimum design space of the domain class We have applied the meta-modelling approach with UML/OCL to systematically define the abstract syntax of DCSL We have also specified the semantics of the language The second contribution is a unified domain modelling approach, which consists in using DCSL to express a unified domain model We have chosen UML activity diagram language for behavioural modelling and discussed how the state-specific features of this language are expressed in DCSL We have demonstrated our approach with a set of five fundamental UD modelling patterns The third contribution is a 4-property software characterisation that provides technical guidelines for the software that are constructed directly from the domain model The four properties are instance-based GUI, model reflectivity, modularity and generativity These properties are defined based on a layered software model that includes the domain model at the core, an intermediate module layer surrounding this core and an outer software layer Conceptually, this software model shows that a software is structured in terms of a set of modules and these modules are constructed directly from the domain model The fourth contribution is another aDSL, named MCCL, that is used for designing the software modules in the module-based software architecture More precisely, MCCL is used to express the module configuration classes (MCCs) An MCC provides an explicit class-based definition of a set of module configurations of a given module class These configurations are treated as first-class objects and, thus, can easily be reused to create different variants of the same module class, without having to change the module class design Again, we have adapted the meta-modelling approach with UML/OCL to systematically define the abstract and concrete syntaxes of MCCL We have also leveraged DCSL to define the base semantics for MCCL The fifth contribution is an implementation of DCSL, MCCL and the generators associated with these aDSLs as components in the jDomainApp software framework Our implementation results in various software tools that can be used by developers to effectively apply our method in their software development processes 146 6.2 Future Work We argue that our research lays a foundation for further works to be conducted towards enhancing the DDD method We highlight below a number of directions for these works MOSA and Software Construction It is clear that the MOSA architecture needs to be improved if we are to enhance the software construction capabilities of our method We gather in this section a number of research ideas concerning both MOSA and software construction Formalising the Software Properties It would be beneficial for software design verification purposes to formalise the four software properties that were defined somewhat informally in this dissertation The formalism should focus on the UML software model that was used as the basis to define the properties Improved Spport for Behavioural Modelling Two areas of improvement would be considered The first area of improvement concerns extending the UDM to support other UML activity diagram constructs, e.g activity group The second area of improvement concerns constructing an aDSL for the UML activity graph This graph was assumed to exist in this dissertation (see Section 3.6.2) A closer look at the graph description in the UML specification [57] would reveal that it too can be expressed by an aDSL Supporting Other Types of Requirement To better support real-world software, the MOSA architecture would be extended to support web-based and mobile software development Other important requirement types that should be studied with MOSA include security and those that are included in the current software module design of the Java language An aDSL for Software Construction We discussed in Section 1.3 how software construction is supported by the jDomainApp framework However, this framework currently lacks a language that enables the designer to configure the software as a whole and the modules that make up a software We would argue that the lessons learnt from developing MCCL for software modules would be applied to develop a similar aDSL for software configuration In particular, this aDSL would allow the definition of software configuration classes Each class defines a set of software configurations for constructing a software class from a set of software modules 147 Integration into Software Development Processes This integration is essential for the dissemination of our method in practice and, thus, we would recommend future research be conducted to investigate this We argue that our method would particularly be suited for integration into iterative [43] and agile [6] development processes Conceptually, the development team (which includes domain experts and developers) would use our tool to work together on developing the UDM in an incremental fashion: the developers use DCSL to create/update the UDM and then use MCCL to construct the software modules from this model The software prototypes generated from these modules are used as the intermediate releases for the final software The domain experts give feedbacks for the model via the software GUI and the update cycle continues Further, for both iterative and agile processes, tools and techniques from MDSE would be applied to enhance productivity and tackle platform variability In particular, PIM-to-PSM model transformation would be applied to automatically generate the UDM from a high-level one that is constructed from a combination of UML class and activity diagrams Industrial-Scale Applications It would be useful to apply our method to develop industrial-scale applications and report the results To prepare for this, in addition to carrying out the future works described in the previous subsections, we would recommend investigating the integration of the overall method in well-known IDE, e.g Eclipse Further, an automated mechanism for handling domain model evolution would also be desirable Software Engineering Education Because of the strong connection of our method to OOPL, it would be interesting to investigate how our method is applied in teaching software engineering course modules Applying our method in education would also help increase the awareness of the method and its adoption in practice To achieve this, further work should be conducted to integrate our method into university’s software engineering curriculumns For instance, the practical experience that has been gained through applying our method (especially in connection with DomainAppTool) to teaching software engineering at Hanoi Univeristy should be documented, analysed and published In addition, other works should be conducted to integrate the method into teaching at the entry level, which includes object-oriented programming course modules 148 Publications During the development of this dissertation, the author has published in the following international conferences and journals: D M Le, D.-H Dang, V.-H Nguyen, “Domain-Driven Design Using Meta-Attributes: A DSL-Based Approach”, in: Proc 8th Int Conf Knowledge and Systems Engineering (KSE), IEEE, 2016, pp 67–72 D M Le, D.-H Dang, V.-H Nguyen, “Domain-Driven Design Patterns: A MetadataBased Approach”, in: Proc 12th Int Conf on Computing and Communication Technologies (RIVF), IEEE, 2016, pp 247–252 D M Le, D H Dang, V H Nguyen, “Generative Software Module Development: A Domain-Driven Design Perspective”, in: Proc 9th Int Conf on Knowledge and Systems Engineering (KSE), 2017, pp 77–82 D M Le, D.-H Dang, and V.-H Nguyen, “On Domain Driven Design Using AnnotationBased Domain Specific Language,” Journal of Computer Languages, Systems & Structures (SCIE), vol 54, pp 199–235, 2018 D M Le, D.-H Dang, H T Vu, “jDomainApp: A Module-Based Domain-Driven Software Framework”, in: Proc 10th Int Symp on Information and Communication Technology (SOICT), ACM, 2019 D M Le, D.-H Dang, V.-H Nguyen, “Generative Software Module Development for Domain-Driven Design with Annotation-Based Domain Specific Language”, Journal of Information and Software Technology (SCIE), vol 120, pp 106–239, 2020 149 Bibliography [1] D Akehurst et al., “Implementing Associations: UML 2.0 to Java 5,” Softw Syst Model, vol 6, no 1, pp 3–35, Mar 2007 [2] J Alves-Foss and F S Lam, “Dynamic Denotational Semantics of Java,” in Formal Syntax and Semantics of Java, ser Lecture Notes in Computer Science Springer, Berlin, Heidelberg, 1999, pp 201–240 [3] K Arnold et al., The Java Programming Language, 4th ed Addison-wesley Reading, 2005, vol [4] M Balz, “Embedding Model Specifications in Object-Oriented Program Code: A Bottom-up Approach for Model-Based Software Development,” Ph.D dissertation, Universität Duisburg-Essen, Jan 2012 [5] M Barnett et al., “The Spec# Programming System: An Overview,” in Construction and Analysis of Safe, Secure, and Interoperable Smart Devices, ser Lecture Notes in Computer Science Springer, Berlin, Heidelberg, Mar 2004, pp 49–69 [6] K Beck et al., “Manifesto for Agile Software Development,” 2017 [7] D Bogdanas and G Roşu, “K-Java: a complete semantics of Java,” in ACM SIGPLAN Notices, vol 50 ACM, 2015, pp 445–456 [8] G Booch, “Object-Oriented Development,” IEEE Transactions on Software Engineering, vol SE-12, no 2, pp 211–221, Feb 1986 [9] M Brambilla et al., Model-Driven Software Engineering in Practice, 2nd ed Morgan & Claypool Publishers, Apr 2017 150 [10] D Bruns, “Formal Semantics for the Java Modeling Language,” Ph.D dissertation, 2009 [11] G Calvary et al., “From Single-user Architectural Design to PAC*: A Generic Software Architecture Model for CSCW,” in ACM SIGCHI Conf on Human Factors in Computing Systems, ser CHI ’97 New York, NY, USA: ACM, 1997, pp 242–249 [12] V Cepa, Attribute Enabled Software Development Saarbrücken, Germany, Germany: VDM Verlag, 2007 [13] V Cepa and S Kloppenburg, “Representing Explicit Attributes in UML,” in 7th Int Workshop on Aspect-Oriented Modeling (AOM), 2005 [14] C W Churchman, The Systems Approach, revised, updated ed Publising Company, Nov 1984 New York, NY: Dell [15] J Coutaz, “PAC: An Object Oriented Model for Dialog Design,” in Interact’87, vol 87 Elsevier, 1987, pp 431–436 [16] K Czarnecki, “Overview of Generative Software Development,” in Unconventional Programming Paradigms, ser Lecture Notes in Computer Science, J.-P Banâtre et al., Eds Springer Berlin Heidelberg, 2005, no 3566, pp 326–341 [17] Dan Haywood, “Apache Isis - Developing Domain-Driven Java Apps,” Methods & Tools: Practical knowledge source for software development professionals, vol 21, no 2, pp 40–59, 2013 [18] DataNucleus, “JDO Annotations Reference (v5.1),” 2018 [19] R Dekkers, Applied Systems Theory, 2nd ed Springer International Publishing, 2017 [20] M Dumas and A H M t Hofstede, “UML Activity Diagrams as a Workflow Specification Language,” in UML 2001, ser LNCS, M Gogolla and C Kobryn, Eds Springer, Oct 2001, pp 76–90 [21] Eclipse Foundation, “Eclipse Modeling Project,” 2019 URL: https://www.eclipse.org/ modeling/emf/ 151 [22] E Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software Addison-Wesley Professional, 2004 [23] E Evans, Domain-Driven Design Reference: Definitions and Pattern Summaries Dog Ear Publishing, LLC, Sep 2014 [24] E Folmer and J Bosch, “Architecting for Usability: A Survey,” Journal of Systems and Software, vol 70, no 1–2, pp 61–78, Feb 2004 [25] M Fowler and T White, Domain-Specific Languages Sep 2010 Addison-Wesley Professional, [26] A Fuggetta and E Di Nitto, “Software Process,” in Proceedings of the on Future of Software Engineering, ser FOSE 2014 New York, NY, USA: ACM, 2014, pp 1–12 [27] E Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1st ed Reading, Mass: Addison-Wesley Professional, Nov 1994 [28] J Gosling et al., The Java Language Specification, Java SE Edition, 1st ed Saddle River, NJ: Addison-Wesley Professional, May 2014 [29] J Gosling et al., The Java Language Specification: Java SE Edition USA: Oracle America, Inc., Aug 2017 Upper California, [30] C Guindon, “Eclipse OCL (Object Constraint Language),” Jan 2013 [31] W Harrison et al., “Mapping UML Designs to Java,” in Proc 15th ACM SIGPLAN Conf on Object-oriented Programming, Systems, Languages, and Applications, ser OOPSLA ’00 New York, NY, USA: ACM, 2000, pp 178–187 [32] J Hatcliff et al., “Behavioral Interface Specification Languages,” ACM Comput Surv., vol 44, no 3, pp 16:1–16:58, Jun 2012 [33] A Hejlsberg et al., The C# Programming Language, 4th ed Upper Saddle River, NJ: Addison Wesley, Oct 2010 [34] J A Hoffer et al., Modern Systems Analysis and Design, 7th ed Hall, Feb 2013 152 Boston: Prentice [35] J A Hoffer et al., Modern Database Management, 12nd ed 2015 Boston: Pearson, Jul [36] P Hudak, “Modular Domain Specific Languages and Tools,” in Proc 5th Int Conf on Software Reuse, Jun 1998, pp 134–142 [37] J Juneau, “Java Modularity,” in Java Recipes: A Problem-Solution Approach, J Juneau, Ed Berkeley, CA: Apress, 2017, pp 605–614 [38] S Kent, “Model Driven Engineering,” in Integrated Formal Methods, ser Lecture Notes in Computer Science, M Butler et al., Eds Springer Berlin Heidelberg, May 2002, no 2335, pp 286–298 [39] A Kleppe, Software Language Engineering: Creating Domain-Specific Languages Using Metamodels, 1st ed Upper Saddle River, NJ: Addison-Wesley Professional, Dec 2008 [40] T Kosar et al., “Domain-Specific Languages: A Systematic Mapping Study,” Information and Software Technology, vol 71, pp 77–91, Mar 2016 [41] G E Krasner and S T Pope, “A Description of the Model-View-Controller User Interface Paradigm in the Smalltalk-80 System,” Journal of object-oriented programming, vol 1, no 3, pp 26–49, 1988 [42] A v Lamsweerde, “Formal Specification: A Roadmap,” in Proceedings of the Conference on The Future of Software Engineering, ser ICSE ’00 New York, NY, USA: ACM, 2000, pp 147–159 [43] C Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd ed Upper Saddle River, NJ, USA: Prentice Hall PTR, 2004 [44] D M Le, “A Domain-Oriented, Java Specification Language,” in Proc 7th Int Conf Knowledge and Systems Engineering (KSE) IEEE, Oct 2015, pp 25–30 [45] D M Le, “A Tree-Based, Domain-Oriented Software Architecture for Interactive Object-Oriented Applications,” in Proc 7th Int Conf Knowledge and Systems Engineering (KSE) IEEE, Oct 2015, pp 19–24 153 [46] G T Leavens, “JML Reference Manual,” Tech Rep., 2013 [47] G T Leavens et al., “Preliminary Design of JML: A Behavioral Interface Specification Language for Java,” SIGSOFT Softw Eng Notes, vol 31, no 3, pp 1–38, May 2006 [48] B Liskov and J Guttag, Abstraction and specification in program development MIT Press, 1986 [49] B Liskov and J Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design Pearson Education, 2000 [50] M Mernik et al., “When and How to Develop Domain-specific Languages,” ACM Comput Surv., vol 37, no 4, pp 316–344, Dec 2005 [51] B Meyer, Object-Oriented Software Construction, 2nd ed Santa Barbara (California): ISE Inc., 1997 [52] S Millett and N Tune, Patterns, Principles, and Practices of Domain-Driven Design John Wiley & Sons, Apr 2015 [53] M Nosál and J Porubän, “XML To Annotations Mapping Definition With Patterns,” Computer Science and Information Systems, vol 11, no 4, pp 1455–1477, 2014 [54] M Nosál’ et al., “Language Composition Using Source Code Annotations,” Computer Science and Information Systems, vol 13, no 3, pp 707–729, 2016 [55] OMG, “Model Driven Architecture (MDA),” OMG, Tech Rep ormsc/2001-07-01, Jul 2001 [56] OMG, “Object Constraint Language Version 2.4,” OMG, Tech Rep formal/2014-02-03, 2014 [57] OMG, “Unified Modeling Language version 2.5,” OMG, Tech Rep formal/2015-03-01, 2015 [58] OMG, “Meta Object Facility (MOF) Core Specification,” OMG, Tech Rep formal/1506-06, Nov 2016 [59] Oracle, “Java Persistence API Specification,” 2018 154 [60] J Paniza, Learn OpenXava by Example form, 2011 CreateSpace Independent Publishing Plat- [61] Paul Deitel, “Understanding Java Modules,” 2017 [62] R Pawson and R Matthews, “Naked Objects,” in OOPSLA ’02, ser OOPSLA ’02 New York, NY, USA: ACM, 2002, pp 36–37 [63] Red Hat, “Bean Validation 2.0 (JSR 380),” 2017 [64] Red Hat, “Hibernate Validator,” 2017 [65] D Riehle and H Züllighoven, “Understanding and Using Patterns in Software Development,” Theory Pract Obj Syst., vol 2, no 1, pp 3–13, Jan 1996 [66] P Runeson and M Höst, “Guidelines for Conducting and Reporting Case Study Research in Software Engineering,” Empir Software Eng, vol 14, no 2, p 131, Apr 2009 URL: http://link.springer.com/article/10.1007/s10664-008-9102-8 [67] D C Schmidt, “Model-Driven Engineering,” Computer, vol 39, pp 25–31, 2006 [68] Sculptor Team, “Sculptor - Generating Java Code From DDD-Inspired Textual DSL,” 2016 URL: http://sculptorgenerator.org/ [69] G Smith, The Object-Z Specification Language, ser Advances in Formal Methods Boston, MA: Springer US, 2000, vol [70] I Sommerville, Software Engineering, 9th ed Pearson, 2011 [71] J M Spivey, “An Introduction to Z and Formal Specifications,” Software Engineering Journal, vol 4, no 1, pp 40–50, Jan 1989 [72] M Sulír et al., “Recording Concerns In Source Code Using Annotations,” Computer Languages, Systems & Structures, vol 46, pp 44–65, Nov 2016 [73] F Tomassetti et al., “JavaParser,” 2016 URL: http://javaparser.org/ [74] A van Deursen et al., “Domain-Specific Languages: An Annotated Bibliography,” SIGPLAN Not., vol 35, no 6, pp 26–36, Jun 2000 155 [75] V Vernon, Implementing Domain-Driven Design, 1st ed Addison-Wesley Professional, Feb 2013 Upper Saddle River, NJ: [76] H Wada and J Suzuki, “Modeling Turnpike Frontend System: A Model-Driven Development Framework Leveraging UML Metamodeling and Attribute-Oriented Programming,” in Model Driven Engineering Languages and Systems, ser Lecture Notes in Computer Science, L Briand and C Williams, Eds Springer Berlin Heidelberg, Oct 2005, no 3713, pp 584–600 [77] J B Warmer and A G Kleppe, “Building a Flexible Software Factory Using Partial Domain Specific Models,” Oct 2006 [78] J Warmer, “A Model Driven Software Factory Using Domain Specific Languages,” in Model Driven Architecture- Foundations and Applications Springer, Berlin, Heidelberg, Jun 2007, pp 194–203 156 Appendices 157 Appendix A Helper OCL Functions for DCSL’s ASM ExprTk Figure A.1: Utility class ExprTk 10 context ExprTk :: g enLi nkRem over PreC ond ( c : Classifier , m : Parameter , y : Integer ) : String return a pre - condition for a link - remover operation depending on m type post : let ty : Classifier = m type in let cname : String = c name at (1) toLowerCase () + c name substring (2 , c name size () ) in if ty oclIsKindOf ( CollectionType ) then result = cname + ’ Count - ’+ m name + ’ size () >= ’ + y else result = cname + ’ Count - >= ’ + y endif 158 11 12 13 14 15 16 17 18 19 20 21 context ExprTk :: ge n Li n kR em o ve r Po st C on d ( a : Field , return post - condition (1) for a link - remover type pre : a type oclIsKindOf ( CollectionType ) post : let ty : Classifier = m type in if ty oclIsKindOf ( CollectionType ) then result = a name + ’ = ’+ a name + ’ @pre - > asSet () else result = a name + ’ = ’+ a name + ’ @pre - > asSet () endif m : Parameter ) : String operation depending on m - ’+ m name + ’ - > asSet () ’ - Set { ’+ m name + ’} ’ 22 23 24 25 26 27 28 context ExprTk :: ge n Li n kR em o ve r Po st C on d ( c : Classifier , a : Field ) : String return post - condition (2) for a link - remover operation depending on m type pre : a type oclIsKindOf ( CollectionType ) post : let cname : String = c name at (1) toLowerCase () + c name substring (2 , c name size () ) in result = cname + ’ Count = ’+ a name + ’ - > size () ’ 29 30 31 32 33 34 35 36 37 38 39 context ExprTk :: genLinkAdderPreCond ( c : Classifier , m : Parameter , x : Integer ) : String return a pre - condition for a link - adder operation depending on m type post : let ty : Classifier = m type in let cname : String = c name at (1) toLowerCase () + c name substring (2 , c name size () ) in if ty oclIsKindOf ( CollectionType ) then result = cname + ’ Count + ’+ m name + ’ size () union ( ’+ m name + ’ - > asSet () ) ’ 159 48 else result = a name + ’ = ’+ a name + ’ @pre - > asSet () -> union ( Set { ’+ m name + ’}) ’ endif 49 50 51 52 53 54 55 context ExprTk :: g enLi nkAdd erPo stCo nd2 ( c : Classifier , a : Field ) : String return post - condition (2) for a link - remover operation depending on m type pre : a type oclIsKindOf ( CollectionType ) post : result = ge n Li nk R em o ve rP o st C on d2 (c , a ) Tk Figure A.2: Utility class Tk context Tk :: isLinkTo ( o1 : Object , a : Field , o2 : Object ) : Boolean check if a value ( o1 ) contains a link to o2 post : let v1 = a value ( o1 ) in if a type oclIsKindOf ( CollectionType ) then v1 - > includes ( o2 ) else v1 = o2 endif 10 11 12 13 14 15 context Tk :: ancestors ( c : Class ) : Set ( Class ) return ancestor classes of c post : if not ( c gens oclIsUndefined () ) then result = c gens - > collect ( g | { g super } union ( ancestors ( g super ) ) -> excluding ( OclVoid ) ) -> flatten () -> asSet () else result = OclVoid endif 160 Classifier context Classifier if this conforms to CollectionType then return elementType else return self def : elementType () : Classifier = if oclIsKindOf ( CollectionType ) then oclAsType ( CollectionType ) elementType else self endif Class context Class return all link - remover methods of this def : linkRemovers () : Set ( Method ) = methods - > select ( m | m opt type = OptType :: LinkRemover ) return all link - adder methods of this def : linkAdders () : Set ( Method ) = methods - > select ( m | m opt type = OptType :: LinkAdder ) 10 11 12 return all overriden methods of this def : overridenMethods () : Set ( Method ) = methods - > select ( m | m annotations - > select ( n | n name = ’ Overriden ’) -> size () = 1) Method context Method return the post - condition exprs of a method def : postExps () : Sequence ( OclExpression ) = post specification oclAsType ( OpaqueExpression ) body oclAsType ( Sequence ( OclExpression ) ) 10 return the pre - condition exprs of a method def : preExps () : Sequence ( OclExpression ) = pre specification oclAsType ( OpaqueExpression ) body oclAsType ( Sequence ( OclExpression ) ) 11 12 13 14 return the result expression of the form " result = " def : resultExp () : OclExpression = if postExps () -> size () = and 161 15 postExps () -> any ( true ) oclIsType ( VarAssignExpression ) then postExps () -> any ( true ) oclAsType ( VarAssignExpression ) else OclVoid endif 16 17 18 19 20 21 22 23 is this an overriden method def : isOverriden () : Boolean = ( annotations - > select ( n | n name = ’ Overriden ’) -> size () = 1) 24 25 26 is this the mutator method def : isAttrRef ( a : Field ) : Boolean = ( ref value = a name ) 27 28 29 30 is this a creator method or a mutator method that references a ? def : i sCre ator OrMut ator Ref ( a : Field ) : Boolean = isCreatorRef ( a ) or isMutatorRef ( a ) 31 32 33 34 is this a creator method that contains a parameter referencing a ? def : isCreatorRef ( a : Field ) : Boolean = isCreator () and params - > exists ( isAttrRef ( a ) ) 35 36 37 38 is this a mutator method that contains a parameter referencing a ? def : isMutatorRef ( a : Field ) : Boolean = isMutator () and params - > exists ( isAttrRef ( a ) ) ) 39 40 41 is this the creator method def : isCreator () : Boolean = ( opt type = OptType :: Creator ) 42 43 44 is this the mutator method def : isMutator () : Boolean = ( opt type = OptType :: Mutator ) Parameter context Parameter does this reference a ? def : isAttrRef ( a : Field ) : Boolean = ( ref value = a name ) Field context f : Field determine if a field has numeric type 162 def : isNumericType () : Boolean = let tyn : String = f type name in tyn = ’ Integer ’ or tyn = ’ Real ’ or tyn = ’ UnlimitedNatural ’ DAttr context DAttr does this preserve another DAttr ? def : preserves ( r : DAttr ) : Boolean = mutable = r mutable and optional = r optional and unique = r unique and id = r id and auto = r auto and length = r and max Double :: INFINITY implies max collect ( f | MCCModel :: getInstance () :: lookUpModuleCfg ( f type ) ) -> asSet () in G union (G - > iterate ( g ; G1 : Set ( Set ( ModuleConfig ) ) = Set {}) | G1 - > including ( descMods ( g ) ) ) -> flatten () else {} endif 16 17 18 19 20 if g is composite then return the ModuleConfigs of the descendant modules else return {} def : descMods ( g : ModuleConfig ) : Set ( ModuleConfig ) = if g isComposite () then 164 21 g descMods () else {} endif 22 23 24 25 26 return the ModuleConfig of the descendant module of this in t whose domain class is mapped to n def : getDescModuleOf ( n : Node ) : ModuleConfig = descMods () -> select ( model domainClass = n dclass ) -> any () 27 28 29 30 31 if this is a composite module return true else return false def : isComposite () : Boolean = model domainClass assocFields - > notEmpty () 32 Class R29 context Class if self contains domain fields then return them as Set else return {} def : domFields () : Set ( Field ) = fields - > select ( f | not ( f atr oclIsUndefined () ) ) 10 if self contains a domain field whose name is n then return it else return OclVoid def : getDomField ( n : String ) : Field = let F : Set ( Field ) = fields - > select ( f | not ( f atr oclIsUndefined () ) and f name = n ) in if F - > notEmpty () then F - > any () else OclVoid endif 11 12 13 14 if self contains associative domain fields then return them as Set else return {} def : assocFields () : Set ( Field ) = fields - > select ( f | not ( f atr oclIsUndefined () ) and not ( f asc oclIsUndefined () ) ) 15 16 17 whether or not self is a domain class ( i e is defined with DClass ) def : isDomainClass () : Boolean = not ( dcl oclIsUndefined () ) 165 Containment Tree R30 context Tree determines if there is a path ( i e a sequence of edges ) that connect n1 to n2 ( in either direction ) def : hasPath ( n1 : Node , n2 : Node ) : Boolean = edges - > exists (( parent = n1 and child = n2 ) or ( parent = n2 and child = n1 )) or nodes - > exists ( n3 | hasPath ( n1 , n3 ) and hasPath ( n3 , n2 ) ) R31 10 11 12 13 14 15 context Tree return set of pairs ( n : Node , s : String ) such that n is the root or a child node and s is the containment scope string of n edge or of the ScopeConfig of the Edge in which n is the child def : getContScopes () : Set ( Tuple ( n : Node , s : String ) ) = let C : Set ( Tuple ( n : Node , s : String ) ) = edges - > select ( e | not ( e scope stateScope oclIsUndefined () ) ) -> collect ( e | Tuple { n = e child , s = e scope stateScope } ) -> asSet () in if not ( root stateScope oclIsUndefined () ) then { Tuple { n = root , s = root stateScope } union ( C ) else C endif Tk R32 context Tk :: parseContScope ( s : String ) : Set ( String ) if s contains ‘,’ then split s into elements ( using ‘,’ as separator ) and return them as Set , else return { s } pre : s indexOf ( ‘ , ’) > implies s size () >= post : result = splitStr (s , ‘ , ’) 166 R33 10 11 12 13 context Tk :: splitStr ( s : String , p : String ) : Set ( String ) if s contains p then split s into elements ( using p as separator ) and return them as Set , else return { s } pre : p size () = and ( s indexOf ( p ) > implies s size () >= 3) post : let i : Integer = s indexOf ( p ) in if i > then result = splitStr ( s substring (0 ,i -1) , p ) union ( splitStr ( s substring ( i +1 , s size () ) ,p ) ) else result = { s } endif MCCModel In the next OCL rule, we assume the existence of the attribute MCCModel.mcfgs whose type is Set(ModuleConfig) This attribute records all the ModuleConfigs of all the software modules R34 context MCCModel return the ModuleConfig of the owner module of c def : lookUpModuleConfig ( c : Class ) : ModuleConfig = mcfgs - > select ( model domainClass = c ) -> any () B.2 Two MCCs of ModuleEnrolmentMgmt Listing B.1: The MCC of ModuleEnrolmentMgmt with containment tree @ ModuleDesc ( name = " ModuleEnrolmentMgmt " , modelDesc = @ ModelDesc ( model = EnrolmentMgmt class ) , viewDesc = @ ViewDesc ( formTitle = " Manage Enrolment Management " , imageIcon = " enrolment jpg " , domainClassLabel = " Enrolment Management " , view = View class , parentMenu = RegionName Tools , topX =0.5 , topY =0.0) , controllerDesc = @ ControllerDesc ( controller = Controller class ) , containmentTree = @CTree ( root = EnrolmentMgmt class , 167 10 11 12 13 14 15 16 17 18 edges ={ // enrolmentmgmt -> student @CEdge ( parent = EnrolmentMgmt class , child = Student class , scopeDesc = @ ScopeDesc ( stateScope ={ " id " , " name " , " helpRequested " , " modules " } ) ) }) ) public class ModuleEnrolmentMgmt { @ AttributeDesc ( label = " Enrolment Management " ) private String title ; 19 20 // student registration @ AttributeDesc ( label = " Student Registration " , layoutBuilderType = T wo Col um nL ay out Bu il der class , controllerDesc = @ ControllerDesc ( openPolicy = OpenPolicy I // support many - many association with CourseModule , props ={ // custom Create : to create { @link Enrolment } from the course modules @ PropertyDesc ( name = PropertyName controller_dataController_create , valueIsClass = C r e a t e O b j e c t A n d M a n y A s s o c i a t e s D a t a C o n t r o l l e r C o m m a n d class , valueAsString = MetaConstants NullValue , valueType = Class class ) , // custom Update command : to update { @link Enrolment } from the course modules @ PropertyDesc ( name = PropertyName controller_dataController_update , valueIsClass = U p d a t e O b j e c t A n d M a n y A s s o c i a t e s D a t a C o n t r o l l e r C o m m a n d class , valueAsString = MetaConstants NullValue , valueType = Class class ) }) ) private Collection < Student > students ; 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 // help desk @ AttributeDesc ( label = " Help Request " , type = DefaultPanel class ) private Collection < HelpRequest > helpDesks ; 40 41 42 43 // class registration @ AttributeDesc ( label = " Class Registration " , type = DefaultPanel class ) private Collection < SClassRegistration > sclassRegists ; 44 45 46 } 168 Listing B.2: The MCC of ModuleEnrolmentMgmt with custom subview configuration for a descendant module of type ModuleStudent 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 @ ModuleDesc ( name = " ModuleEnrolmentMgmt2 " , modelDesc = @ ModelDesc ( model = EnrolmentMgmt class ) , viewDesc = @ ViewDesc ( formTitle = " Manage Enrolment Management " , imageIcon = " enrolment jpg " , domainClassLabel = " Enrolment Management " , view = View class , parentMenu = RegionName Tools , topX =0.5 , topY =0.0) , controllerDesc = @ ControllerDesc ( controller = Controller class ) , containmentTree = @CTree ( root = EnrolmentMgmt class , edges ={ // enrolmentmgmt -> student @CEdge ( parent = EnrolmentMgmt class , child = Student class , scopeDesc = @ ScopeDesc ( stateScope ={ " id " , " name " , " helpRequested " , " modules " } // custom configuration for ModuleStudent , attribDescs ={ // Student name is not editable @ AttributeDesc ( id = " id " , type = JLabelField class ) , @ AttributeDesc ( id = " name " , type = JLabelField class , editable = false ) , }) )} ) ) public class ModuleEnrolmentMgmt2 { @ AttributeDesc ( label = " Enrolment Management " ) private String title ; 25 26 27 28 29 30 31 32 33 34 35 36 37 38 // student registration @ AttributeDesc ( label = " Student Registration " , layoutBuilderType = T wo Col um nL ay out Bu il der class , controllerDesc = @ ControllerDesc ( openPolicy = OpenPolicy I // support many - many association with CourseModule , props ={ // custom Create : to create { @link Enrolment } from the course modules @ PropertyDesc ( name = PropertyName controller_dataController_create , valueIsClass = C r e a t e O b j e c t A n d M a n y A s s o c i a t e s D a t a C o n t r o l l e r C o m m a n d class , valueAsString = MetaConstants NullValue , valueType = Class class ) , // custom Update : to update { @link Enrolment } from the course modules @ PropertyDesc ( name = PropertyName controller_dataController_update , valueIsClass = U p d a t e O b j e c t A n d M a n y A s s o c i a t e s D a t a C o n t r o l l e r C o m m a n d class , valueAsString = MetaConstants NullValue , valueType = Class class ) 169 39 }) ) private Collection < Student > students ; 40 41 42 43 // help desk @ AttributeDesc ( label = " Help Request " , type = DefaultPanel class ) private Collection < HelpRequest > helpDesks ; 44 45 46 47 // class registration @ AttributeDesc ( label = " Class Registration " , type = DefaultPanel class ) private Collection < SClassRegistration > sclassRegists ; 48 49 50 } 170 Appendix C DCSL Evaluation Data C.1 Expressiveness Comparison Between DCSL and the DDD Frameworks Table C.1: Comparing the expressiveness of DCSL to AL, XL DCSL AL XL mutable DomainObject.editing – unique – (i) - optional jdo Column.allowsNull, (Property.optionality) Required mutable Property.editing - id jdo.PrimaryKey.value jpa.Id auto – – (iii) length jdo.Column.length, (Property.maxLength) jpa(iv) Column.length – Min(v) value max – Max(v) value DClass DAttr (ii) DAssoc 171 – – ascType – jpa.OneToMany, jpa.ManyToOne, jpa.ManyToMany role – – endType – – associate.type – – associate.cardMin – – associate.cardMax – – type – – requires – – effects – – value – – ascName DOpt AttrRef (i) AL supports property Property.mustSatisfy which may be used to implement the constraint (ii) Java Data Objects (JDO) [18] (iii) XL supports property ha.Formula that may be use to implement formula for value generation function (iv) Java Persistence API (JPA) [59] (v) Bean Validator (BV) [63] 172 C.2 Level of Coding Comparison Between DCSL and the DDD Frameworks Table C.2: Comparing the max-locs of DCSL to AL, XL DCSL Domain Class AL XL DomainObject.editing, autoCompleteRepository Entity, EntityValidator.value DAttr.length, min, max Column.allowsNull, name, one-of { length, scale }, jdbcType Required, one-of { Column.length, scale }, PropertyValidator.value, Min.value, Max.value, SearchKey Associative Field DAssoc.ascName, ascType, role, endType; associate.type, associate.cardMin, associate.cardMax – one-of { OneToMany, ManyToOne, ManyToMany} DClass.mutable Domain Field 173 Table C.3: Comparing the typical-locs of DCSL to AL, XL DCSL Domain Class AL XL DomainObject.editing, autoCompleteRepository Entity, EntityValidator.value one-of { DAttr.length, min, max } one-of { Column.length, scale } one-of { Column.length, Column.scale, Min.value, Max.value } Associative Field DAssoc.ascName, ascType, role, endType; associate.type, associate.cardMin, associate.cardMax – one-of { OneToMany, ManyToOne, ManyToMany} DClass.mutable Domain Field 174 ... uses a mathematics-based formalism The second approach is translational, which translates the language into another language whose semantics is known The third approach is pragmatic, which uses a. .. of taking the object-relational mapping and applying it to the domain model In particular, it handles how an entity is stored in an underlying database and how to manage access to this database... run-time state when a mogram is executed As a general modelling approach, there are a variety of meta-modelling languages that can be applied A de facto language is Unifield Modelling Language (UML)