A Unified View Approach to Software Development Automation = Phương pháp tiếp cận khung hình 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

Doctor of Philosophy Dissertationin Information Technology

Hanoi - 2020

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LÊ MINH ĐỨC

LUAN AN TIEN SI NGANH CONG NGHE THONG TIN

Hà Nội - 2020

Vietnam National University, Hanoi

VNU University of Engineering and Technology

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Thereby declare that the materials presented in this dissertation are my own work, conductedunder the supervision of Assoc Prof., Dr Nguyen Viet Ha and Dr Dang Duc Hanh, atthe Faculty of Information Technology, University of Engineering and Technology, VietnamNational University, Hanoi All the research data and results presented in this dissertationare authentic and (to the best of my knowledge) have not previously been published in anyacademic publications by other authors.

Le Minh Duc

An important software engineering methodology that has emerged over the past twentyyears is model-based software development At the heart of this methodology lies twocomplementary methods: model-driven software engineering (MDSE) and domain-drivendesign (DDD) While the aim of MDSE is ambitiously broad, DDD’s goal is more modestand direct but not less important — to apply model-based engineering techniques to tackle thecomplexity inherent in the domain requirements The state-of-the-art DDD method includesa set of principles for constructing a domain model that is feasible for implementation in atarget programming language However, this method lacks the solutions needed to addressthe following important design questions facing a technical team when applying DDD inobject oriented programming language (OOPL) platforms: (2) what constitues an essentiallyexpressive domain model and (72) how to effectively construct a software from this model.The dissertation aims to address these limitations by using annotation-based domain-specificlanguage (aDSL), which is internal to OOPL, to not only express an essential and unifieddomain model but generatively construct modular software from this model.

First, we propose an aDSL, named domain class specification language (DCSL), whichconsists in a set of annotations that express the essential structural constraints and the essentialbehaviour of a domain class We carefully select the design features from a number of

authoritative software and system engineering resources and reason that they form a minimumdesign space of the domain class.

Second, we propose a unified domain (UD) modelling approach, which uses DCSL toexpress both the structural and behavioural modelling elements We choose UML activitydiagram language for behavioural modelling and discuss how the domain-specific constructsof this language are expressed in DCSL To demonstrate the applicability of the approach wedefine 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 constructeddirectly from the domain model These properties are defined based on a conceptual layeredsoftware model that includes the domain model at the core, an intermediate module layersurrounding 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 softwarearchitecture An MCC provides an explicit class-based definition of a set of module con-figurations of a given class of software modules The MCCs can easily be reused to createdifferent 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 associatedwith these aDSLs We implement these tools as components in a software framework, namedJ1DOMAINAPP, which we have developed in our research.

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

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

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ềmthườ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 đốitượng (object oriented programming language (OOPL)): (7) những thành phan nàocầu tạo nên một mô hình miền có mức độ diễn đạt thiết yếu? và (22) 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 (domainclass specification language (DCSL)), bao gồm một tập các ghi chú để biểu diễn cácrà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ẩnthậ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 dé 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ànhvi 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 dé 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ìnhmô-đ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ếnthể 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 ta 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 tang OOPL Mặt khác, phương pháp trở nên day đủ 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.

I would first like to thank my supervisors, Assoc Prof Nguyen Viet Ha and Dr DangDuc Hanh, for their instructions and guidance throughout my research and the developmentof this dissertation I would also like to thank all the teachers at the Faculty of InformationTechnology (University of Engineering and Technology, Hanoi) for the very kind supportthat I have received throughout my research study at the department.

I am deeply grateful for my home university (Hanoi University) for providing the PhDstudentship and a gracious teaching arrangement, that has enabled me to have the time tocomplete the required course works and research I am also very grateful for the financialsupport that I have additionally received from the MOET’s 911 fund and the NAFOSTEDproject (grant number 102.03-2015.25), led by Assoc Prof Nguyen Viet Ha.

I would also like to thank all of my colleagues and fellow PhD students for the manymeaningful and entertaining discussions Last but not least, I wish to thank my family for thesacrifices that they have made and for all the love and encouragement that they have givenme during my PhD study.

2 State of the Art 13

2.1.1 Model-Driven Software Engineering 132.1.2 Domain-Specifc Language 152.13 Meta-Modelling wiíhUMUOCL 172.1.4 Domain-Driven Design Ặ.ẶẶ 222.15 Model-View-Controller Architecture 272.1.6 Comparing and Integrating MDSEwithDDD 282.1.7 A Core Meta-Model of Object-Oriented Programming Language 292.1.8 Using AnnotaioninMBSD 33

