Tài liệu A unified view approach to software development automation.

Vietnam National University, Hanoi VNU University of Engineering and Technology LE MINH DUC A Unified View Approach to Software Development Automation Doctor of Philosophy Dissertation in Information Technology Hanoi - 2020 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ LÊ MINH ĐỨC PHƯƠNG PHÁP TIẾP CẬN KHUNG NHÌN HỢP NHẤT CHO TỰ ĐỘNG HÓA PHÁT TRIỂN PHẦN MỀM LUẬN ÁN TIẾN SĨ NGÀNH CÔNG NGHỆ THÔNG TIN Hà Nội - 2020 Vietnam National University, Hanoi VNU University of Engineering and Technology LE MINH DUC A Unified View Approach to Software Development Automation Specialisation: Software Engineering Code: 9480103.01 Doctor of Philosophy Dissertation in Information Technology Supervisors: 1. Assoc. Prof., Dr. Nguyen Viet Ha 2. Dr. Dang Duc Hanh Hanoi – 2020 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ LÊ MINH ĐỨC PHƯƠNG PHÁP TIẾP CẬN KHUNG NHÌN HỢP NHẤT CHO TỰ ĐỘNG HÓA PHÁT TRIỂN PHẦN MỀM Chuyên ngành: Kỹ thuật Phần mềm Mã số: 9480103.01 LUẬN ÁN TIẾN SĨ NGÀNH CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC: 1. PGS. TS. Nguyễn Việt Hà 2. TS. Đặng Đức Hạnh Hà Nội – 2020 Declaration I hereby declare that the materials presented in this dissertation are my own work, conducted under the supervision of Assoc. Prof., Dr. Nguyen Viet Ha and Dr. Dang Duc Hanh, at the Faculty of Information Technology, University of Engineering and Technology, Vietnam National University, Hanoi. All the research data and results presented in this dissertation are authentic and (to the best of my knowledge) have not previously been published in any academic publications by other authors. Le Minh Duc Abstract An important software engineering methodology that has emerged over the past twenty years is model-based software development. At the heart of this methodology lies two complementary methods: model-driven software engineering (MDSE) and domain-driven design (DDD). While the aim of MDSE is ambitiously broad, DDD’s goal is more modest and direct but not less important – to apply model-based engineering techniques to tackle the complexity inherent in the domain requirements. The state-of-the-art DDD method includes a set of principles for constructing a domain model that is feasible for implementation in a target programming language. However, this method lacks the solutions needed to address the following important design questions facing a technical team when applying DDD in object oriented programming language (OOPL) platforms: (i) what constitues an essentially expressive domain model and (ii) how to effectively construct a software from this model. The dissertation aims to address these limitations by using annotation-based domain-specific language (aDSL), which is internal to OOPL, to not only express an essential and unified domain model but generatively construct modular software from this model. First, we propose an aDSL, named domain class specification language (DCSL), which consists in a set of annotations that express the essential structural constraints and the essential behaviour of a domain class. We carefully select the design features from a number of authoritative software and system engineering resources and reason that they form a minimum design space of the domain class. Second, we propose a unified domain (UD) modelling approach, which uses DCSL to express both the structural and behavioural modelling elements. We choose UML activity diagram language for behavioural modelling and discuss how the domain-specific constructs of this language are expressed in DCSL. To demonstrate the applicability of the approach we define the UD modelling patterns for tackling the design problems posed by five core UML activity flows. Third, we propose a 4-property characterisation for the software that are constructed directly from the domain model. These properties are defined based on a conceptual layered software model that includes the domain model at the core, an intermediate module layer surrounding this core and an outer software layer. Fourth, we propose a second aDSL, named module configuration class language (MCCL), that is used for designing module configuration classes (MCCs) in a module-based software architecture. An MCC provides an explicit class-based definition of a set of module configurations of a given class of software modules. The MCCs can easily be reused to create different variants of the same module class, without having to change the module class design. Fifth, we develop a set of software tools for DCSL, MCCL and the generators associated with these aDSLs. We implement these tools as components in a software framework, named jDomainApp, which we have developed in our research. To evaluate the contributions, we first demonstrate the practicality of our method by applying it to a relatively complex, real-world software construction case study, concerning organisational process management. We then evaluate DCSL as a design specification language and evaluate the effectiveness of using MCCL in module-based software construction. We focus the latter evaluation on module generativity. We contend that our contributions help make the DDD method more concrete and more complete for software development. On the one hand, the method becomes more concrete with solutions that help effectively apply the method in OOPL platforms. On the other hand, the method is more complete with solutions for the design aspects that were not originally included. Tóm tắt Trong vòng hai thập kỷ gần đây, phương pháp luận phát triển phần mềm dựa trên mô hình nổi lên là một phương pháp luận quan trọng trong kỹ nghệ phần mềm. Ở trung tâm của phương pháp luận này có hai phương pháp có tính bổ trợ nhau là: kỹ nghệ phần mềm hướng mô hình (model-driven software engineering (MDSE)) và thiết kế hướng miền (domain-driven design (DDD)). Trong khi MDSE mang một mục tiêu rộng và khá tham vọng thì mục tiêu của DDD lại khiêm tốn và thực tế hơn, đó là tập trung vào cách áp dụng các kỹ thuật của kỹ nghệ dựa trên mô hình để giải quyết sự phức tạp vốn có trong yêu cầu miền. Phương pháp DDD hiện tại bao gồm một tập các nguyên lý để xây dựng một mô hình miền ở dạng khả thi cho triển khai viết mã trên một ngôn ngữ lập trình đích. Tuy nhiên phương pháp này còn thiếu các giải pháp cần thiết giúp giải đáp hai câu hỏi quan trọng mà người phát triển phần mềm thường gặp phải khi áp dụng DDD vào các nền tảng ngôn ngữ lập trình hướng đối tượng (object oriented programming language (OOPL)): (i) những thành phần nào cấu tạo nên một mô hình miền có mức độ diễn đạt thiết yếu? và (ii) xây dựng một cách hiệu quả phần mềm từ mô hình miền như thế nào? Luận án này đặt mục đích khắc phục hạn chế trên của DDD bằng cách sử dụng ngôn ngữ chuyên biệt miền dựa trên ghi chú (annotation-based domain-specific language (aDSL)), được phát triển trong OOPL, để không chỉ biểu diễn một mô hình miền hợp nhất thiết yếu mà còn để xây dựng phần mềm có tính mô-đun từ mô hình miền này. Thứ nhất, luận án đề xuất một aDSL, tên là ngôn ngữ đặc tả lớp miền (domain class specification language (DCSL)), bao gồm một tập các ghi chú để biểu diễn các ràng buộc cấu trúc thiết yếu và các hành vi thiết yếu của lớp miền. Tác giả đã cẩn thận lựa chọn các đặc trưng thiết kế từ một số nguồn tài liệu học thuật có uy tín về kỹ nghệ phần mềm và kỹ nghệ hệ thống và lập luận rằng các đặc trưng này tạo thành một không gian thiết kế tối giản cho lớp miền. Thứ hai, luận án đề xuất một phương thức tiếp cận mô hình hóa miền hợp nhất, trong đó sử dụng DCSL để biểu diễn các thành phần mô hình hóa cấu trúc và hành vi. Luận án đã chọn ngôn ngữ biểu đồ hoạt động UML cho mô hình hóa hành vi và trình bày cách biểu diễn các đặc trưng chuyên biệt trạng thái của ngôn ngữ này bằng DCSL. Để chứng tỏ tính thực tiễn của cách tiếp cận, luận án định nghĩa một tập mẫu mô hình hóa miền hợp nhất cho các bài toán thiết kế liên quan trực tiếp đến năm luồng hoạt động UML cơ bản. Thứ ba, luận án đề xuất một mô tả đặc điểm gồm bốn tính chất cho phần mềm được xây dựng trực tiếp từ mô hình miền. Bốn tính chất này được định nghĩa dựa trên mô hình khái niệm phần mềm dạng phân lớp, bao gồm mô hình miền ở lớp lõi, một lớp mô-đun trực tiếp bao quanh lớp lõi và một lớp phần mềm ở ngoài. Thứ tư, luận án đề xuất một aDSL thứ hai, tên là ngôn ngữ lớp cấu hình mô-đun (module configuration class language (MCCL)), dùng để thiết kế các lớp cấu hình mô-đun (module configuration classes (MCCs)) trong một kiến trúc phần mềm dựa trên mô-đun. Mỗi MCC cung cấp một định nghĩa dạng lớp cho một tập các cấu hình mô-đun của một lớp mô-đun. Các MCC có thể dễ dàng sử dụng lại để tạo ra các biến thể của một lớp mô-đun mà không cần sửa thiết kế bên trong của mô-đun. Thứ năm, luận án phát triển một bộ công cụ dành cho DCSL, MCCL và các bộ sinh mã của các ngôn ngữ này, dưới dạng các thành phần của một phần mềm khung, tên là JDOMAINAPP. Để đánh giá các kết quả trên, luận án trước hết trình diễn tính thực tiễn của phương pháp bằng cách áp dụng vào một trường hợp nghiên cứu tương đối phức tạp về phát triển phần mềm, liên quan đến quản lý quy trình tổ chức. Tiếp theo, luận án đánh giá DCSL từ khía cạnh một ngôn ngữ đặc tả và đánh giá hiệu quả việc sử dụng MCCL trong xây dựng mô-đun phần mềm một cách tự động. Chúng tôi cho rằng, các đóng góp của luận án giúp phương pháp DDD trở nên cụ thể và đầy đủ hơn. Một mặt, phương pháp trở nên cụ thể hơn với các giải pháp giúp áp dụng một cách hiệu quả vào các nền tảng OOPL. Mặt khác, phương pháp trở nên đầy đủ hơn với các giải pháp cho các khía cạnh thiết kế chưa được xem xét tới. Acknowledgement I would first like to thank my supervisors, Assoc. Prof. Nguyen Viet Ha and Dr. Dang Duc Hanh, for their instructions and guidance throughout my research and the development of this dissertation. I would also like to thank all the teachers at the Faculty of Information Technology (University of Engineering and Technology, Hanoi) for the very kind support that I have received throughout my research study at the department. I am deeply grateful for my home university (Hanoi University) for providing the PhD studentship and a gracious teaching arrangement, that has enabled me to have the time to complete the required course works and research. I am also very grateful for the financial support that I have additionally received from the MOET’s 911 fund and the NAFOSTED project (grant number 102.03-2015.25), led by Assoc. Prof. Nguyen Viet Ha. I would also like to thank all of my colleagues and fellow PhD students for the many meaningful and entertaining discussions. Last but not least, I wish to thank my family for the sacrifices that they have made and for all the love and encouragement that they have given me during my PhD study. Contents Glossary v List of Figures vii List of Tables ix 1 . . . . . . . 1 3 3 5 7 7 8 12 . . . . . . . . . 13 13 13 15 17 22 27 28 29 33 2 Introduction 1.1 Problem Statement . . . . . . . . . . . . . 1.1.1 Motivating Example . . . . . . . . 1.1.2 Domain-Driven Design Challenges 1.1.3 Research Statement . . . . . . . . . 1.2 Research Aim and Objectives . . . . . . . . 1.3 Research Approach . . . . . . . . . . . . . 1.4 Dissertation Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State of the Art 2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Model-Driven Software Engineering . . . . . . . . . . . . . . . 2.1.2 Domain-Specific Language . . . . . . . . . . . . . . . . . . . . 2.1.3 Meta-Modelling with UML/OCL . . . . . . . . . . . . . . . . 2.1.4 Domain-Driven Design . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Model-View-Controller Architecture . . . . . . . . . . . . . . . 2.1.6 Comparing and Integrating MDSE with DDD . . . . . . . . . . 2.1.7 A Core Meta-Model of Object-Oriented Programming Language 2.1.8 Using Annotation in MBSD . . . . . . . . . . . . . . . . . . . i . . . . . . . . . . . . . . . . 2.2 2.3 3 4 Domain-Driven Software Development with aDSL . . . . . 2.2.1 DDD with aDSL . . . . . . . . . . . . . . . . . . . 2.2.2 Behavioural Modelling with UML Activity Diagram 2.2.3 Software Module Design . . . . . . . . . . . . . . . 2.2.4 Module-Based Software Architecture . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . Unified Domain Modelling with aDSL 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 DCSL Domain . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Essential State Space Constraints . . . . . . . . . 3.2.2 Essential Behaviour Types . . . . . . . . . . . . . 3.3 DCSL Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Expressing the Pre- and Post-conditions of Method 3.3.2 Domain Terms . . . . . . . . . . . . . . . . . . . 3.4 Static Semantics of DCSL . . . . . . . . . . . . . . . . . 3.4.1 State Space Semantics . . . . . . . . . . . . . . . 3.4.2 Behaviour Space Semantics . . . . . . . . . . . . 3.4.3 Behaviour Generation for DCSL Model . . . . . . 3.5 Dynamic Semantics of DCSL . . . . . . . . . . . . . . . 3.6 Unified Domain Model . . . . . . . . . . . . . . . . . . . 3.6.1 Expressing UDM in DCSL . . . . . . . . . . . . . 3.6.2 UD Modelling Patterns . . . . . . . . . . . . . . . 3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . Module-Based Software Construction with aDSL 4.1 Introduction . . . . . . . . . . . . . . . . . . 4.2 Software Characterisation . . . . . . . . . . . 4.2.1 An Abstract Software Model . . . . . 4.2.2 Instance-based GUI . . . . . . . . . . 4.2.3 Model reflectivity . . . . . . . . . . . 4.2.4 Modularity . . . . . . . . . . . . . . 4.2.5 Generativity . . . . . . . . . . . . . . ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 36 36 40 41 45 . . . . . . . . . . . . . . . . 46 46 47 47 48 49 56 57 57 58 64 68 71 72 73 76 87 . . . . . . . 88 88 89 90 91 92 92 94 4.3 4.4 4.5 4.6 5 Module Configuration Domain . . . . . . . . . . . . . . . . . . 4.3.1 One Master Module Configuration . . . . . . . . . . . . 4.3.2 The ‘Configured’ Containment Tree . . . . . . . . . . . 4.3.3 Customising Descendant Module Configuration . . . . . MCCL Language Specification . . . . . . . . . . . . . . . . . . 4.4.1 Specification Approach . . . . . . . . . . . . . . . . . . 4.4.2 Conceptual Model . . . . . . . . . . . . . . . . . . . . 4.4.3 Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . 4.4.4 Concrete Syntax . . . . . . . . . . . . . . . . . . . . . 4.4.5 Semantics . . . . . . . . . . . . . . . . . . . . . . . . . MCC Generation . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Structural Consistency between MCC and Domain Class 4.5.2 MCCGEN Algorithm . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluation 5.1 Implementation . . . . . . . . . . . . . . . . . . . 5.1.1 UD Modelling . . . . . . . . . . . . . . . 5.1.2 Module-Based Software Construction . . . 5.2 Case Study: ProcessMan . . . . . . . . . . . . . 5.2.1 Method . . . . . . . . . . . . . . . . . . . 5.2.2 Case and Subject Selection . . . . . . . . . 5.2.3 Data Collection and Analysis . . . . . . . . 5.2.4 Results . . . . . . . . . . . . . . . . . . . 5.3 DCSL Evaluation . . . . . . . . . . . . . . . . . . 5.3.1 Evaluation Approach . . . . . . . . . . . . 5.3.2 Expressiveness . . . . . . . . . . . . . . . 5.3.3 Required Coding Level . . . . . . . . . . . 5.3.4 Behaviour Generation . . . . . . . . . . . 5.3.5 Performance Analysis . . . . . . . . . . . 5.3.6 Discussion . . . . . . . . . . . . . . . . . 5.4 Evaluation of Module-Based Software Construction 5.4.1 Module Generativity Framework . . . . . . iii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 95 95 96 97 97 98 104 110 114 114 114 116 118 . . . . . . . . . . . . . . . . . 119 119 119 121 122 122 122 123 123 127 127 129 132 133 134 134 135 135 . . . . . 137 138 143 144 144 Conclusion 6.1 Key Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 146 147 5.5 6 5.4.2 M P1 : Total Generativity 5.4.3 M P2 –M P4 . . . . . . . 5.4.4 Analysis of MCCGen . 5.4.5 Discussion . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliography 150 Appendices A Helper OCL Functions for DCSL’s ASM 158 B MCCL Specification B.1 Library Rules of the MCCL’s ASM . . . . . . . . . . . . . . . . . . . . . B.2 Two MCCs of ModuleEnrolmentMgmt . . . . . . . . . . . . . . . . . . . . 164 164 167 C DCSL Evaluation Data C.1 Expressiveness Comparison Between DCSL and the DDD Frameworks . . C.2 Level of Coding Comparison Between DCSL and the DDD Frameworks . . 171 171 173 iv Glossary aDSL Annotation-Based DSL, page 36 ASM Abstract Syntax Meta-model, page 17 AtOP Attribute-Oriented Programming, page 35 BISL Behaviour Interface Specification Language, page 35 CSM Concrete Syntax Meta-model, page 17 DCSL Domain Class Specification Language, page 51 DDD Domain-Driven Design, page 22 DDDAL DDD with aDSLs, page 8 DSL Domain-Specific Language, page 15 JML Java Modelling Language, page 36 MCC Module Configuration Class, page 99 MCCL Module Configuration Class Language, page 99 MDA Model-Driven Architecture, page 13 MDD Model-Driven Development, page 13 MDE Model-Driven Engineering, page 13 MDSE Model-Driven Software Engineering, page 13 v MVC Model-View-Controller, page 27 OCL Object Constraint Language, page 18 OOPL Object-Oriented Programming Language, page 29 PIM Platform-Independent Model, page 14 PSM Platform-Specific Model, page 14 SDM Semantic Domain Meta-model, page 17 UDM Unified Domain Model, page 76 UML Unifield Modelling Language, page 18 UML/OCL UML made precise with OCL, page 18 vi List of Figures 1.1 1.2 A partial domain model of CourseMan. . . . . . . . . . . . . . . . . . . . An overview of DDDAL (with an emphasis on phases 1 and 2). . . . . . . . 2.1 2.2 2.3 2.4 2.5 The essential ASM of UML (synthesised from seven meta-models of UML [57]). The OCL expression meta-model (Adapted from §8.3 [56]). . . . . . . . . A UI class of the domain class Student (Source: [45]). . . . . . . . . . . . The UML-based ASM of OOPL. . . . . . . . . . . . . . . . . . . . . . . . The meta-model of UML activity modelling language (Adapted from §15.2.2 of the UML specification [57]). . . . . . . . . . . . . . . . . . . . . . . . . The UML activity models of five basic variants of the CourseMan’s enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . The MOSA model of CourseMan. . . . . . . . . . . . . . . . . . . . . . A ModuleEnrolmentMgmt’s view containing a child ModuleStudent’s view. 2.6 2.7 2.8 3.1 3.2 3.3 3.4 3.5 3.6 3.7 The abstract syntax model of DCSL. . . . . . . . . . . . . . . . . . . . . . A DCSL model for a part of the CourseMan domain model. . . . . . . . . (A: Left) The UML activity and class models of a CourseMan software variant that handles the enrolment management activity; (B: Right) The UDM that results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The sequential pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The sequential pattern form view of enrolment management activity. . . . . The decisional pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The decisional pattern form view of enrolment management activity. . . . . vii 3 9 18 20 28 30 38 39 43 44 50 55 75 77 78 79 80 3.8 3.9 3.10 3.11 3.12 3.13 4.1 4.2 The forked pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The forked pattern form view of enrolment management activity. . . . . . . The joined pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The joined pattern form view of enrolment management activity. . . . . . . The merged pattern form (top left) and an application to the enrolment management activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The merged pattern form view of enrolment management activity. . . . . . 81 82 83 84 85 86 4.6 4.7 4.8 A detailed view of DDDAL’s phase 2 with software module construction. . 89 An abstract UML-based software model: (core layer) domain model, (middle layer) module and (top layer) software. . . . . . . . . . . . . . . . . . . . . 90 The GUI of CourseMan software prototype generated by jDomainApp: (1) main window, (2-4) the UDM’s GUI for EnrolmentMgmt, Student, and Enrolment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 The CM of MCCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 (A-shaded area) The transformed CM (CMT ); (B-remainder) Detailed design of the 105 key classes of CMT . The annotation-based ASM. . . . . . . . . . . . . . . . . . . . . . . . . . 109 The view of a (stand-alone) ModuleStudent object. . . . . . . . . . . . . . 111 The customised view of ModuleEnrolmentMgmt (as configured in Listing 4.2).113 5.1 5.2 5.3 5.4 5.5 A partial CourseMan’s GUI that is generated by DomainAppTool. . . . ProcessMan’s domain model. . . . . . . . . . . . . . . . . . . . . . . . A partial MCC Model for process structure. . . . . . . . . . . . . . . . . The view of ModuleEnrolmentMgmt of the software in Figure 5.1. . . . . An example CourseMan software that has substantially been customised. 4.3 4.4 4.5 . . . . . 121 124 125 138 141 A.1 Utility class ExprTk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Utility class Tk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 160 viii List of Tables 2.1 Meta-mapping between OOPL and UML/OCL . . . . . . . . . . . . . . . 33 3.1 3.2 3.3 3.4 3.5 3.6 3.7 The essential state space constraints . . . . . . . . . . . . . . The essential behaviour types . . . . . . . . . . . . . . . . . . Well-formedness constraints of DCSL . . . . . . . . . . . . . The boolean state space constraints of DCSL . . . . . . . . . The non-boolean state space constraints of DCSL . . . . . . . The core structural mapping rules . . . . . . . . . . . . . . . Translating Domain Field properties into JML’s class invariants . . . . . . . 48 49 59 60 63 67 72 4.1 Mapping from CM to CMT . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.1 5.2 The expressiveness aspects and domain properties of interest . . . . . . . . (A-left) Comparing DCSL to DDD patterns; (B-right) Comparing DCSL to AL and XL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (A-left) Summary of max-locs for DCSL, AL and XL; (B-right) Summary of typical-locs for DCSL, AL and XL . . . . . . . . . . . . . . . . . . . . BSpaceGen for CourseMan . . . . . . . . . . . . . . . . . . . . . . . . . Module pattern classification . . . . . . . . . . . . . . . . . . . . . . . . . Module generativity values of two CourseMan’s modules in M P2 –M P4 . 128 C.1 Comparing the expressiveness of DCSL to AL, XL . . . . . . . . . . . . . C.2 Comparing the max-locs of DCSL to AL, XL . . . . . . . . . . . . . . . . C.3 Comparing the typical-locs of DCSL to AL, XL . . . . . . . . . . . . . . . 171 173 174 5.3 5.4 5.5 5.6 ix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 132 133 135 140 Chapter 1 Introduction There is no doubt that an important software engineering research area over the last two decades is what we would generally call model-based software development (MBSD) – the idea that a software can and should systematically be developed from abtractions, a.k.a models, of the problem domain. MBSD brings many important benefits, including ease of problem solving and improved quality, productivity and reusability. Perhaps a most visible and novel software engineering development that falls under the MBSD umbrella is model-driven software engineering (MDSE) [9, 16, 38, 67]. Another more modest and direct development method is domain-driven design (DDD) [22, 62, 75]. Very early on, Czarnecki [16] stated that MDSE is a type of generative software development (GSD). The key benefits of MDSE are to significantly improve reusability and productivity in producing software for different implementation platforms. These are basically achieved by constructing the high-level (platform-independent) software models before-hand and then very efficiently, typically with the help of proven automated techniques and tools, applying these models to a new platform to generate the software for it. This application step makes extensive use of reusable assets, including software frameworks, components, architectures and models [16]. While the MDSE’s goal is ambitiously broad and encompassing, DDD [22] focuses more specifically on the problem of how to effectively use models to tackle the complexity inherent in the domain requirements. DDD’s goal is to develop software based on domain models that not only truly describe the domain but are technically feasible for implementation. According to Evans [22], object-oriented programming language (OOPL) is especially suited for use with DDD. This is not surprising, given that Booch [8] had ealier pointed out two 1