Luận án 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

193 trang thiennha21 14/04/2022 3950

Download

Bạn đang xem 20 trang mẫu của tài liệu "Luận án 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", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

luan_an_phuong_phap_tiep_can_khung_nhin_hop_nhat_cho_tu_dong.pdf

Nội dung text: Luận án 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

Vietnam National University, Hanoi VNU University of Engineering and Technology LE MINH DUC A Unified View Approach to Software Development Automation Doctor of Philosophy Dissertation in Information Technology Hanoi - 2020
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ LÊ MINH ĐỨC PHƯƠNG PHÁP TIẾP CẬN KHUNG NHÌN HỢP NHẤT CHO TỰ ĐỘNG HÓA PHÁT TRIỂN PHẦN MỀM LUẬN ÁN TIẾN SĨ NGÀNH CÔNG NGHỆ THÔNG TIN Hà Nội - 2020
Vietnam National University, Hanoi VNU University of Engineering and Technology LE MINH DUC A Unified View Approach to Software Development Automation Specialisation: Software Engineering Code: 9480103.01 Doctor of Philosophy Dissertation in Information Technology Supervisors: 1. Assoc. Prof., Dr. Nguyen Viet Ha 2. Dr. Dang Duc Hanh Hanoi – 2020
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ LÊ MINH ĐỨC PHƯƠNG PHÁP TIẾP CẬN KHUNG NHÌN HỢP NHẤT CHO TỰ ĐỘNG HÓA PHÁT TRIỂN PHẦN MỀM Chuyên ngành: Kỹ thuật Phần mềm Mã số: 9480103.01 LUẬN ÁN TIẾN SĨ NGÀNH CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC: 1. PGS. TS. Nguyễn Việt Hà 2. TS. Đặng Đức Hạnh Hà Nội – 2020
Declaration I hereby declare that the materials presented in this dissertation are my own work, conducted under the supervision of Assoc. Prof., Dr. Nguyen Viet Ha and Dr. Dang Duc Hanh, at the Faculty of Information Technology, University of Engineering and Technology, Vietnam National University, Hanoi. All the research data and results presented in this dissertation are authentic and (to the best of my knowledge) have not previously been published in any academic publications by other authors. Le Minh Duc
Abstract An important software engineering methodology that has emerged over the past twenty years is model-based software development. At the heart of this methodology lies two complementary methods: model-driven software engineering (MDSE) and domain-driven design (DDD). While the aim of MDSE is ambitiously broad, DDD’s goal is more modest and direct but not less important – to apply model-based engineering techniques to tackle the complexity inherent in the domain requirements. The state-of-the-art DDD method includes a set of principles for constructing a domain model that is feasible for implementation in a target programming language. However, this method lacks the solutions needed to address the following important design questions facing a technical team when applying DDD in object oriented programming language (OOPL) platforms: (i) what constitues an essentially expressive domain model and (ii) how to eﬀectively construct a software from this model. The dissertation aims to address these limitations by using annotation-based domain-speciﬁc language (aDSL), which is internal to OOPL, to not only express an essential and uniﬁed domain model but generatively construct modular software from this model. First, we propose an aDSL, named domain class speciﬁcation 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 uniﬁed 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-speciﬁc constructs of this language are expressed in DCSL. To demonstrate the applicability of the approach we deﬁne the UD modelling patterns for tackling the design problems posed by ﬁve core UML activity ﬂows.
Third, we propose a 4-property characterisation for the software that are constructed directly from the domain model. These properties are deﬁned 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 conﬁguration class language (MCCL), that is used for designing module conﬁguration classes (MCCs) in a module-based software architecture. An MCC provides an explicit class-based deﬁnition of a set of module con- ﬁgurations of a given class of software modules. The MCCs can easily be reused to create diﬀerent 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 ﬁrst 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 speciﬁcation lan- guage and evaluate the eﬀectiveness 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 eﬀectively apply the method in OOPL platforms. On the other hand, the method is more complete with solutions for the design aspects that were not originally included.
Tóm tắt Trong vòng hai thập kỷ gần đây, phương pháp luận phát triển phần mềm dựa trên mô hình nổi lên là một phương pháp luận quan trọng trong kỹ nghệ phần mềm. Ở trung tâm của phương pháp luận này có hai phương pháp có tính bổ trợ nhau là: kỹ nghệ phần mềm hướng mô hình (model-driven software engineering (MDSE)) và thiết kế hướng miền (domain-driven design (DDD)). Trong khi MDSE mang một mục tiêu rộng và khá tham vọng thì mục tiêu của DDD lại khiêm tốn và thực tế hơn, đó là tập trung vào cách áp dụng các kỹ thuật của kỹ nghệ dựa trên mô hình để giải quyết sự phức tạp vốn có trong yêu cầu miền. Phương pháp DDD hiện tại bao gồm một tập các nguyên lý để xây dựng một mô hình miền ở dạng khả thi cho triển khai viết mã trên một ngôn ngữ lập trình đích. Tuy nhiên phương pháp này còn thiếu các giải pháp cần thiết giúp giải đáp hai câu hỏi quan trọng mà người phát triển phần mềm thường gặp phải khi áp dụng DDD vào các nền tảng ngôn ngữ lập trình hướng đối tượng (object oriented programming language (OOPL)): (i) những thành phần nào cấu tạo nên một mô hình miền có mức độ diễn đạt thiết yếu? và (ii) xây dựng một cách hiệu quả phần mềm từ mô hình miền như thế nào? Luận án này đặt mục đích khắc phục hạn chế trên của DDD bằng cách sử dụng ngôn ngữ chuyên biệt miền dựa trên ghi chú (annotation-based domain-specific language (aDSL)), được phát triển trong OOPL, để không chỉ biểu diễn một mô hình miền hợp nhất thiết yếu mà còn để xây dựng phần mềm có tính mô-đun từ mô hình miền này. Thứ nhất, luận án đề xuất một aDSL, tên là ngôn ngữ đặc tả lớp miền (domain class specification language (DCSL)), bao gồm một tập các ghi chú để biểu diễn các ràng buộc cấu trúc thiết yếu và các hành vi thiết yếu của lớp miền. Tác giả đã cẩn thận lựa chọn các đặc trưng thiết kế từ một số nguồn tài liệu học thuật có uy tín về
kỹ nghệ phần mềm và kỹ nghệ hệ thống và lập luận rằng các đặc trưng này tạo thành một không gian thiết kế tối giản cho lớp miền. Thứ hai, luận án đề xuất một phương thức tiếp cận mô hình hóa miền hợp nhất, trong đó sử dụng DCSL để biểu diễn các thành phần mô hình hóa cấu trúc và hành vi. Luận án đã chọn ngôn ngữ biểu đồ hoạt động UML cho mô hình hóa hành vi và trình bày cách biểu diễn các đặc trưng chuyên biệt trạng thái của ngôn ngữ này bằng DCSL. Để chứng tỏ tính thực tiễn của cách tiếp cận, luận án định nghĩa một tập mẫu mô hình hóa miền hợp nhất cho các bài toán thiết kế liên quan trực tiếp đến năm luồng hoạt động UML cơ bản. Thứ ba, luận án đề xuất một mô tả đặc điểm gồm bốn tính chất cho phần mềm được xây dựng trực tiếp từ mô hình miền. Bốn tính chất này được định nghĩa dựa trên mô hình khái niệm phần mềm dạng phân lớp, bao gồm mô hình miền ở lớp lõi, một lớp mô-đun trực tiếp bao quanh lớp lõi và một lớp phần mềm ở ngoài. Thứ tư, luận án đề xuất một aDSL thứ hai, tên là ngôn ngữ lớp cấu hình mô-đun (module configuration class language (MCCL)), dùng để thiết kế các lớp cấu hình mô-đun (module configuration classes (MCCs)) trong một kiến trúc phần mềm dựa trên mô-đun. Mỗi MCC cung cấp một định nghĩa dạng lớp cho một tập các cấu hình mô-đun của một lớp mô-đun. Các MCC có thể dễ dàng sử dụng lại để tạo ra các biến thể của một lớp mô-đun mà không cần sửa thiết kế bên trong của mô-đun. Thứ năm, luận án phát triển một bộ công cụ dành cho DCSL, MCCL và các bộ sinh mã của các ngôn ngữ này, dưới dạng các thành phần của một phần mềm khung, tên là JDOMAINAPP. Để đánh giá các kết quả trên, luận án trước hết trình diễn tính thực tiễn của phương pháp bằng cách áp dụng vào một trường hợp nghiên cứu tương đối phức tạp về phát triển phần mềm, liên quan đến quản lý quy trình tổ chức. Tiếp theo, luận án đánh giá DCSL từ khía cạnh một ngôn ngữ đặc tả và đánh giá hiệu quả việc sử dụng MCCL trong xây dựng mô-đun phần mềm một cách tự động. Chúng tôi cho rằng, các đóng góp của luận án giúp phương pháp DDD trở nên cụ thể và đầy đủ hơn. Một mặt, phương pháp trở nên cụ thể hơn với các giải pháp giúp áp dụng một cách hiệu quả vào các nền tảng OOPL. Mặt khác, phương pháp trở nên đầy đủ hơn với các giải pháp cho các khía cạnh thiết kế chưa được xem xét tới.
Acknowledgement I would ﬁrst 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 ﬁnancial 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 sacriﬁces that they have made and for all the love and encouragement that they have given me during my PhD study.
Contents Glossaryv List of Figures vii List of Tables ix 1 Introduction1 1.1 Problem Statement 3 1.1.1 Motivating Example 3 1.1.2 Domain-Driven Design Challenges 5 1.1.3 Research Statement 7 1.2 Research Aim and Objectives 7 1.3 Research Approach 8 1.4 Dissertation Structure 12 2 State of the Art 13 2.1 Background 13 2.1.1 Model-Driven Software Engineering 13 2.1.2 Domain-Speciﬁc Language 15 2.1.3 Meta-Modelling with UML/OCL 17 2.1.4 Domain-Driven Design 22 2.1.5 Model-View-Controller Architecture 27 2.1.6 Comparing and Integrating MDSE with DDD 28 2.1.7 A Core Meta-Model of Object-Oriented Programming Language 29 2.1.8 Using Annotation in MBSD 33 i
2.2 Domain-Driven Software Development with aDSL 35 2.2.1 DDD with aDSL 36 2.2.2 Behavioural Modelling with UML Activity Diagram 36 2.2.3 Software Module Design 40 2.2.4 Module-Based Software Architecture 41 2.3 Summary 45 3 Uniﬁed Domain Modelling with aDSL 46 3.1 Introduction 46 3.2 DCSL Domain 47 3.2.1 Essential State Space Constraints 47 3.2.2 Essential Behaviour Types 48 3.3 DCSL Syntax 49 3.3.1 Expressing the Pre- and Post-conditions of Method 56 3.3.2 Domain Terms 57 3.4 Static Semantics of DCSL 57 3.4.1 State Space Semantics 58 3.4.2 Behaviour Space Semantics 64 3.4.3 Behaviour Generation for DCSL Model 68 3.5 Dynamic Semantics of DCSL 71 3.6 Uniﬁed Domain Model 72 3.6.1 Expressing UDM in DCSL 73 3.6.2 UD Modelling Patterns 76 3.7 Summary 87 4 Module-Based Software Construction with aDSL 88 4.1 Introduction 88 4.2 Software Characterisation 89 4.2.1 An Abstract Software Model 90 4.2.2 Instance-based GUI 91 4.2.3 Model reﬂectivity 92 4.2.4 Modularity 92 4.2.5 Generativity 94 ii
4.3 Module Conﬁguration Domain 95 4.3.1 One Master Module Conﬁguration 95 4.3.2 The ‘Conﬁgured’ Containment Tree 95 4.3.3 Customising Descendant Module Conﬁguration 96 4.4 MCCL Language Speciﬁcation 97 4.4.1 Speciﬁcation Approach 97 4.4.2 Conceptual Model 98 4.4.3 Abstract Syntax 104 4.4.4 Concrete Syntax 110 4.4.5 Semantics 114 4.5 MCC Generation 114 4.5.1 Structural Consistency between MCC and Domain Class 114 4.5.2 MCCGEN Algorithm 116 4.6 Summary 118 5 Evaluation 119 5.1 Implementation 119 5.1.1 UD Modelling 119 5.1.2 Module-Based Software Construction 121 5.2 Case Study: ProcessMan 122 5.2.1 Method 122 5.2.2 Case and Subject Selection 122 5.2.3 Data Collection and Analysis 123 5.2.4 Results 123 5.3 DCSL Evaluation 127 5.3.1 Evaluation Approach 127 5.3.2 Expressiveness 129 5.3.3 Required Coding Level 132 5.3.4 Behaviour Generation 133 5.3.5 Performance Analysis 134 5.3.6 Discussion 134 5.4 Evaluation of Module-Based Software Construction 135 5.4.1 Module Generativity Framework 135 iii
5.4.2 MP1: Total Generativity 137 5.4.3 MP2–MP4 138 5.4.4 Analysis of MCCGen 143 5.4.5 Discussion 144 5.5 Summary 144 6 Conclusion 145 6.1 Key Contributions 146 6.2 Future Work 147 Bibliography 150 Appendices A Helper OCL Functions for DCSL’s ASM 158 B MCCL Speciﬁcation 164 B.1 Library Rules of the MCCL’s ASM 164 B.2 Two MCCs of ModuleEnrolmentMgmt 167 C DCSL Evaluation Data 171 C.1 Expressiveness Comparison Between DCSL and the DDD Frameworks 171 C.2 Level of Coding Comparison Between DCSL and the DDD Frameworks 173 iv
Glossary aDSL Annotation-Based DSL, page 36 ASM Abstract Syntax Meta-model, page 17 AtOP Attribute-Oriented Programming, page 35 BISL Behaviour Interface Speciﬁcation Language, page 35 CSM Concrete Syntax Meta-model, page 17 DCSL Domain Class Speciﬁcation Language, page 51 DDD Domain-Driven Design, page 22 DDDAL DDD with aDSLs, page 8 DSL Domain-Speciﬁc Language, page 15 JML Java Modelling Language, page 36 MCC Module Conﬁguration Class, page 99 MCCL Module Conﬁguration 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-Speciﬁc Model, page 14 SDM Semantic Domain Meta-model, page 17 UDM Uniﬁed Domain Model, page 76 UML Uniﬁeld Modelling Language, page 18 UML/OCL UML made precise with OCL, page 18 vi
List of Figures 1.1 A partial domain model of CourseMan 3 1.2 An overview of DDDAL (with an emphasis on phases 1 and 2) 9 2.1 The essential ASM of UML (synthesised from seven meta-models of UML [57]). 18 2.2 The OCL expression meta-model (Adapted from §8.3 [56]) 20 2.3 A UI class of the domain class Student (Source: [45]) 28 2.4 The UML-based ASM of OOPL 30 2.5 The meta-model of UML activity modelling language (Adapted from §15.2.2 of the UML speciﬁcation [57]) 38 2.6 The UML activity models of ﬁve basic variants of the CourseMan’s enrol- ment management activity 39 2.7 The MOSA model of CourseMan 43 2.8 A ModuleEnrolmentMgmt’s view containing a child ModuleStudent’s view. 44 3.1 The abstract syntax model of DCSL 50 3.2 A DCSL model for a part of the CourseMan domain model 55 3.3 (A: Left) The UML activity and class models of a CourseMan software variant that handles the enrolment management activity; (B: Right) The UDM that results 75 3.4 The sequential pattern form (top left) and an application to the enrolment management activity 77 3.5 The sequential pattern form view of enrolment management activity 78 3.6 The decisional pattern form (top left) and an application to the enrolment management activity 79 3.7 The decisional pattern form view of enrolment management activity 80 vii
3.8 The forked pattern form (top left) and an application to the enrolment man- agement activity 81 3.9 The forked pattern form view of enrolment management activity 82 3.10 The joined pattern form (top left) and an application to the enrolment man- agement activity 83 3.11 The joined pattern form view of enrolment management activity 84 3.12 The merged pattern form (top left) and an application to the enrolment man- agement activity 85 3.13 The merged pattern form view of enrolment management activity 86 4.1 A detailed view of DDDAL’s phase 2 with software module construction 89 4.2 An abstract UML-based software model: (core layer) domain model, (middle layer) module and (top layer) software 90 4.3 The GUI of CourseMan software prototype generated by jDomainApp: (1) main window, (2-4) the UDM’s GUI for EnrolmentMgmt, Student, and Enrolment 91 4.4 The CM of MCCL 98 4.5 (A-shaded area) The transformed CM (CMT ); (B-remainder) Detailed design of the105 key classes of CMT . 4.6 The annotation-based ASM 109 4.7 The view of a (stand-alone) ModuleStudent object 111 4.8 The customised view of ModuleEnrolmentMgmt (as conﬁgured in Listing 4.2).113 5.1 A partial CourseMan’s GUI that is generated by DomainAppTool 121 5.2 ProcessMan’s domain model 124 5.3 A partial MCC Model for process structure 125 5.4 The view of ModuleEnrolmentMgmt of the software in Figure 5.1 138 5.5 An example CourseMan software that has substantially been customised 141 A.1 Utility class ExprTk 158 A.2 Utility class Tk 160 viii
List of Tables 2.1 Meta-mapping between OOPL and UML/OCL 33 3.1 The essential state space constraints 48 3.2 The essential behaviour types 49 3.3 Well-formedness constraints of DCSL 59 3.4 The boolean state space constraints of DCSL 60 3.5 The non-boolean state space constraints of DCSL 63 3.6 The core structural mapping rules 67 3.7 Translating Domain Field properties into JML’s class invariants 72 4.1 Mapping from CM to CMT 107 5.1 The expressiveness aspects and domain properties of interest 128 5.2 (A-left) Comparing DCSL to DDD patterns; (B-right) Comparing DCSL to AL and XL 130 5.3 (A-left) Summary of max-locs for DCSL, AL and XL; (B-right) Summary of typical-locs for DCSL, AL and XL 132 5.4 BSpaceGen for CourseMan 133 5.5 Module pattern classiﬁcation 135 5.6 Module generativity values of two CourseMan’s modules in MP2–MP4 . 140 C.1 Comparing the expressiveness of DCSL to AL, XL 171 C.2 Comparing the max-locs of DCSL to AL, XL 173 C.3 Comparing the typical-locs of DCSL to AL, XL 174 ix
Chapter 1 Introduction There is no doubt that an important software engineering research area over the last two decades is what we would generally call model-based software development (MBSD) – the idea that a software can and should systematically be developed from abtractions, a.k.a models, of the problem domain. MBSD brings many important beneﬁts, including ease of problem solving and improved quality, productivity and reusability. Perhaps a most visible and novel software engineering development that falls under the MBSD umbrella is model-driven software engineering (MDSE) [9, 16, 38, 67]. Another more modest and direct development method is domain-driven design (DDD) [22, 62, 75]. Very early on, Czarnecki [16] stated that MDSE is a type of generative software devel- opment (GSD). The key beneﬁts of MDSE are to signiﬁcantly improve reusability and pro- ductivity in producing software for diﬀerent implementation platforms. These are basically achieved by constructing the high-level (platform-independent) software models before-hand and then very eﬃciently, 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 speciﬁcally on the problem of how to eﬀectively use models to tackle the complexity inherent in the domain requirements. DDD’s goal is to develop software based on domain models that not only truly describe the domain but are technically feasible for implementation. According to Evans [22], object-oriented programming language (OOPL) is especially suited for use with DDD. This is not surprising, given that Booch [8] had ealier pointed out two 1
main reasons why OOPL would result in domain models that are inherently expressive and feasible. First, object naturally represents the (abstract) entities that are conceived to exist in real-world domains. Second, the construct of object used in OOPL is also a basic construct of high-level analysis and design modelling languages that are used to conceptualise and analyse the domain. The domain model, which is primarily studied under DDD and a type of model engineered in MDSE, is in fact the basis for specifying what had been called in the language engineering community as domain-speciﬁc 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 speciﬁcation language (BISL) [32] to deﬁne the speciﬁcation structure. A key beneﬁt of aDSL is that it is internal to the host OOPL and thus does not require a separate syntax speciﬁcation. This helps signiﬁcantly reduce development cost and increase ease-of- learning. In fact, simple forms of aDSL have been used quite extensively in both DDD and MDSE communities. In DDD, annotation-based extensions of OOPLs have been used to develop software frameworks (e.g. [17, 60]) that support the development of not only the domain model but the ﬁnal software. The design rules in these models are expressed by a set of annotations. In MDSE, annotation sets are used to construct platform-speciﬁc models of software [4, 76, 77, 78]. Our initial research started out with an MBSD-typed investigation into a practical problem of how to improve the productivity of object-oriented software development [8, 43, 49, 51] using a Java-based design language for the domain model [44] and a software architectural model [45]. Placing these works in the context of DDD, MDSE and aDSL have given us an opportunity to advance our research to tackle a broader and more important problem concerning the DDD method for object-oriented software. 2
1.1 Problem Statement In this section, we will discuss the key challenges facing DDD for the object-oriented problem domains and deﬁne a research statement that is tackled in this disseration. We motivate our discussion using a software example, which we will also use throughout the dissertation to illustrate the concepts that are being presented. 1.1.1 Motivating Example Figure 1.1: A partial domain model of CourseMan. Our motivating example is a course management problem domain (abbr. CourseMan), which describes a compact, yet complete, domain that includes both structural and behavioural aspects. Figure 1.1 shows a partially completed CourseMan domain model expressed in the form of a UML class diagram [57]. Notationwise, in this dissertation, when it is necessary 3
to highlight the type of model element we will use a/an/the with name of the element type to refer to a particular element, and the plural form of this name to refer to a collection of elements. Further, we will use normal font for high-level concepts and fixed font for domain-speciﬁc and technical concepts. The bottom part of Figure 1.1 shows four classes and two association classes of Course- Man. Class Student represents the domain concept Student, who registers to study in an academic instituition. Class CourseModule represents the Course Modules1 that are oﬀered 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 ﬁgure) and the following description about the six classes. We will give more details about the activity later in Chapter2. – HelpRequest: captures data about help information provided to students. – Orientation: captures data about orientation programs for newly-registered students. – Payment: captures data about payment for the intuition fee that a student needs to make. – Authorisation: captures data about the decision made by an enrolment oﬃcer con- cerning whether or not to allow a student to undertake the registered course modules. – EnrolmentApproval: captures data about the decision made by the enrolment oﬃcer concerning a student’s enrolment. – EnrolmentMgmt: represents the enrolment management activity. This activity involves registering Students, enrolling them into CourseModules and registering them into SClasses. In addition, it allows each Student to raise a HelpRequest. 1 we use class/concept name as countable noun to identify instances. 4
1.1.2 Domain-Driven Design Challenges Let us now outline the key challenges facing domain modelling in DDD and software devel- opment 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, ﬁeld and association. These constraints appear frequently in real-world domain models [34, 48, 49, 57]. We describe these constraints below: 1. Class Payment is immutable, i.e. all objects of this class are immutable. 2. Field Student.name is mutable, i.e. its value can be changed. 3. Student.name is not optional, i.e. its value must be speciﬁed for each object. 4. Student.name does not exceed 30 characters in length. 5. Student.name is not unique, i.e. its value may duplicate among objects. 6. Student.id is an id ﬁeld. 7. Student.id is auto, i.e. its value is automatically generated. 8. The minimum value of CourseModule.semester is 1. 9. The maximum value of CourseModule.semester is 8. 10. The association constraint, e.g. with respect to the enrols-in association, a Student is enrolled in zero or no more than 30 CourseModules, and a CourseModule is enrolled in by zero or more Students. 11. The minimum value of CourseModule.semester in ElectiveModule is 3. These constraints are primitive in the sense that they are applied independently to a single model element (e.g. class Student and Student.id). The key design questions concerning these constraints are: (i) are they essential to real-world domain models? and (ii) how do we represent these constraints in the domain model using an aDSL? 5
Essential Behaviour Types When we consider constraints in designing the domain model, we are eﬀectively constraining the state space of each domain class in the model. For this state space, two orthogonal design questions that can be raised are: (i) what are the essential types of behaviour that operate on a constrained state space? and (ii) how do we specify the behaviour types directly in each domain class, in such a way that can help capture the relationship with the state space? Let us take class Student in Figure 1.1 as an example. Given the constrained state space that is structured around the class and its two attributes (id and name), what are the essential operations that must be deﬁned for this class? More speciﬁcally, is the constructor Student(Student, String) shown in the ﬁgure suﬃcient for creating Student objects that the software needs? What are the basis for deﬁning the other three operations of the class, namely getId, setName and getName? Are there any other essential operations that we need to add to this class? Regarding to modelling the behaviour type, how do we specify the behaviours of, say, the constructor Student(Student, String) and the operations setName and getName so that they make explicit the connections to the attribute Student.name? Clearly, such connections help validate the essentiality of the behaviours, while making the design of Student easier to comprehend. Software Construction from the Domain Model Software construction from the domain model requires this model to essentially support both structural and behavioural modelling elements. UML [57] includes three behavioural modelling languages: state machine and interaction and activity diagrams. The ﬁrst challenge is how to factor in the domain model the behavioural modelling structure (e.g. activity class and activity graph structure of an activity)? For the CourseMan example in Figure 1.1, for instance, how do we deﬁne the activity class EnrolmentMgmt and the activity graph structure of the concerned activity? This would cover the area labelled ‘?’ in the ﬁgure. Another challenge with software construction is what software architecture can be suitable and how to use it to eﬀectively construct software from the domain model? This challenge needs to be addressed in the context of a well-accepted fact that software construction can not be fully automated [26]. The generally accepted position is that a GUI-based tool is employed to assist the development team in the construction process. 6
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 reﬂects 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 ﬁnalised domain model but from the software components (e.g. architectural components, view layouts and view ﬁelds) 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 de- velopment. 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 deﬁne 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 uniﬁed 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 object- 7
oriented software development purposes. On the one hand, the method would become more concrete with speciﬁc solutions that help the technical team eﬀectively 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: 1. To investigate and design a uniﬁed domain model that includes the essential elements for both the structural and behavioural modelling aspects. 2. To investigate and characterise the software that is constructed from the domain model. This should include properties that are speciﬁc to software construction with DDD. 3. To investigate and deﬁne a generative and modular software construction approach. 4. To investigate and design suitable aDSL(s) for the uniﬁed domain model and for software construction. 5. To implement a support tool, which includes the aDSL(s) and their generators. 1.3 Research Approach We take the view that software is a system and apply the system approach [14, 19] to both engineer the software and to tackle the stated research problem. Churchman [14] generically deﬁnes system as “ a set of parts coordinated to accomplish a set of goals”. This deﬁnition 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-deﬁned. 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 deﬁne 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 it- eratively. All three phases are supported by a software framework named jDomainApp 2. 2 paper5 listed in the Publications section. 8
Figure 1.2: An overview of DDDAL (with an emphasis on phases 1 and 2). Phases 1 and 2 are the two key phases of the method and are depicted in Figure 1.2 with more details. The elements that are drawn using dashed lines in the ﬁgure are not within the research scope of this dissertation. Conceptually, phase 1 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 2 is to generate a software prototype that reﬂects 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 1 with an update on the domain model. The process is stopped when the domain model satisﬁes 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 deﬁne a subset of elements for the ﬁrst two phases of DDDAL. We consider these two phases as two sub-problems of our research problem (deﬁned in Section 1.1), which are tackled by carrying out the research objectives (deﬁned in the previous section). We will discuss in more detail below our research approach for tackling these two sub-problems. 9
Sub-Problem 1: Uniﬁed Domain Modelling with aDSL This sub-problem is tackled by performing the research objectives1,4 and5. 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 uniﬁed domain model (UDM) that incorporates both types of features. We call the process for constructing UDM UD modelling. In the spirit of DDD, we encourage but do not force the use of any high- level modelling languages for expressing the input requirement sets. In our method, 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-expert- friendly [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 Speciﬁcation 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 objectives2,3,4 and5. 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 conﬁgurations and capture their design in a module conﬁguration class (MCC). We then apply modelling and abstraction to specify an aDSL, named Module Conﬁguration 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 do not discuss sub-problem (2.b) in detail in this dissertation. Contributions We summarise below ﬁve main contributions of our dissertation that concern the two sub- problems presented above. As the contributions will show, the term “uniﬁed 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. Uniﬁed domain modelling with aDSL: x Domain Class Speciﬁcation 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. y A uniﬁed domain modelling approach: uses DCSL to construct a uniﬁed domain model that incorporates state-speciﬁc modelling elements of UML activity diagram. Module-based software construction with aDSL: z A 4-property software characterisation: to provide a structured guidance for the construction of software from the domain model. { Module Conﬁguration Class Language (MCCL): an aDSL for designing the conﬁg- uration classes for software modules. Each of these classes serves as a template for creating the conﬁgurations 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 into6 chapters that closely reﬂect the stated contributions. In Chapter2, 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 Chapter3, we describe our contributions concerning UD modelling. Taking the view that domain class design is the basis for UDM construction, we ﬁrst specify DCSL for expressing the essential structural and behavioural features of the domain class. We then use DCSL to deﬁne UDM. After that, we present a set of generic UD modelling patterns that can be applied to construct UDMs for real-world domains. In Chapter4, we explain our contributions concerning module-based software construc- tion. We ﬁrst set the software construction context by deﬁning a software characterisation scheme. We then specify MCCL for expressing the MCCs and present a generator for generating the MCCs. In Chapter5, we present an evaluation of our contributions. We ﬁrst describe an imple- mentation 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 Chapter6, 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 2 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 ﬁrst objective is to gather authoritative guidance for and to deﬁne the relevant foundational concepts, methods, and techniques. The second objective is to identify signiﬁcant, 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] deﬁnes MDSE as a more specialised term. In particular, they relate MDSE to a form of MDE and highlights the diﬀerences 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 deﬁnition of both terms from Brambilla et al. [9]. Deﬁnition 2.1. Domain (a.k.a problem domain) is a ﬁeld 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 speciﬁcation of the MDA by OMG. They deﬁne MDA as “ an approach to IT system speciﬁcation that separates the speciﬁcation of system functionality from the speciﬁcation of the implementation of that functionality on a speciﬁc technology platform” [55]. This means that the same system model of the functionality can be applied to diﬀerent implementation platforms. The two types of speciﬁcation in the above deﬁnition are represented by two types of model: platform-independent model (PIM) (the system functionality) and platform-speciﬁc model (PSM) (the platform). MDA deﬁnes four types of model transformations between PIM and PSM and suggests that, to ease maintenance, these transformations be automated as much as possible. The ﬁrst model transformation type is PIM-to-PIM, which is used for design reﬁnement. 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 reﬁnement. 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 eﬀectively reuses MDE to deﬁne 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 deﬁnitions are just models (called meta-models) with mappings deﬁned 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]). 1 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 eﬀective domain modelling. This prob- lem arised from a fact that software languages were primarily concerned with the solution spaces and, thus, were inadequate for eﬀectively expressing the domain concepts. Schmidt next states that MDE technologies should be developed to use domain-speciﬁc modelling language (DSML) (a type of domain-speciﬁc language (DSL)[39] that is deﬁned through meta-modelling) to construct models and transformation engine and generator to auto- matically 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 deﬁne 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 deﬁnition 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 diﬀerent 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-Speciﬁc Language In general, DSL [40, 50, 74] is a software language that is speciﬁcally designed for expressing the requirements of a problem domain, using the conceptual notation suitable for the domain. An important beneﬁt 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 diﬀerent DSLs are designed for diﬀerent domains, they share some underlying properties that can be used to classify them. DSLs can be classiﬁed 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 classiﬁed as being either vertical or horizontal DSL [39]. A vertical DSL, a.k.a business- oriented DSL, targets a bounded real-world domain. For example, course management is 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 classiﬁed 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 ﬁve years after the OMG’s proposal for MDA/MDD. A plausible explanation for this, as Czarnecki [16] pointed out, is that the MDSE eﬀort 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 insuﬃcient 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 deﬁnes a framework for identifying and combining the DSLs that form 16
a complete software model. More speciﬁcally, this entails a 3-step development method: (i) determine the application architecture, (ii) develop the DSLs that ﬁt this architecture and (iii) combine the DSLs by deﬁning transformations between them. In this method, the DSLs are designed to address diﬀerent 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 deﬁning 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 speciﬁcation consists in three meta-models and the rela- tions between them. The ﬁrst 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 de- scribes 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 deﬁned 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 Uniﬁeld 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 speciﬁcation itself [56] to deﬁne 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 deﬁne 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 speciﬁcation to use UML/OCL to deﬁne itself. Speciﬁcally, we ﬁrst construct the ASM of UML and introduce very brieﬂy 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, suﬃces for our research purpose in this dissertation. A meta-concept is represented in the ﬁgure 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 speciﬁcation [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 speciﬁcation: – Abstract syntax of the root (foundational) concepts of UML (see §7.2.22) – Abstract syntax of Classiﬁers (the base concept of UML’s classiﬁcation) (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 Classiﬁer – 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 deﬁned. For instance, meta-concept Class is deﬁned in the meta-model of §11.4.2. The ASM presented in Figure 2.1 includes two new meta-concepts: Attribute and Asso- ciation End. These meta-concepts, whose rectangles are ﬁlled in gray, are sub-types of the meta-concept Property. We use the two meta-concepts to diﬀerentiate 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 speciﬁcation [56], OCL is a user-friendly, typed, formal language for constructing expressions on UML models. OCL expressions are side-eﬀect-free and each has a type. Typical examples of OCL expressions are invariants and queries over a UML model. The OCL speciﬁcation consists in two packages: type (§8.2) and expression (§8.3). The former deﬁnes the valid types for the expressions in the latter. In the type package, all OCL types are derived from Classifier3 (see UML speciﬁcation §9.2.2). Two core OCL types 2 we use the symbol § to denote sections in the UML speciﬁcation. 3 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 diﬀerent 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 identiﬁed by a name. Similar to CollectionType, TupleType is also nested. This means that the attributes in a tuple can have their types deﬁned as TupleTypes. The expression package, whose meta-model is shown in Figure 2.2, speciﬁes 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 deﬁne a condition against which the elements are checked. An OclExpression is deﬁned 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 speciﬁcation [57], which states that an aggregation is a binary association: 1 context Association inv: 2 self.memberEnd->exists( 3 e | e.aggregation size() = 2 and 6 memberEnd->exists(aggregation = AggregationKind::none)) Line 1 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 speciﬁed at lines 2–3 and B is speciﬁed 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 satisﬁes 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 eﬀectively means to ﬁnd 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 bi- nary) 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 deﬁning the SDM of a language. The ﬁrst 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 deﬁnes 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 7 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], object- oriented programming languages (OOPLs), such as Java [3, 28], are a natural ﬁt 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 speciﬁcally 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 - satisﬁability) the domain model satisﬁes 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 ﬁve patterns of the ﬁrst 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 speciﬁc 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 concep- tual modelling [34], should be treated with special care in DDD. The key design consideration is that entity is an object deﬁned fundamentally by its identity. This identity, which is typi- cally 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 deﬁned 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 deﬁned with an identity attribute. All but the 23
two classes CourseModule and ElectiveModule are deﬁned 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 speciﬁc 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 identiﬁer, but this identiﬁer is the only attribute of interest. The identiﬁer values carry domain-speciﬁc information that are signiﬁcant 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 ﬁrst type is named PaymentStatus, which describes a ﬁxed 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 ﬁxed 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 do not ﬁt the responsibility of entity. These behaviours operate on entities but typically do not need to maintain state information like entities. Therefore, these behaviours are deﬁned 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 diﬀerent 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-speciﬁc 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-speciﬁc, activity-based logic which requires coordinating the behaviours deﬁned by other domain classes in the model. domain events. This pattern describes when and how domain-speciﬁc events are mod- elled 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 ser- vices). 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) deﬁne 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 program- ming [51] is applied to the domain model. Evans [22] deﬁnes module as a sub-structure of the domain model that “brings together elements of the model with particularly rich concep- tual 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 deﬁne modules, but allows the designer to have the ﬂexibility 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 do 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 deﬁnes 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 speciﬁc 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 speciﬁcation and ensuring the correctness of this speciﬁcation is a non-trivial task. Second, a domain model speciﬁed 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 signiﬁcantly reduce the development eﬀort, 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 beneﬁt 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 com- ponent 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 (ex- cluding 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 re- sponsible 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 ﬁelds of the UI class of Student. When the state of a domain object is changed, a change notiﬁcation 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 beneﬁt 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 diﬀerent levels of abstraction (e.g. platform-independent and platform-dependent). However DDD diﬀers 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 meta- modelling 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 struc- ture 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 ﬁgure. First, meta-concept Class represents both class and interface (an interface is a class that has no ﬁelds). Second, meta-concept AnnotatedElement is modelled as super- type 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. Deﬁnition 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 Sec- tion 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 deﬁned 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
Deﬁnition 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 deﬁnes 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#. Deﬁnition 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 deﬁned 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 Deﬁnition 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 paper4, which is listed in the Publications section. In this dissertation, we will use annotation 31
property as presented in Deﬁnition 2.4, because this deﬁnition 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 Deﬁnition 2.4 that there exists a reference relationship between the anno- tations. 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 deﬁned 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 deﬁnition makes clear the meaning of annotation instance and its connection to the assignment of annotation to non-annotation element. Deﬁnition 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 deﬁned, 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 OOPL UML/OCL Map# meta-concepts 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 diﬀerent between meta-concepts in the same pair (which may have the same name), we write them in the table using diﬀerent 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 ﬁrst 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 speciﬁcation language (BISL). The third and more recent development concerns the use of annotation to deﬁne 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-speciﬁc 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 do 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-speciﬁc design rules. AtOP can overcome this by allowing domain-speciﬁc 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 deﬁne domain- speciﬁc 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 deﬁning annotation-based embedded models. Behaviour Interface Speciﬁcation 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 speciﬁcation. These BISLs are concerned with deﬁning a speciﬁcation structure for the code model elements (e.g. a Class or a Method) that can be used to capture the domain-speciﬁc requirements concerning those elements. At the unit level, one speciﬁes the behaviour for either a Class or a Method. A behaviour speciﬁcation includes two parts: interface deﬁnition and behaviour description. The former consists in the information needed by other software units. The latter speciﬁes 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 speciﬁcation. However, these BISLs are general-purpose languages and, as such, do not deﬁne rules speciﬁcally 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 classiﬁed this type of language as “fragmentary, internal DSL”. Nosal et al. deﬁned annotation-based DSL based on three types of its composition. The ﬁrst type is language uniﬁcation, in which annotation in the host language is used to deﬁne 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 deﬁnes references to the concepts in another language. These references eﬀectively extend the host language with new concepts. The third type is language extension, in which annotation in the host language deﬁnes new concepts, but these concepts do not exist independently from the host. However, Nosal et al. only provide a general framework and do not provide technical insights for how to construct aDSL. In particular, they do not discuss how meta-modelling (such as using UML/OCL) is used to deﬁne 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 identiﬁed 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 do not formalise their extensions into a language. Second, their extensions, though include many annotations, do not identify those that express the minimal (absolutely essential) annotations. Third, they do 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 2 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 speciﬁc 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-deﬁned 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 meta- modelling approach with UML/OCL (see Section 2.1.3) to deﬁne 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 ﬁgure, Activity itself is a sub-type of Behaviour, which, according to §13.2.2 of the UML speciﬁcation, 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 deﬁnes either data or control ﬂows and, thus, consists of two sub-types: ObjectFlow and ControlFlow (resp.). ObjectFlow (ControlFlow) models the ﬂow 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