2.2_ Domain-Driven Software Development withaDSL 35

2.2.1 DDDwithaDSL 00- 362.2.2 Behavioural Modelling with UML Activity Diagram 36

2.2.3 SoftwareModuleDesign 40

2.2.4 Module-Based Software Architecture 41

23 Summary 2 ee 45Unified Domain Modelling with aDSL 463.1 Introduction 2.2 ee 463.2 DCSLDomain 2.0 0 ee ee 473.2.1 Essential State Space Constraints 47

3.2.2 Essential Behaviour Types 000004% 483.3 DCSLSyntax 2 ee 493.3.1 Expressing the Pre- and Post-conditions of Method 56

3.3.2 DomainTerms 2000000 eee 573.4 StaticSemanticsof DCSL 2.2 000 573.41 StateSpace Semantics Ặ Ặ Ặ HQ SẺ 583.4.2 Behaviour Space Semantics 64

3.4.3 Behaviour Generation for DCSL Model 68

ii

43 Module Confsguration Domain 95

4.3.1 One Master Module Confguraton 95

4.3.2 The ‘Configured’ Containment Tre 95

4.3.3, Customising Descendant Module Configuration 96

4.4 MCCL Language Specifcaton ẶẶ Ặ 974.4.1 Specification Approach 2 0.2 002 0008 974.4.2 Conceptual Model 0.00000 ee eee 984.4.3 Abstract Syntax 2 ee kia 1044.4.4 Concrete Syntax 2 2 2.2 ee ee ee 1104.4.5 Semantics 2 0.0 00 2 eee kia 1144.5 MCCGeneration ee ee ee ee 1144.5.1 Structural Consistency between MCC and Domain Class 114

4.5.2 MCCGEN Algorthm 116

4.6 Summary 0 ee ee 118Evaluation 1195.1 Implementation 0200.0000 HQ HH 0000 1195.1.1 UDModelling Ặ.ẶẶẶẶẶẶ 1195.1.2 Module-Based Software Construction 121

5.2 Case Study: ProcessMAN 7 ee ee 1225.2.1 Method 0000000020000 008, 1225.2.2 Case and Subject Selection 2 00 1225.2.3 Data Collection and Analysis 123

5.2.4 Results 2 2 0 ee ee eee 1235.3 DCSL Evaluation 0.0 Q 0000000000 0000 1275.3.1 Evaluation Approach .0.4 1275.3.2 Expressiveness 2 2 ee ee eee 1295.3.3 Required CodingLevel Ặ.Ặ ẶẶ 1325.3.4 BehaviourGeneration 04 1335.3.5 Performance Analysis 0.2- 0000000 % 1345.3.6 Discussion HH ee 1345.4 Evaluation of Module-Based Software Construction 135

5.4.1 Module Generativity Framework 135

iii

5.4.2 MP,: TotadlGeneratiVity Qua

5.4.4 Analysisof MCCGEN ẶẶ Q Q HQ Q 000000045.4.5 DiscussiOon HH HQ ee

6 Conclusion

C.I Expressiveness Comparison Between DCSL and the DDD Frameworks

C.2 Level of Coding Comparison Between DCSL and the DDD Frameworks

171171173

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

Object Constraint Language, page 18

Object-Oriented Programming Language, page 29

Platform-Independent Model, page 14

Platform-Specific Model, page 14

Semantic Domain Meta-model, page 17

Unified Domain Model, page 76

Unifield Modelling Language, page 18

UML/OCL UML made precise with OCL, page 18

vi

List of Figures

of the UML specification [57]) 2 2 ee ee ee ee 38The UML activity models of five basic variants of the CoURsEMAN”S enrol-

ment management actViy Ặ ee 39The MOSA model of CoURsEMAN Ặ.Ặ.Ặ 43A ModuleEnrolmentMgmt’s view containing a child ModuleStudent’s view 44

The abstract syntax model of DCSL 50A DCSL model for a part of the CoursEMAN domain model 55

(A: Left) The UML activity and class models of a CoursEMAN softwarevariant that handles the enrolment management activity; (B: Right) The

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

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 894.2 Anabstract UML-based software model: (core layer) domain model, (middle

layer) module and (top layer) software 904.3 The GUI of CoursEMAN software prototype generated by JDoMAINAppP: (1)

main window, (2-4) the UDM’s GUI for EnrolmentMgmt, Student, and

5.1 A partial CoURsEMAN”s GUI that is generated by DoMAINAPPTOoOL 1215.2 PRocEssMAN sdomainmodel 1245.3 A partial MCC Model for process structure 1255.4 The view of ModuleEnrolmentMgmt of the software in Figure5.1 1385.5 An example CoursEMAN software that has substantially been customised 141

viii

List of Tables

Meta-mapping between OOPL and UML/OCL 33

The essential state space constraints 48

The essential behaviour types 02 0000.4 49Well-formedness constraintsofDCSL 59

The boolean state space constraints of DCSL 60

The non-boolean state space constraints of DCSL 63

The core structural mapping rules 67

Translating Domain Field properties into JML’s class invariants 72

Mapping from CMtoCM;r 0.00 eee eee eee 107The expressiveness aspects and domain properties of interest 128

(A-left) Comparing DCSL to DDD patterns; (B-right) Comparing DCSL toALandXL 1 ee ee 130(A-left) Summary of max-locs for DCSL, AL and XL; (B-right) Summaryof typical-locs for DCSL,ALandXL 132

BSPACEGEN for CouURSEMAN 1 0 ee Kia 133Module pattern classification 2 0000004 135Module generativity values of two CoURsEMAN”s modules in MP,-MP, 140Comparing the expressiveness of DCSLto AL, XL 171

Comparing the max-locs of DCSLto AL,XL 173

Comparing the typical-locs of DCSLto AL,XL 174

ix

Chapter 1

There is no doubt that an important software engineering research area over the last twodecades is what we would generally call model-based software development (MBSD) - theidea that a software can and should systematically be developed from abtractions, a.k.a models,of the problem domain MBSD brings many important benefits, including ease of problemsolving and improved quality, productivity and reusability Perhaps a most visible and novelsoftware engineering development that falls under the MBSD umbrella is model-drivensoftware engineering (MDSE) [9, 16, 38, 67] Another more modest and direct developmentmethod is domain-driven design (DDD) [22, 62, 75].

Very early on, Czarnecki [16] stated that MDSE is a type of generative software opment (GSD) The key benefits of MDSE are to significantly improve reusability and pro-ductivity in producing software for different implementation platforms These are basicallyachieved by constructing the high-level (platform-independent) software models before-handand 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 applicationstep makes extensive use of reusable assets, including software frameworks, components,architectures and models [16].

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

1

main reasons why OOPL would result in domain models that are inherently expressive andfeasible First, object naturally represents the (abstract) entities that are conceived to exist inreal-world domains Second, the construct of object used in OOPL is also a basic constructof 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 engineeredin MDSE, is in fact the basis for specifying what had been called in the language engineeringcommunity as domain-specific language (DSL) [74] The aim of DSL is to express thedomain using concepts that are familiar to the domain experts A key requirement in DSLengineering is to enable the domain experts and the technical team to focus on building thedomain 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 thisrequirement aDSL is an application of the annotation feature of modern OOPLs in DSLengineering Before this, however, annotation (called attribute in C# [33]) was used inattribute-oriented programming (AtOP) [12, 13] to express meta-attributes and in behaviourinterface specification language (BISL) [32] to define the specification structure A keybenefit of aDSL is that it is internal to the host OOPL and thus does not require a separatesyntax specification This helps significantly reduce development cost and increase ease-of-learning.

In fact, simple forms of aDSL have been used quite extensively in both DDD and MDSEcommunities In DDD, annotation-based extensions of OOPLs have been used to developsoftware frameworks (e.g [17, 60]) that support the development of not only the domainmodel but the final software The design rules in these models are expressed by a set of

annotations In MDSE, annotation sets are used to construct platform-specific models ofsoftware [4, 76, 77, 78].

Our initial research started out with an MBSD-typed investigation into a practical problemof how to improve the productivity of object-oriented software development [8, 43, 49, 51]using a Java-based design language for the domain model [44] and a software architecturalmodel [45] Placing these works in the context of DDD, MDSE and aDSL have given usan opportunity to advance our research to tackle a broader and more important problemconcerning the DDD method for object-oriented software.

1.1 Problem Statement

In this section, we will discuss the key challenges facing DDD for the object-oriented problemdomains and define a research statement that is tackled in this disseration We motivate ourdiscussion using a software example, which we will also use throughout the dissertation toillustrate the concepts that are being presented.

1.1.1 Motivating Example

Authorisation= - id: int

(1) immutable - payDetails: String — id: int

- description: String - authorDetails: String

- status: PaymentStatus - description: String

- status: AuthorzStatus

EnrolmentApprovalHelpRequest - id: int

- approved: boolean

- id: int EnrolmentMgm PP

- content: String ~ id: int i

- id: int

— id: int - internalMark: Double

- name: String - examMark: Double

- finalGrade: char

(10) cardinalityconstraint

Figure 1.1: A partial domain model of CoursEMan.

Our motivating example is a course management problem domain (abbr CoURsEMAN),which describes a compact, yet complete, domain that includes both structural and behaviouralaspects Figure 1.1 shows a partially completed CoursEMAN domain model expressed in theform of a UML class diagram [57] Notationwise, in this dissertation, when it is necessary

to highlight the type of model element we will use a/an/the with name of the element typeto refer to a particular element, and the plural form of this name to refer to a collectionof elements Further, we will use normal font for high-level concepts and fixed font fordomain-specific and technical concepts.

The bottom part of Figure |.1 shows four classes and two association classes of Man Class Student represents the domain concept Student, who registers to study in anacademic instituition Class CourseModule represents the Course Modules! that are offeredby the institution Class ElectiveModule represents a specialised type of CourseModule.Class SClass represents the student class type (morning, afternoon, or evening) for studentsto choose Association class SClassRegistration captures details about the many-manyassociation between Student and SClass Finally, association class Enrolment capturesdetails about the many-many association between Student and CourseModule.

CouRSE-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 enrolmentmanagement We know some design details (the attributes shown in the figure) and thefollowing description about the six classes We will give more details about the activity laterin Chapter 2.

— HelpRequest: captures data about help information provided to students.

— Orientation: captures data about orientation programs for newly-registered students.

— Payment: captures data about payment for the intuition fee that a student needs tomake.

— Authorisation: captures data about the decision made by an enrolment officer cerning whether or not to allow a student to undertake the registered course modules.

con-— EnrolmentApproval: captures data about the decision made by the enrolment officerconcerning a student’s enrolment.

— EnrolmentMgmt: represents the enrolment management activity This activity involvesregistering Students, enrolling them into CourseModules and registering them into

SClasses In addition, it allows each Student to raise a HelpRequest.

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

1.1.2 Domain-Driven Design Challenges

Let us now outline the key challenges facing domain modelling in DDD and software opment from the domain model Understanding these challenges leads us to formulate a setof open issues for the research statement that we tackle in this dissertation.

devel-Essential Constraints

The UML note boxes in Figure 1.1 shows examples of 11 kinds of constraints concerning class,field and association These constraints appear frequently in real-world domain models [34,48, 49, 57] We describe these constraints below:

Class Payment is immutable, i.e all objects of this class are immutable.

Field Student.name is mutable, i.e its value can be changed.

Student.name is not optional, i.e its value must be specified for each object.

Student.name does not exceed 30 characters in length.

Student.name is not unique, i.e its value may duplicate among objects.

Student.id is an id field.

Student.id is auto, i.e its value is automatically generated.

The minimum value of CourseModule.semester is 1.

The maximum value of CourseModule.semester is 8.

The association constraint, e.g with respect to the enrols-in association, a Student isenrolled in zero or no more than 30 CourseModules, and a CourseModule is enrolledin by zero or more Students.

The minimum value of CourseModule.semester in ElectiveModule is 3.

These constraints are primitive in the sense that they are applied independently to a singlemodel element (e.g class Student and Student.id) The key design questions concerningthese constraints are: (7) are they essential to real-world domain models? and (22) 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 effectively constrainingthe state space of each domain class in the model For this state space, two orthogonal designquestions that can be raised are: (7) what are the essential types of behaviour that operate ona constrained state space? and (i7) how do we specify the behaviour types directly in eachdomain 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 statespace that is structured around the class and its two attributes (id and name), what are theessential operations that must be defined for this class? More specifically, is the constructorStudent(Student, String) shown in the figure sufficient for creating Student objects thatthe software needs? What are the basis for defining the other three operations of the class,namely getId, setName and getName? Are there any other essential operations that we needto add to this class?

Regarding to modelling the behaviour type, how do we specify the behaviours of, say, theconstructor Student(Student, String) and the operations setName and getName so thatthey make explicit the connections to the attribute Student name? Clearly, such connectionshelp validate the essentiality of the behaviours, while making the design of Student easierto comprehend.

Software Construction from the Domain Model

Software construction from the domain model requires this model to essentially supportboth structural and behavioural modelling elements UML [57] includes three behaviouralmodelling languages: state machine and interaction and activity diagrams The first challengeis how to factor in the domain model the behavioural modelling structure (e.g activity classand activity graph structure of an activity)? For the CoursEMAN example in Figure 1.1, forinstance, how do we define the activity class EnrolmentMgmt and the activity graph structureof the concerned activity? This would cover the area labelled ‘?’ in the figure.

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

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

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

1.1.3 Research Statement

DDD is a design method that tackles the complexity that lies at the heart of software velopment However, in the context of the challenges presented above, we argue that thereare still important open issues concerning the object-oriented problem domains that needto be addressed These issues fall into two main areas: domain modelling and softwaredevelopment from the domain model First, the domain model does not define the essentialstructural elements and lacks support for behavioural modelling Second, there has beenno formal study of how aDSL is used in DDD This is despite the fact that annotation isbeing used quite extensively in implementations of the method in the existing DDD softwareframeworks Third, there has been no formal study of how to construct software from thedomain model In particular, such a study should investigate generative techniques (similarto those employed in MDSE) that are used to automate software construction.

de-1.2 Research Aim and Objectives

In this dissertation, we aim to address the issues mentioned in the research statement aboveby formally using aDSL to not only construct an essential and unified domain model butgeneratively construct modular software from this model We claim that attaining this aimwould help make the DDD method not only more concrete but more complete for object-

oriented software development purposes On the one hand, the method would become moreconcrete with specific solutions that help the technical team effectively apply the method inthe OOPL platforms On the other hand, the method would become more complete withsolutions for the design aspects that were not originally included We organise our researchwith the following objectives:

1 To investigate and design a unified domain model that includes the essential elementsfor both the structural and behavioural modelling aspects.

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

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

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

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

1.3 Research Approach

We take the view that software is a system and apply the system approach [14, 19] to bothengineer the software and to tackle the stated research problem Churchman [14] genericallydefines system as “ a set of parts coordinated to accomplish a set of goals” This definitionmeans 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 softwareis one whose behaviour and interaction between the software components are initially notwell-defined A main characteristic of the system engineering approach for such software isthat it is broken down into stages, which are performed in a disciplined manner to build thesystem We adapt the iterative software engineering method [43, 70] to define an enhancedDDD method, shown in Figure 1.2 and which we call DDD with aDSLs (DDDAL).

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

it-2 paper 5 listed in the Publications section.

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

Phases 1 and 2 are the two key phases of the method and are depicted in Figure 1.2 withmore details The elements that are drawn using dashed lines in the figure are not withinthe research scope of this dissertation Conceptually, phase 1 takes as input the (typicallyincomplete) structural and behavioural requirements from the domain experts and produceas output a domain model, called UDM The purpose of phase 2 is to generate a softwareprototype that reflects the domain model in such a way that the project team can, in phase 3,intuitively review the model, the software and the associated requirements The subsequent

iterations repeat at phase | with an update on the domain model The process is stopped whenthe domain model satisfies the requirements From here, it is used to develop the production

software The generated software prototype is reusable for this development.

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

Sub-Problem 1: Unified Domain Modelling with aDSL

This sub-problem is tackled by performing the research objectives 1, 4 and 5 We conducta literature survey on the essential structural and behavioural features of the domain classand apply modelling and abstraction [19] to construct a unified domain model (UDM)that incorporates both types of features We call the process for constructing UDM UDmodelling In the spirit of DDD, we encourage but do not force the use of any high-level modelling languages for expressing the input requirement sets In our method, thedesigner works closely with the domain expert to map the input requirements, together withany 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 prototypethat is constructed directly from the UDM We design the structural aspect of the UDMusing UML class diagram and the behavioural aspect using UML activity diagram Wechoose 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 (statemachine and interaction diagram [57]) To express UDM, we propose an aDSL namedDomain Class Specification Language (DCSL) We apply modelling to specify DCSL andimplement this language as part of the J]DoMAINAPP framework We evaluate DCSL in termsof expressiveness, required coding level and constructibility.

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

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

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

to construct software from these modules We perform a literature survey on DDD, DDDframeworks and software design properties We then characterise a software in terms of fouressential 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 toexplicitly model software in terms of a set of modules Software modules are instantiated frommodule classes The core component of each module class is a domain class To automaticallyconstruct the module class, we focus on the module configurations and capture their design ina module configuration class (MCC) We then apply modelling and abstraction to specify anaDSL, named Module Configuration Class Language (MCCL), to express the MCCs Weimplement MCCL as a component of the JDomaINApp framework and evaluate module-based

10

software construction with MCCL.

The sDomainApp framework has an implementation for the sub-problem (2.b) However,we do not discuss sub-problem (2.0) in detail in this dissertation.

We summarise below five main contributions of our dissertation that concern the two problems presented above As the contributions will show, the term “unified view” in thedissertation’s title refers to our aDSL-centric view of automated software construction fromthe domain model: (2) domain model is expressed using an aDSL, named DCSL; (22) softwaremodule construction is automated by using another aDSL, named MCCL.

sub-Unified domain modelling with aDSL:

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

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

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

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

Module-based software construction with aDSL:

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

construction of software from the domain model.

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

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

® Tool support: to evaluate the aforementioned contributions and to ease the adoption of ouroverall DDDAL method in real-world software projects, we implement DCSL, MCCL andthe associated generators as components in the JDoMAINAPP software framework.

11

1.4 Dissertation Structure

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

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

In Chapter 4, we explain our contributions concerning module-based software tion We first set the software construction context by defining a software characterisationscheme We then specify MCCL for expressing the MCCs and present a generator forgenerating the MCCs.

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

imple-In Chapter 6, we conclude the dissertation with a summary of the research problem, thecontributions that we made and the impacts that these have on advancing the DDD method.We also highlight a number of ideas and directions for future research in this area.

12

Chapter 2

State of the Art

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

2.1 Background

We begin in this section with a review of the relevant background concepts, methods andtechniques concerning MDSE, DDD and OOPL In particular, we highlight the role 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 systemengineering method called model-driven engineering (MDE) MDE in turn was inventedon the basis of model-driven architecture (MDA) [55] Early works, especially by Kentet al [38] and Schmidt [67], use the term MDE A recent book by Brambilla et al [9]defines MDSE as a more specialised term In particular, they relate MDSE to a form ofMDE and highlights the differences between the latter and two other related terms (MDA andmodel-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” meansengineering) MDA, on the other hand, is a particular realisation of MDD by the ObjectManagement Group (OMG)'.

Since our aim in this dissertation is to study the development of software systems, we willlimit our focus to just MDSE Before reviewing the related work, let us clarify the meaningof two basic and related terms: domain and domain model We adopt the following recentdefinition of both terms from Brambilla et al [9].

Definition 2.1 Domain (a.k.a problem domain) is a field of expertise that needs to beexamined to solve a problem Domain model is the conceptual model of the domain.

The work by Kent et al [38] serves as a good light-weight introductory background forMDSE, not only because of the timing of its publication but because it broadly covers MDEand does so on the basis of an initial draft specification of the MDA by OMG They defineMDA as “ an approach to IT system specification that separates the specification of systemfunctionality from the specification of the implementation of that functionality on a specifictechnology platform” [55] This means that the same system model of the functionality canbe applied to different implementation platforms The two types of specification in the abovedefinition are represented by two types of model: platform-independent model (PIM) (the

system functionality) and platform-specific model (PSM) (the platform).

MDA defines four types of model transformations between PIM and PSM and suggeststhat, to ease maintenance, these transformations be automated as much as possible The firstmodel transformation type is PIM-to-PIM, which is used for design refinement The secondtype is PIM-to-PSM, which is for realising PIM in a particular platform The third typeis PSM-to-PSM, which is for platform model refinement The fourth type is PSM-to-PIM,

which is for reverse engineering PIMs from PSMs of an existing platform.

Next, Kent et al suggest that meta-modelling be used to specify the languages thatare used to express models This is attractive because it effectively reuses MDE to defineitself A meta-model is a model that expresses the shared structure of a set of related

models Among the key points about meta-modelling are: (i) language definitions are justmodels (called meta-models) with mappings defined between them, (22) meta-modelling canbe used to specify the abstract and concrete syntax, and the semantics of a language and (22)

meta-modelling is achievable with an object-oriented modelling language (e.g MOF [58]).

‘http: //www.omg.org

14

Schmidt [67] both reinforces the work by Kent et al and discusses another importantcontribution of MDE to software development He argues that MDE had a potential foraddressing the abstraction gap problem, through effective domain modelling This prob-lem arised from a fact that software languages were primarily concerned with the solutionspaces and, thus, were inadequate for effectively expressing the domain concepts Schmidtnext states that MDE technologies should be developed to use domain-specific modellinglanguage (DSML) (a type of domain-specific language (DSL) [39] that is defined throughmeta-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 toengineering software They define MDSE as “ a methodology for applying the advantagesof modelling to software engineering activities’ The key concepts that MDSE entailsare models and transformations (or “manipulation operations” on models) This definitionthen serves as the basis for integrating MDSE into four well-known software developmentprocesses MDSE may be integrated into the traditional development processes (such aswaterfall, spiral, and the like) by making models the primary artefacts and by using modeltransformation techniques to automate (at least partially) the activites that are performedwithin and at the transition between different phases.

MDSE can also be integrated into agile, domain-driven design (DDD) and test-drivendevelopment processes Within the scope of this dissertation, we are interested in theintegration capability of MDSE into DDD We will discuss this capability in Section 2.1.6.

2.1.2 Domain-Specific Language

In general, DSL [40, 50, 74] is a software language that is specifically designed for expressingthe requirements of a problem domain, using the conceptual notation suitable for the domain.An important benefit of DSL is that it raises the level of abstraction of the software modelto the level suitable for the domain experts and thus help them participate more actively andproductively into the development process Despite the fact that different DSLs are designedfor different domains, they share some underlying properties that can be used to classify them.DSLs can be classified based on domain [39] or on the relationship with the target

15

(a.k.a host) programming language [25, 50, 74] From the domain’s perspective, DSLs areclassified as being either vertical or horizontal DSL [39] A vertical DSL, a.k.a business-oriented DSL, targets a bounded real-world domain For example, course management is areal-world domain of CouRsEMAN and the completed domain model of the one shown inFigure |.1 would form the domain model of a vertical DSL for expressing this domain.

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

Regarding to the relationship with the host language [25, 40, 50, 74], DSLs are classifiedas being internal or external In principle, internal DSL has a closer relationship with thehost language than external DSL A typical internal DSL is developed using either the syntaxor 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 outabout five years after the OMG’s proposal for MDA/MDD A plausible explanation for this,as Czarnecki [16] pointed out, is that the MDSE effort until then had only been focusingon addressing the platform complexity issue It had paid almost no attention to the domaincomplexity problem A recent DSL survey [40] reveals that this issue still remains: there hasbeen insufficient focus in DSL research on domain analysis and language evaluation and onthe integration of DSL engineering into the overall software engineering process.

The general method for combining MDSE with DSL is formulated in [9] A technicaldiscussion on how to use meta-modelling to engineer DSLs is presented in [39] The work in[39] proposes two variants of the meta-modelling process: for vertical DSLs, it is the domainmodelling process (discussed in detail in [25]); for horizontal DSLs, it is a pattern-basedmodelling process.

In practice, one of the very early works [77, 78] had experimented with combining MDSEand DSL in a layered, service-oriented architecture, named SMART-Microsoft A key featureof this work is that it defines a framework for identifying and combining the DSLs that form

16

a complete software model More specifically, this entails a 3-step development method: (7)determine the application architecture, (77) develop the DSLs that fit this architecture and(zit) combine the DSLs by defining transformations between them In this method, the DSLsare designed to address different parts of the architecture and each DSL is used to create notone 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 definingDSL More generally, Kleppe [39] suggests that meta-modelling is applicable to any softwarelanguage This includes both DSL and general purpose language (e.g Java [28] and C# [33]).In meta-modelling, a language specification consists in three meta-models and the rela-tions between them The first meta-model describes the abstract syntax and is called abstractsyntax meta-model (ASM) The second meta-model describes the concrete syntax and iscalled concrete syntax meta-model (CSM) The third meta-model describes the semanticsand is called semantic domain meta-model (SDM) According to Kleppe [39], the ASMdescribes 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-determinedpopulation 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 isa 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 isexecuted” Here, “what happens in the computer” is defined based on a representation of thecomputer’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 thatcan be applied A de facto language is Unifield Modelling Language (UML) [57] UMLconsists in a family of languages, one of which is UML class diagram This language, whichwe will refer to in this dissertation as class modelling language, is made more precise whencombined with the Object Constraint Language (OCL) [56] This combination forms anenriched language, which we will generally refer to in this dissertation as UML/OCL Infact, UML/OCL is used in the UML specification itself [56] to define the abstract syntaxesof 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 ison the abstract syntax of a core meta-modelling structure of UML/OCL The meta-conceptsthat form this structure will be used later in this dissertation to define aDSLs The informalsemantics of the meta-concepts are given in [56, 57] In the spirit of meta-modelling, we adoptthe approach used in the UML specification to use UML/OCL to define itself Specifically,we first construct the ASM of UML and introduce very briefly the graphical syntax Afterthat, we discuss OCL and, as an example, explains how OCL is used to express some syntaxrules of the ASM We conclude with a brief review of the approaches for specifying SDM.

The Essential ASM of UML

Figure 2.1: The essential ASM of UML (synthesised from seven meta-models of UML [57]).

The essential ASM for UML consists of the following meta-concepts: Class, Attribute,Association, Association End, Operation, Parameter, Association Class and Generalisation.This ASM, which is shown in Figure 2.1, suffices for our research purpose in this dissertation.A meta-concept is represented in the figure by a labelled rectangle A relationship betweentwo meta-concepts is represented by a line segment that connects the two correspondingrectangles On the one hand, the ASM is derived from a combination of the core structuresof seven relevant UML meta-models presented in the UML specification [57] On the otherhand, it adds two new, more specialised, meta-concepts (Attribute and Association End) formodelling the class structure.

18

The referenced meta-models come from the following sections of the UML specification:

— Abstract syntax of the root (foundational) concepts of UML (see §7.2.27)

— Abstract syntax of Classifiers (the base concept of UML’s classification) (see §9.2.2)

— Abstract syntax of Feature which includes the Parameter concept (see §9.4.2)

— Abstract syntax of Property and the related concepts (see §9.5.2)

— Abstract syntax of Operation and the related concepts (see §9.6.2)

— Abstract syntax of Class — a type of Classifier — and the related concepts (see §11.4.2)

— Abstract syntax of Association and the related concepts (see §11.5.2)

To ease look-up, we label each key element of the ASM with the section reference, withinwhose meta-model the element is defined For instance, meta-concept Class is defined in themeta-model of §11.4.2.

The ASM presented in Figure 2.1 includes two new meta-concepts: Attribute and ciation End These meta-concepts, whose rectangles are filled in gray, are sub-types of themeta-concept Property We use the two meta-concepts to differentiate between properties thatare attributes and those that serve as association ends of associations The former participatein the containment relationship between Class and Attribute, while the latter participate inthe containment relationship between Association and Association End Further, Class has acontainment relationship with Association.

Asso-The Essential OCL

According to the OCL specification [56], OCL is a user-friendly, typed, formal language forconstructing expressions on UML models OCL expressions are side-effect-free and each hasa type Typical examples of OCL expressions are invariants and queries over a UML model.The OCL specification consists in two packages: type ($8.2) and expression (§8.3) The

former defines the valid types for the expressions in the latter In the type package, all OCLtypes are derived from Classifier? (see UML specification §9.2.2) Two core OCL types

2 we use the symbol § to denote sections in the UML specification.

3 we use fixed font here to be consistent with the OCL’s notation style below.

19

referringExp] *

referredType | 0 1

Figure 2.2: The OCL expression meta-model (Adapted from §8.3 [56]).

that are commonly used are CollectionType and TupleType CollectionType has foursub-types, namely SetType, OrderedSetType, SequenceType and BagType, representingsets, order sets, sequences, and bags (resp.) CollectionType is parameterised with anelement type and can be nested A nested CollectionType is one whose element type isanother CollectionType.

The TupleType conveniently combines different types to form an aggregate type, calledtuple Each part of a tuple is represented by an attribute An attribute is typed and is uniquelyidentified by a name Similar to CollectionType, TupleType is also nested This meansthat the attributes in a tuple can have their types defined as TupleTypes.

The expression package, whose meta-model is shown in Figure 2.2, specifies the structureof OCL expression Every 0c1Expression is typed, which is usually not explicitly statedbut derived The core structure of OclExpression is described by VariableExp and theCallExp’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 0c1Expressionsthat define a condition against which the elements are checked.

An Dc1Expression is defined in a context of a model element (e.g a class, an attribute, amethod, etc.) It is via this element that an OclExpression can navigate the model, throughassociation chains, to access other model elements that are of interest A special keywordself is available in every OclExpression for referring to the contextual element To easewriting, this keyword is implicit if omitted.

Example 2.1 Let us illustrate OCL by showing how it is used to express an invarianton the UML’s ASM in Figure 2.1 The invariant is taken from §11.8.1.8 of the UML

specification [57], which states that an aggregation is a binary association:

1 context Association inv:

is)self memberEnd->exists (

e | e.aggregation <> AggregationKind::none)

4 implies

5 (memberEnd->size() = 2 and

6 memberEnd->exists (aggregation = AggregationKind::none) )

Line | uses the keyword context to specify the context of the invariant (keyword inv)to be an Association The invariant is interpreted as being true for every Association

instance (at all times) Lines 2—6 form the body of the invariant It is an implication A > B,where A is specified at lines 2-3 and B is specified at lines 5-6 The keyword implies

means — Lines 2—3 form a CallExp that performs an operation called exists over thecollection self.memberEnd This operation returns true or false depending on whetherthere exists an element of the collection that satisfies the condition: e.aggregation <>AggregationKind: :none In this condition, e is a Variable that points to each collectionelement and AggregationKind: :none means ‘not-an-aggregation’ Thus, the conditioneffectively means to find all Association Ends of the current Association instance that isan aggregation of some kind.

Lines 5-6 state two conditions that hold for memberEnd (which is a short-form ofself.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