1. Generation of IEEE/ISO 42010-2011 Compliant
Views of Platform-Independent Models
Complying with the URDAD Meta Model
Mini-dissertation by
ABRAM PHILIP DE KOCK
(22024582)
submitted in partial fulfilment of the requirements for the degree
MASTER IN INFORMATION TECHNOLOGY
in the
SCHOOL OF INFORMATION TECHNOLOGY
of the
UNIVERSITY OF PRETORIA
Supervisor: Dr. F. Solms (November) (2013)
2. Summary
Use Case, Responsibility Driven Analysis and Design (URDAD) is a semi-
formal service-oriented methodology for requirements gathering. Require-
ments are specified as a Model Driven Architecture (MDA) Platform Inde-
pendent Model (PIM) that conforms to the approach of the Object Man-
agement Group (OMG) to MDE. The construction of a PIM is supported
by the URDAD Domain Specific Language (DSL) with a textual syntax. A
usable graphical syntax is defined to simplify the application of the URDAD
DSL. Usability is gauged through the identification of quality requirements
that are used to both guide and critically evaluate the intuitiveness of the
graphical notation. This project focuses on the service contract and data
structure specifications. They correspond to viewpoints that govern the con-
struction of views, as defined by the IEEE/ISO 42010-2011 specification for
describing software architecture. Modelling tools to implement the graph-
ical syntax were developed for each view. These tools aim to making the
language more accessible for practitioners. The modelling tools were tested
using a non-trivial example of an URDAD PIM which also demonstrated the
consistency and ontological completeness of the graphical syntax. This study
contributes to the field of service-oriented design, and more particularly to
the application of the theory of diagrammatic languages to service-oriented
design.
1
3. Acknowledgements
I would like to express my great appreciation to Dr. Fritz Solms for his
willingness to give his time so generously in order to provide me with guid-
ance. His advice, honest feedback and sincere effort are recognised and
much appreciated. I would like to offer my gratitude to my wife Tarina for
her patience and support, and who during the course of this project had our
beautiful baby daughter Emma. I am particularly grateful for the assistance
given by Ms Hanna Boeke with the use of the English language. Finally, I
wish to thank my parents and friends for their support and encouragement
throughout my study.
2
7. List of Tables
2.1 Advantages of using models in software engineering . . . . . . 25
4.1 Graphical notation definitions for the data structure view . . 67
4.2 Graphical element definition for Service Contract View . . . . 68
5.1 Graphiti vs. GMF . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2 Information contained within the (.genmodel) . . . . . . . . . 73
6.1 Graphical syntax evaluated against the 10 design principles . 81
6
8. List of Figures
2.1 The IEEE/ISO 42010-2011 conceptual model of an architec-
ture description . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 Ontological analysis . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 The 8 variables (Semiology of Graphics) . . . . . . . . . . . . 40
3.3 Principles for cognitively effective visual notation design . . . 42
3.4 A semantic transparency continuum . . . . . . . . . . . . . . 43
3.5 Location relations . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1 The URDAD data specification elements . . . . . . . . . . . . 50
4.2 The URDAD contract specification elements . . . . . . . . . . 56
4.3 PreCondition and postCondition notation . . . . . . . . . . . 59
4.4 ExceptionHandler notation in the UML Specification v2.4.1 . 61
5.1 The Eclipse Modelling Project (EMP) . . . . . . . . . . . . . 70
5.2 The relationship between the various EMP frameworks . . . . 71
5.3 The GMF workflow . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4 The service contract graphical definition model (.gmfgraph) . 74
5.5 The service contract editor . . . . . . . . . . . . . . . . . . . 75
5.6 The service contract tooling definition model (.gmftool) . . . 76
5.7 The service contract mapping definition model (.gmfmap) . . 77
6.1 The service contract view displaying the enrollForPresenta-
tion service contract . . . . . . . . . . . . . . . . . . . . . . . 89
6.2 The service contract view displaying the multiElectrodeVe-
nousCatheterMappingRequirement quality requirements ele-
ment and the multiElectrodeVenousCatheterMapping quality
constraint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.3 The service contract view displaying the refundAmount in-
verse service element . . . . . . . . . . . . . . . . . . . . . . . 94
7
9. 6.4 The data structure view displaying the Enrollments respon-
sibility domain containing the EnrollForPresentationRequest
request and EnrollForPresentationResult result data struc-
tures as well as the EnrollmentPrerequisitesNotSatisfiedEx-
ception exception . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.5 The data structure view displaying the Finance responsibility
domain data structures . . . . . . . . . . . . . . . . . . . . . . 99
6.6 The data structure view displaying the super type relation-
ship between the Finance responsibility domain data struc-
tures and the Storage responsibility domain Entity data struc-
ture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.7 The data structure view displaying the ClientRelationship-
Management responsibility domain data structures . . . . . . 106
6.8 The data structure view displaying basic data types as defined
in the Primitives responsibility domain . . . . . . . . . . . . . 108
6.9 The data structure view displaying the aggregation, associa-
tion and range multiplicity notations . . . . . . . . . . . . . . 109
8
10. Listings
5.1 The ParserImpl.java class for manipulating complex labels
defined in OCL (particularly an Expression) . . . . . . . . . . 78
5.2 Implementation of the parser in the expression label . . . . . 78
6.1 Overview of the Enrollments responsibility domain in con-
crete XML syntax . . . . . . . . . . . . . . . . . . . . . . . . 86
6.2 Overview of the Enrollments responsibility domain in the con-
crete textual syntax . . . . . . . . . . . . . . . . . . . . . . . 86
6.3 enrollForPresentation service contract . . . . . . . . . . . . . 87
6.4 Specifying a service contract in the concrete textual syntax. . 88
6.5 financialPrerequisitesMet and enrollmentPrerequisitesMet pre-
conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.6 enrollmentProcessPerformed and invoiceIssued postconditions 91
6.7 The enrollmentPrerequisitesForPresentationMet state constraint
and studentEnrolledForPresentation state constraint elements
in the concrete XML syntax . . . . . . . . . . . . . . . . . . . 91
6.8 The enrollmentPrerequisitesForPresentationMet state constraint
and studentEnrolledForPresentation state constraint elements
in the concrete textual syntax . . . . . . . . . . . . . . . . . . 92
6.9 enrollForPresentation service . . . . . . . . . . . . . . . . . . 92
6.10 multiElectrodeVenousCatheterMappingRequirement quality re-
quirement element . . . . . . . . . . . . . . . . . . . . . . . . 93
6.11 inverseService inverse service element . . . . . . . . . . . . . 93
6.12 EnrollForPresentationRequest and EnrollForPresentationRe-
sult data structure elements in the concrete XML syntax . . . 94
6.13 EnrollForPresentationRequest and EnrollForPresentationRe-
sult data structure elements in the concrete textual syntax . . 95
6.14 EnrollmentPrerequisitesNotSatisfiedException exception in the
responsibility domain Enrollments (XML syntax) . . . . . . . 97
6.15 EnrollmentPrerequisitesNotSatisfiedException exception in the
responsibility domain Enrollments (text syntax) . . . . . . . 97
6.16 The Finance responsibility domain (XML syntax) . . . . . . 97
6.17 The Finance responsibility domain (Text syntax) . . . . . . . 98
6.18 The ClientRelationshipManagement responsibility domain (XML
syntax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
9
11. 6.19 The ClientRelationshipManagement responsibility domain (text
syntax) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.20 Basic data types in the concrete XML syntax within the
Primitives responsibility domain . . . . . . . . . . . . . . . . 107
6.21 Basic data types in the concrete textual syntax within the
Primitives responsibility domain . . . . . . . . . . . . . . . . 107
6.22 The aggregation and association relationships and range mul-
tiplicity constraint in the concrete XML syntax . . . . . . . . 108
A.1 enrollForPresentation service contract . . . . . . . . . . . . . 122
B.1 enrollments responsibility domain including the enrollForP-
resentation service contract . . . . . . . . . . . . . . . . . . . 124
10
12. Chapter 1
Introduction and
Background
1.1 Introduction
The increase in scale of software systems and the rapid growth in their
complexity greatly increases the potential of errors occurring in the design
and construction of software systems [20]. Errors have the potential to be
particularly costly since the cost of errors is compounded as software tran-
sitions through the phases of software development [61]. According to Gilb
and Finzi (1988) correcting errors during design is ten times less expensive
than during the development phase and a hundred times less expensive than
fixing an error once the system has been deployed [29].
1.1.1 Formal Methods
Formal methods have been developed to address some of these concerns. In
particular, they illuminate inconsistencies, ambiguities and the incomplete-
ness of systems [20]. Formal methods facilitate the construction of reliable
software. Formal methods aim to achieve this through providing unam-
biguous requirements in addition to designs capable of being proven to be
accurate and reliable [46]. However, the perception of formal methods has
been that they are very expensive [33] and generally do not scale up well
from small-scale applications [37].
1.1.2 Model Driven Engineering (MDE)
The challenges surrounding formal methods have resulted in the develop-
ment of a range of semi-formal methods capable of retaining the benefits
of formality whilst addressing concerns regarding complexity and cost [14].
Model Driven Engineering (MDE) approaches fall within the class of semi-
formal methods. MDE is an overarching paradigm of software development
11
13. vested in the exploitation of domain models. MDE proposes a promising
approach to generative techniques, specifying the realisation of executable
models that are based on formal semantics [45].
1.1.3 Model Driven Architecture (MDA)
The Object Modelling Group (OMG) has attempted to realise the concept
of MDE through Model Driven Architecture (MDA). MDA is supported by
a set of OMG standards [43] which can be implemented to produce tools
that facilitate the application of MDE. MDA reduces complexity by sepa-
rating the functional and non-functional requirements of systems in order to
address the different aspects of a system independently [64]. MDA achieves
the separation through the representation of a system at a higher level of
abstraction where implementation details can be disregarded [64]. MDA
captures these requirements without the need to commit to a technology
platform [64]. The concept of a Platform Independent Model (PIM) in
MDA, realises the higher level of abstraction by representing the functional
requirements of a system [25].
1.1.4 Use Case, Responsibility Driven Analysis and Design
(URDAD)
The OMG offers an approach to MDA as well as standards for tool sup-
port. The OMG provides guidance instead of prescribing, and accordingly
MDA does not specify the model structure of source models and does not
prescribe any methodology for analysing and designing them. URDAD pro-
vides a services-oriented analysis and design methodology which can be used
to generate an MDA PIM [70]. The URDAD methodology provides domain
experts with the ability to model requirements in a technology-neutral man-
ner [70]. It provides a simple, repeatable manner in which to generate MDA
PIM’s allowing functional requirements to remain technology neutral [70].
URDAD bolsters its formal aspects through model verification and a formal
model structure specification [71].
URDAD PIMs have been documented utilising the Unified Model Lan-
guage (UML) due to the wide adoption and corresponding tool support
throughout the software industry [68]. This has proven complex as, in addi-
tion to the lack of a defined model structure capable of sufficiently express-
ing the constraints of a valid URDAD PIM, UML lacks support for certain
URDAD concepts [68]. The wide variation in model structure and content
permitted by UML contributes to the difficulty in generating an URDAD
PIM [71]. The difficulty results from the increased complexity of imple-
mentation mapping [71] caused by the lack of structure and wide variation
in permitted model content. Further, the UML specification lacks a stan-
dard notation for rendering precondition and postcondition [71] constraints
12
14. in the context of URDAD. This is required for rendering an URDAD PIM
and places a dependency on supporting tools. The lack of such tool support
requires the practitioner to populate dependency relationships directly on
the model [71].
1.2 Problem Background
Model-driven approaches to software development have the advantage that
the business requirements exist within the model [27]. The model is, in ef-
fect, the business requirement [27] and vice versa. Changes to requirements
are implicitly reflected in the model, which ensures integrity between the
model and requirements [27]. In addition, a model-driven approach pro-
vides a platform for generating tool support to further simplify requirement
specification [27].
Using models in software engineering has several advantages, including:
• reuse at the design level,
• reduced system complexity,
• reduced coding costs,
• reduced testing costs,
• reduced documentation costs, and
• increased maintainability and enhanceability [24].
MDA is a framework that provides way of automating the generation of
applications from models [41] and aims to improve productivity, portability,
interoperability, and quality of software [41]. MDA also promotes the sepa-
ration of technology and business requirements [41], and as stated by Ma et
al. (2009) is complementary to a Service-oriented Architecture (SOA) ap-
proach [41]. MDA achieves this separation of business requirements from its
implementation technology in the form of a PIM [64]. Technology changes
do not affect the PIM, and the impervious nature of the PIM toward change
extends the Return on Investment (ROI) of modelled requirements [6]. MDA
thus facilitates the generation of independent components capable of outliv-
ing one another through change [41].
URDAD subscribes to a service-oriented approach to requirement solici-
tation [68]. It integrates a service-oriented approach with MDA [68]. In the
context of MDA URDAD is used to generate a PIM [70]. URDAD specifies
service contracts across levels of granularity [68]. Service contracts specify
non-functional requirements in terms of quality requirements and functional
requirements in terms of preconditions and postconditions [68]. Services at
13
15. a higher level of granularity can consist of other services, thus forming a
functional composition [68].
Previous attempts at service-oriented design methodologies have em-
ployed Business Process Model and Notation (BPMN) in order to model
processes [49, 41], and in addition have been technology specific [71]. Al-
though BPMN is reasonably capable of business process specification across
levels of granularity, its constrained semantics limits BPMN to the sufficient
design of technology-neutral business processes amenable to Model Driven
Development (MDD) [70]. BPMN does not support robust service contract
specification or data structure specification [70] and does not require a design
approach to be service-oriented [25].
The benefits of adopting URDAD include:
• increased productivity resulting from a systematic approach and the
ability to disregard non-functional requirements,
• an established standard of output from the analysis and design process,
produced with improved quality and consistency, and
• the potential of the requirements produced to retain relevance that
transcends the implementation technology [70].
As previously mentioned, URDAD PIMs have been visualised using UML
due to wide industry adoption and the extensive tool support that the lan-
guage enjoys [68]. UML supports many of the elements required by UR-
DAD including technology-neutral business process design [70], service con-
tract specification (using compound activities in conjunction with the Object
Constraint Language (OCL)) and data structure specification [70].
UML is sufficient for depicting relationships as well as, to a degree, stake-
holders [68]. UML does not provide support in terms of linkages between
stakeholders [68]. In addition, the UML specification does not specify any
standard notation for rendering constraints. As stated earlier, UML repre-
sentations may also be complex due to the large number of entities contained
within the language [71]. UML does not provide a notation for specifying
services conveniently and is unable to represent dependencies between ser-
vices, which significantly impedes its ability to populate URDAD PIMs [70].
In general UML is not that accessible to business stakeholders and is
difficult to understand and work with [76]. Visual representations and views
of UML models are provided in order to overcome the usability issues [76].
There is no clear indication of how the large number of diagrams (13 different
types in UML 2.0 [76]) are related to one another [76].
A UML profile (such as the UML profile for Enterprise Distributed Ob-
ject Computing (EDOC) [76]) restricts the number of diagrams and UML
elements [71] to a small but sufficient subset of UML and provides struc-
ture to a valid UML model. A UML profile is also capable of introducing
14
16. concepts required by URDAD [68]. Constraints can enforce and restrict a
model structure to the extent that it is capable of representing a UML model
as a valid URDAD PIM [71]. An URDAD UML profile however, requires
an excessive number of constraints in order to structurally comply with an
URDAD PIM [68].
The output of the URDAD methodology is a model complying with the
URDAD meta model [68]. A meta model logically defines the modelling ele-
ments used within a modelling notation [9]. A meta model is often referred
to as an abstract syntax [31]. It specifies the semantics and structure with
which a model must comply in order to be valid. An abstract syntax does
not however prescribe a method of concrete model construction.
A Domain-Specific Language (DSL) is a language designed
to be useful for a specific set of tasks [31]
Solms et al. (2011) have defined the URDAD DSL for the domain of
technology-neutral service-oriented requirements modelling [68]. The UR-
DAD DSL facilitates technology-neutral, service-oriented requirements mod-
elling and enhances the ability of practitioners, using the URDAD method-
ology, to document requirements in models [68]. The URDAD DSL enforces
a valid model structure by limiting constructs to those congruent with the
URDAD meta model [68]. This renders many constraints required by the
URDAD UML profile superfluous and provides a more conducive environ-
ment for tool-supported model validation [68]. In addition to enforcing a
valid model structure, the URDAD DSL is simpler than UML and provides
better support for depicting URDAD concepts than UML [68] as it is specif-
ically designed for this purpose.
A DSL’s structure is captured in its abstract syntax [31]. The URDAD
DSL’s abstract syntax is described in terms of Ecore, the Eclipse Modelling
Framework’s (EMF)’s implementation of the OMG’s Essential Meta Object
Facility (EMOF) [68]. EMOF is a smaller subset of the OMG’s Meta Object
Facility (MOF) standard for defining meta models and provides a language
for defining the abstract syntax of modelling languages [74] such as that
of the URDAD DSL. MDA relies on EMOF/MOF for its modelling aspect
[6] and because the URDAD DSL is described in an EMOF/MOF based
implementation, the URDAD DSL is capable of populating an MDA PIM.
In order for an abstract syntax of a DSL to be represented for use by
humans, one or more concrete syntaxes must be developed [31]. Models
constructed from a concrete syntax are referred to as instance models [31].
A concrete textual syntax for URDAD is proposed by Solms et al. (2011)
which enables practitioners to specify requirements from an URDAD PIM
[68]. The textual syntax is regarded as too technical for many industry
practitioners [68]. In addition, a textual syntax has other detracting features
when compared to a graphical representation.
15
17. Text is extremely constrained when compared to graphical representa-
tions [54]. Although the linear character of text is restricting, it aids in
conveying meaning to the reader when the secondary notation is dysfunc-
tional [54]. At the other extreme of freedom a graphical representation is
more susceptible to conveying an incorrect meaning and confusing the con-
sumer [54].
The definition of a usable concrete graphical syntax has been identified
as a critical success factor for the URDAD methodology [68]. A concrete
graphical syntax safeguards the validity of the model by limiting constructs
to its ontology set [73]. The restrictive nature of such a syntax also ensures
that it is easier to learn [73] by prohibiting invalid relationships and ensuring
that construct definitions are complete and valid. Tooling capable of sup-
porting the concrete syntax aids in safeguarding the population of a valid
model. This attribute contributes to the critical success factor of usability
[68]. This project defines a concrete graphical syntax for a subset of elements
in the URDAD meta model. In addition, tooling capable of supporting the
concrete graphical syntax is developed.
The graphical syntax is used in generating diagrams of URDAD PIM’s.
Different diagrams represent different views of the underlying model [31].
With large, complex models, such as that of URDAD, multiple diagrams, or
views, of the model are often required [31]. Each view focuses on represent-
ing one concern addressed by the model. This makes it easier to understand
and work with the model. The issue of synchronisation is raised when deal-
ing with multiple views, as changes to the diagram should be reflected in the
underlying model and vice versa. When multiple models are involved the
complexity increases in mapping different views to different models for syn-
chronisation. However, with URDAD there is only one underlying model
that is represented from various perspectives and thus synchronisation is
simplified.
As mentioned earlier, MDA is non-prescriptive as to the structure of
model specification. The IEEE/ISO 42010-2011 specification, however, pro-
vides us with a standard for documenting models [10] in the form of a set of
requirements that architecture descriptions must adhere to. The IEEE/ISO
42010-2011 specification is very abstract and does not prescribe a method
of producing architectural descriptions [10]. Nor does it prescribe any mod-
elling methods or notations in order to produce architecture descriptions
[10].
The standard requires that an architecture description consist of one or
more views [10]. A view addresses one or more stakeholder concerns [10],
with each view complying with the specifications of a viewpoint [10]. A
viewpoint ensures that a view addresses stakeholder concerns by framing
them and establishing conventions by which the view is generated [10]. A
viewpoint frames one or more stakeholder concerns, and a concern can be
framed by more than one viewpoint [10]. The concept of a viewpoint is
16
18. already employed in the definition of a concrete textual syntax for the UR-
DAD DSL [68]. In particular, the URDAD DSL text syntax specifies data
structure, service contract and service viewpoints, with the latter containing
the process specification for a service realizing a service contract.
The concerns addressed in this project are the data structure specifica-
tion and service contract specification. This project defines the viewpoints
that are leveraged in order to produce views capable of addressing these
stakeholder concerns.
1.3 Problem Definition
The development of a concrete textual syntax for the URDAD DSL enabled
practitioners to leverage off the advantages of using models in requirement
specification. The URDAD DSL, through its ability to support service-
oriented, contracts-based requirement specification, provides a simpler way
than the use of UML to populate models. As stated earlier, the textual
syntax is deemed too technical for practitioners [68].
A graphical notation can be developed for a DSL, and can then be
mapped onto its abstract syntax in order to produce a concrete graphi-
cal syntax. A concrete graphical syntax can provide a visual programming
interface [73] which greatly enhances the usability of a DSL. It can signif-
icantly reduce cognitive load [47] by taking advantage of the benefits of
convey information through visual representations.
The definition of a concrete graphical syntax for the URDAD DSL is
required in order for it to be rendered diagrammaticality. The URDAD
methodology envisages requirements specialists, from various responsibility
domains, contributing to a single requirements model [68]. Subsets of the
URDAD DSL identified for graphical representation, that are in alignment
with the concrete textual syntax are the service contract view and data
structure view [68]. The full semantic coverage of the elements of the UR-
DAD DSL that each view consists of is required in order to maintain the
integrity of the model. The identification of suitable graphical notation qual-
ity requirements is paramount in order to assess its capability to effectively
convey information.
The application of the graphical syntax will be significantly simplified
with the support of tooling capable of populating an URDAD PIM. This will
allow the implementation of the concrete graphical syntax while preserving
the integrity of the URDAD PIM through the application of bi-directional
binding to the model and any representations (from various perspectives)
of the model. The complexity of using the URDAD DSL for requirement
specification is significantly reduced by defining a concrete graphical syntax
as well as developing tooling capable of implementing the syntax.
17
19. 1.4 Purpose of the Study
In the first place this study aims to generate graphical representations of
an MDA PIM constructed using the URDAD DSL. In the context of the
IEEE/ISO 42010-2011 specification the model is represented from two per-
spectives that address specific stakeholder concerns [10]. The focus of this
project is the representation of a single URDAD PIM from various per-
spectives in the form of views. The perspectives identified for URDAD are
the data structure viewpoint, the service contract viewpoint and the service
viewpoint that contains the process specification. This study focuses on the
data structure and service contract viewpoints.
The generation of a concrete graphical syntax that corresponds to the
URDAD meta model is required for each view. Secondly, this project aims
at full semantic coverage of the elements in the URDAD meta model that are
required to represent the respective views. This will allow for the preserva-
tion of the model’s integrity when it is altered diagrammatically. The third
aim of the project is to identify criteria for the evaluation of the effective-
ness of the defined graphical notation proposed for these views. In the fourth
place the study aims to develop corresponding tooling, which implements
the concrete graphical syntax to support practitioners in the application of
the URDAD DSL. In order to demonstrate the graphical notation as well as
the tooling, the concrete graphical syntax is applied in visually representing
a non-trivial example of an URDAD PIM.
1.5 Significance of Study
This study will contribute to the field of service-oriented design, and more
particularly to the application of the theory of diagrammatic languages to
service-oriented design. The outcome of this study covers the URDAD DSL
but could be re-purposed on a much wider scale, i.e. a graphical syntax
rooted in well researched quality requirements could be reused in other
graphical representations of Ecore constructed meta models. Furthermore,
adhering to standards compliant with MDA allows the resultant model to
be used in the Eclipse Graphical Modelling Project (GMP) tool suite.
This project should significantly lower the barrier to entering into the
MDA space by enhancing the URDAD DSL’s usability. It is envisioned
that a usable graphical syntax will facilitate the adoption of URDAD. An
intuitive graphical notation should enable a larger audience to work with
the URDAD methodology in requirements modelling.
A graphical syntax prevents the practitioner from straying from valid
model constructs, enforces the integrity of the graphical representation. A
lack of tooling capable of providing guidance for this syntax is another factor
hindering the adoption of URDAD in commercial applications. The tooling
18
20. developed in this project aims to make it less complex to adopt the method-
ology by enabling domain specialists to more easily construct valid URDAD
PIMs which can then further be employed for model validation, code and
test generation and documentation generation. Generating the visual repre-
sentations based on a common meta model that enjoys widespread support
provides us with a wide range of applications. In this instance the URDAD
DSL conforms to the EMF supported Ecore meta model.
1.6 Scope and Limitations
The scope of this project pertains to the generation of two IEEE/ISO 42010-
2011 compliant views of an MDA PIM described using the URDAD DSL.
The IEEE/ISO 42010-2011 specification provides us with the concept of
models that describe the architecture of a system and views of models that
address various stakeholder concerns [10]. MDA proposes a way to harness
models in systems development [64, 25]. The URDAD methodology provides
us with a practical means of constructing an MDA PIM [70] that describes
the functional requirements of a system separately from the non-functional
requirements [68]. The two concerns identified for the generation of views
are the service contract specification and the data structure specification
[68]. For each of these concerns a corresponding view is generated with a
corresponding concrete graphical syntax defined.
Congruent to the IEEE/ISO 42010-2011 standard, the first of the two
graphical representations is the service contract view. It governs the
requirements a service needs to meet in order to sufficiently provide a par-
ticular service. These include the preconditions and postconditions of the
service [68]. The second is the data structure view. It defines the rela-
tionships between data structure objects and their composition [70] within
a responsibility domain, as well as the composition of the input and output
required of a service so that they conform to the service’s service contract
[68].
Each view will require its own graphical notation which will be mapped
onto the existing DSL constructs and evaluated against quality requirements
for graphical notation design. Evaluations of requirements engineering no-
tations are often conducted based on semantics [48]. This project focuses
on the design rationale of the graphical notation, since the URDAD DSL is
concerned with the semantic coverage required to produce a complete and
valid model that adheres to the URDAD meta model.
The DSL’s abstract syntax is specified in Ecore. We will be using the
Graphical Modelling Framework (GMF) to generate the diagrammatic syn-
tax for each view, as well as the corresponding tooling to support the de-
velopment of a concrete graphical syntax. The project does not include the
model-to-model transformations required to generate other models from an
19
21. URDAD PIM and will focus on the visualisation of an already constructed
MDA PIM described using the URDAD DSL. Further research can be done
to promote the universality of the URDAD analysis and design methodology.
The main focus of this research project is the practitioner. The re-
duced complexity and increased formality of the URDAD methodology are
expected to enhance and expedite their capabilities in requirements specifi-
cation.
1.7 Method
1.7.1 Quality Requirements for the Concrete Graphical Syn-
tax
This project aims to generate a concrete graphical syntax that will reduce
the complexity of working with the URDAD DSL in requirements modelling.
In notation design the most effort usually goes into the definition of the vi-
sual language constructs and what they represent [48]. The main focus is
often on ensuring the graphical notation is ontologically complete, which
results in the visual notation often being neglected [48]. Since this project
aims to reduce complexity, focus on the graphical notation is paramount.
This endeavour places certain quality requirements on the development of
a graphical syntax, quality requirements capable of providing guidance in
defining a simple, intuitive notation that reduces the complexity of em-
ploying the URDAD DSL in modelling an URDAD PIM. The criteria for
a reduction in complexity are intuitiveness, simplicity and practicality. If
they are met, ease of use in requirements solicitation using the URDAD
DSL should be increased. Quality requirements for the definition of graph-
ical notations are identified for this purpose. The industry-wide acceptance
of these quality requirements will contribute towards an intuitive graphical
syntax.
1.7.2 Approach and Implementation
The URDAD DSL is defined in terms of the Ecore model. Ecore is the
Eclipse Modelling Framework’s (EMF) implementation of EMOF [31] (a
smaller version of MOF). A common meta model has been identified as a
critical factor for the successful adoption of Model Driven Software Develop-
ment (MDSD) [31]. The Ecore model serves as this common meta model for
MDA tool suites, thus providing us with the ability to generate a concrete
graphical syntax and provide tool support for meta models conforming to
EMOF [68].
The Eclipse Modelling Project (EMP) encompasses smaller projects that
provides support for abstract syntax definition as well as concrete syntax de-
velopment [32]. A prerequisite for technologies used for practising MDA is
20
22. the implementation of OMG standards [32]. EMP largely supports OMG
standards and encourages the practice of MDA since many of the projects
conform to MDA specifications. The MOF (and EMOF) specification forms
the basis of the OMG standards for MDA in addition to transformation
standards such as Query/View/Transformation (QVT) [31]. The OMG stan-
dards do not, however, support the specification of concrete syntaxes.
The GMF project supports concrete graphical syntax development through
the definition of a graphical notation for a DSL. In GMF the graphical nota-
tion is defined independently of the DSL constructs. The graphical notation
is then mapped to the DSL in the mapping model. The meta model is an in-
tegral part of the implementation. It requires an Ecore model at the nucleus
of the GMF workflow for tool generation.
The modelling tools are envisioned as being realized through the pro-
duction of a plug-in for the Eclipse IDE, such as the GMF based diagram
editors. In the process of the development of such a tool-set there is an
implicit requirement to use the already developed Ecore domain model in
defining a concrete graphical syntax amenable to EMF and its projects. The
URDAD DSL forms the basis of this endeavour.
1.7.3 Assessment
The concrete graphical syntax defined for each view is evaluated against the
design goal of cognitive effectiveness. The speed, ease, and accuracy of the
graphical syntax’s application are assessed against principles that influence
each of these factors. There is the potential for conflict in assessing the
graphical syntax against the same criteria guiding its definition.
This possibility can be excluded because 1.) the principles are univer-
sally accepted (widely known) and 2.) there is a trade-off in the extent to
which each principle is applied (see chapter 3). Some of the principles are
competing and therefore it is impossible to fully adhere to all the principles
equally in defining a graphical notation.
The complexity of developing an URDAD PIM using the concrete graph-
ical syntax is assessed against the identified quality requirements. The prac-
ticality and usability of the graphical notation is evaluated through its ap-
plication to a non-trivial example, which is enabled through the tooling
developed in support of the graphical syntax.
1.8 Summary of Results and Achievements
A literature review of quality requirements for graphical notation design is
conducted. A concrete graphical syntax is developed for a subset of the UR-
DAD DSL, namely the service contract and data structure specifications.
These specifications correspond to viewpoints that govern the construction
of views, as defined by the IEEE/ISO 42010-2011 specification for describing
21
23. software architecture. It is argued that the IEEE/ISO 42010-2011 specifi-
cation applies to application as well as architecture design and accordingly
compliance to the standard is assessed.
The data structure and service contract viewpoints enable the generation
of IEEE/ISO 42010-2011 compliant views of an URDAD PIM. The views
are represented across layers of granularity and within various responsibility
domains. The generated views were then validated for completeness and
correctness by comparing them to the concrete textual syntax as well as the
concrete XML syntax. The graphical syntax developed for these views is
assessed against an extensive set of quality requirements that were identified
to guide and critically evaluate the intuitiveness of the notation.
GMF was used to develop modelling tools that map the graphical di-
agrams onto URDAD DSL models and vice versa. The tools implement
the graphical syntax and demonstrates that it can sufficiently populate an
URDAD PIM. These tools aim to making the language more accessible for
practitioners.
The visual representation of an URDAD PIM exposed certain issues
that need to be addressed in the URDAD meta model. The inheritance
of a quality constraint from an expression based constraint has side effects
and should not be allowed, and the named element reference that allows all
elements to have a reference to any other in the DSL should be prevented.
The tooling has also met with limitations, such as not being capable of
dynamically altering the notation of a figure based on model values.
The modelling tools were tested using a non-trivial example of an UR-
DAD PIM which also demonstrated the consistency and ontological com-
pleteness of the graphical syntax. This study contributes to the field of
service-oriented design, and more particularly to the application of the the-
ory of diagrammatic languages to service-oriented design.
22
24. Chapter 2
Related Work
2.1 Formal, Informal and Semi-formal Methods
Research conducted by Zhivich and Cunningham (2009) shows that the cost
of addressing software issues, including re-installing infected systems where
vulnerabilities were exploited, amounts to $60 billion annually (in 2009) in
the United States [78]. Apart from the cost implications of errors, these
errors could prove fatal when human life relies on software systems [46].
The software engineering discipline emerged in response to technical and
economical challenges [46]. Software engineering attempts to enable the con-
struction of reliable software amid their ever increasing complexity and scale
[20]. The earlier shortcomings in a software system are detected, the greater
the financial benefit due to the reduction in the cost impact in subsequent
phases of software development [61, 29].
Formal methods specify and verify systems using the mathematically
based languages, tools and techniques that support their construction [20].
The transfer of formal methods from research to practice has been slow
for software [21]. The wide-spread adoption of more formal methods in
software development is prevented by the model construction problem [21].
The construction of models from implementations is challenging due to the
semantic gap between the languages used in implementations and those re-
quired by verification tools [58]. General-purpose programming languages
allow developers to produce artefacts far removed from the requirements
of model verification tools [58]. Model verification tools mostly accept in-
put described in language specifications designed for simplicity [21]. The
validation of models thus requires the error-prone and time-consuming [21]
transformation of the implementation to an abstraction that contains its
salient properties, specified in the input language accepted by the verifi-
cation tool [58]. Formal methods assist in the provision of unambiguous
requirements and design that is reliable and that can be verified [71].
MDE falls within the class of semi-formal methods [69]. Semi-formal
23
25. approaches provide some structure to support a certain level of model vali-
dation and transformation [71]. Semi-formal approaches are not as complex
as formal approaches, with the result that some of the certainty that formal
approaches can provide is sacrificed.
2.2 Model Driven Engineering (MDE)
MDE promises to reduce the costs involved in software development [31]
through reducing the effort expended in gathering requirements for the con-
struction of a domain model and automating software construction. MDE
provides us with a manner of practising software development, driven through
domain models [45]. Domain models are capable of outliving the infrastruc-
ture they are implemented in as they are platform-independent and can be
reused and implemented in different technologies [66]. As domain models are
technology neutral, they allow us to conform to the IEEE/ISO 42010-2011
standard for software specification.
Staab et al. (2010) surveyed MDE with ontology technologies and assert
that for the sufficient specification of formal semantics that conform to a
meta model, close alignment to the meta model specification is required
[74]. A modelling language is defined as consisting of an abstract syntax
with one or more concrete syntaxes and corresponding semantics [74]. In
this project our meta model is the URDAD DSL which is closely aligned
to its meta model specification (described using EMOF) [68]. Modelling
tools are capable of supporting model validation [74] which is one of the
capabilities of the tooling developed in this project.
2.3 Model Driven Development (MDD) and Model
Driven Architecture (MDA)
Concrete implementations of MDE such as MDD has not been widely adopted
and is mostly utilised in the instances where problems are safety critical and
reliability is vital [71]. Reasons listed are:
• the lack of a clear definition of the requirements for specifying an
MDA1 PIM,
• a lack of standards to define the implementation architecture and the
accompanying technologies required to map implementations, and
• a lack of well-defined, practical analysis and design methodologies that
specify the artefacts to be included in the PIM [71].
1
the OMG’s version of MDD
24
26. In MDA, a Platform-Specific Model (PSM) represents non-functional re-
quirements [25]. A PIM is mapped to a PSM of the different implementation
architectures and technologies according to defined model transformations
[70]. A PSM includes sufficient implementation details to convert the model
to a particular source code implementation [64]. This is referred to as MDD.
MDA provides the environment where a PIM is transformed into a PSM [64].
Both formal and agile methods have influenced MDD [71]. Formal meth-
ods strive to enable the verification of software specifications and develop-
ment and to prove their correctness and reliability [20]. MDD aims to cap-
ture and maintain business processes by an abstraction depicted in models
[62]. MDD’s essential departure point is that software development focuses
on constructing models rather than programs which are deemed as a technol-
ogy specific side effect [62]. MDD is capable of simplifying the development
of software from volatile business processes [70]. The constant pressure of
change and the adaptation of business to the environment it operates in, re-
quire that change be handled effectively. In addition, working with models
provides us with certain benefits which are listed in table 2.1.
Table 2.1: Advantages of using models in software engineering
Concept Description
Direct representation A solution can be expressed directly in terms
of the problem domain [19]
Comprehension An abstracted model is easier to comprehend
than implementation code [19]
Documentation The model may prescribe how to build the
system, or describe how the system was built
[19]
Validation A model can be validated against design cri-
teria to ensure that the system can be built
[19]
Simulation A model of a system can be used to simulate
different scenarios and find the best solution
before the system is built [19]
Traceability A model can refer to other models or code.
Hence, information or changes in one model
can be traced to other models [19]
Automation Implementation code may be partly or com-
pletely generated from models. Hence, it may
speed up development time and reduce the
number of errors [19]
25
27. MDA is the OMGs version of MDD [70]. The most important benefit
of MDA is the ability of the PIM to survive implementation technology
and infrastructural change [70]. These PIMs can then be mapped onto
technology implementations as required [71].
MDA complying models can be modelled using UML [71]. In addition,
MDA is capable of meta language specification via the Meta-Object Facil-
ity (MOF) and supports constraint specification through OCL [71]. Model
querying and transformation are supported via the Query-View Transfor-
mations (QVT) specification [71].
Fatwanto and Boughton (2008) present a method of composing Archi-
tectural Descriptions suitable for MDD that comply with the IEEE/ISO
42010-2011 specification [10, 26]. A distinction is made between a logical
and an architectural viewpoint where the logical view describes the func-
tional features and the architectural view the platform [10]. They depict
these models using the Executable Translatable UML (xtUML) Class Di-
agrams and further demonstrate the capabilities of mapping languages to
their views [26].
In research by Fink et al. (2004) the generation of PSMs from PIMs is
explored [27]. An MDD approach is taken to develop access control policies
for distributed systems [27]. OCL is employed to represent constraints in
the PIM [27]. Meta models are constructed based on the MOF specification,
similarly to the URDAD DSL. Meta models are visually represented [27] yet
there is no graphical syntax definition and accordingly no tool support.
Other emerging disciplines have benefited from the use of MDA. Accord-
ing to Leist and Zellner (2006) the development of enterprise architecture
descriptions is challenging despite the many existing approaches [40]. The
broad scope and lack of structure developers are faced with are the most ap-
parent issues [40]. MDA provides enterprise architecture with an approach
that overcomes many of the obstacles faced, such as being capable of gener-
ating a specification document, based on a meta model, with roles defined
through prescribed techniques [40].
2.4 Service-Oriented Design Methodologies
An MDA approach aims to specify requirements separately from the tech-
nology used to implement the functionality [41]. A service-oriented approach
is capable of separating the business process from its implementation tech-
nology [41]. Accordingly, a service-oriented approach and MDA are comple-
mentary. There are, however, a very few methodologies that, like URDAD,
aim to integrate the MDA and service-oriented approaches in requirement
specification.
26
28. 2.5 Use-Case Responsibility Driven Analysis and
Design (URDAD) and UML
URDAD is a service-oriented analysis and design methodology [71]. UR-
DAD is technology neutral and requires analysis and design across levels of
granularity [71]. URDAD provides a means to realising the value of MDA
by bolstering its standards and providing a well-defined analysis and de-
sign methodology [71]. URDAD integrates with a model-driven approach
by providing a simple, repeatable manner in which to generate MDA PIMs
[71].
URDAD has been employed in conjunction with UML (see section 2.6)
[70], which is not ideal due to the wide variation allowed by UML in model
structure. In their research Wieringa et al. (2004) and Schippers et al.
(2005) attempt to overcome this obstacle by generating a UML profile in
order to mitigate the wide variety of the language used to depict domain
models [60, 76]. Wieringa et al. (2004) mapped their UML profile to the
Archimate meta model [76] that provides visualisation through tool support
and a visual notation to the model. Similarly a corresponding concrete
graphical syntax is defined yet it diverges from the project in this paper in
that the syntax is not based on an MDA supported standard but on UML.
A general-purpose language such as UML does not constrain the PIM
and hence needs to be used with discipline in order to produce valid models.
UML models can be constrained with the use of OCL [68]. An excessive
number of constraints would, however, be required [68]. OCL is also not
suited to constraining a model in a service-oriented context, because it can-
not sufficiently specify a constraint on state that is not accessible via an
object graph [68].
The characteristics of URDAD are stepwise refinement of requirements
and design, with well-defined inputs and outputs per step, service contract
generation in levels of granularity, and an explicit approach to fixing the lev-
els of granularity whilst still remaining technology neutral [70]. The stan-
dardisation in design method eases the mapping of the PIM to the PSM
upon implementation.
Obstacles encountered that relate to the practical application of the UR-
DAD methodology include:
• a reluctance to use UML for documenting business processes,
• difficulty in discerning the boundary between the business process and
the technology employed, and
• a lack of understanding of the methodology that leads to varying and
low-quality results in requirement specification [70].
27
29. 2.6 Domain-Specific Languages (DSL)
An URDAD PIM can be captured in a generic modelling language like UML
[70]. URDAD is not, however, restricted to any particular modelling lan-
guage [70]. A modelling language only requires sufficient semantics capable
of documenting a PIM [70]. In order for a modelling language to support
URDAD it would need to be able to support technology neutral business
process, data structure and service contract modelling. It should also have
the capability to model layers of granularity of services and the ability to
indicate relationships between data structure objects and their composition
[70].
DSLs have met with limited success because:
• they are more expensive to create and maintain due to their limited
user community,
• consequently there is a lack of tooling and support when compared
with Generic Programming Languages (GPL), and
• the sheer size of the General Purpose Language (GPL) user base over-
comes the disadvantages of implementations, ensuring they are robust
and reliable [12].
A DSL enforces the structure of a model ensuring it produces a valid
model [31]. The DSL constrains the model constructs to only those avail-
able in the language capable of producing a valid model [68]. This aspect
makes working with DSLs simpler as it alleviates the burden of validation
for the practitioner, and with the appropriate tool support, facilitates the
construction of models by requirements engineers [68].
Skene and Emmerich (2006) have proposed that meta models should play
a much larger part in specifying requirements, arguing that meta models and
specifications should be combined in order to ensure integrity and eliminate
any ambiguity [65]. The paper proposes the use of a DSL integrated with
requirement specification [65]. Their proposed DSL is not conducive to spec-
ification in a service-oriented approach, yet it does have a concrete textual
syntax defined [65].
Zhaol et al. (2008) propose their own modelling language based on
principles similar to those of this project [77]. They leverage off the MOF
specification in defining their DSL [68, 77]. Their project also recognises the
principles of MDA. Like the URDAD DSL the XKL language is defined based
on the structure of EMOF, and they employ OCL to constrain models [77].
The abstract syntax of the XKL language is defined along with a concrete
textual syntax [77]. Their DSL does not cater for a service-oriented approach
nor is an attempt made to define a concrete graphical syntax [77].
Muller et al. (2008) propose a specification for generating concrete syn-
taxes that rely on meta models [51]. They leverage off meta models in order
28
30. to produce tools capable of bi-directional model transformation between a
concrete and an abstract syntax [51]. Similar to the research in this paper
and aligning with MDA, their project leverages a meta model to produce a
concrete syntax [51]. However, they propose a concrete textual syntax [51]
as opposed to a concrete graphical syntax and they do not integrate service-
oriented design with an MDA approach [51]. As a corresponding concrete
textual syntax has already been developed for the URDAD DSL [68] we will
leverage off the existing meta model in order to define a concrete graphical
syntax.
Pons and Garcia (2008) propose an approach for validating generic mod-
elling language semantics. Therefore they do not leverage off a DSL specif-
ically constructed for their domain of discourse [55]. The method employs
UML as a modelling language and OCL in order to constrain and vali-
date models [55]. Similarly, Borges and Mota (2007) have integrated the
UML meta model with more formal methods by mapping it to the OhCir-
cus language [18] in an attempt to reuse existing tools based on widely
adopted standards. However, both these projects lacks support for mod-
elling a service-oriented approach [71] due to their use of UML.
2.6.1 IEEE/ISO 42010-2011
There are many definitions for software architecture. The definition chosen
for the purpose of this paper is by Solms (2012) who asserts that software
architecture is
. . . the software infrastructure within which application com-
ponents providing user functionality can be specified, deployed
and executed [67].
The definition relies on the definition of an application component [67].
Ambroziewicz and ´Smialek (2010) defines an application component as
. . . software components which address functional requirements
of the software system [15].
The definition makes a distinction between application design and ar-
chitecture design [67]. Application design is defined as design addressing
functional requirements, whilst architecture design addresses non-functional
or quality requirements [67].
URDAD is an architecture-neutral design methodology that aligns with
the definition of architecture as consisting of both the application design as
the functional requirements in business process specification and the recog-
nition of the architecture design in non-functional or quality requirements
[70]. URDAD focuses on the design of functional requirements.
29
31. The IEEE/ISO 42010-2011 specification serves as a recommended prac-
tice for expressing the architecture of software-intensive systems [10]. It
facilitates the communication of architectures [10] and aims to address the
creation, analysis and sustainment of the architecture of software-intensive
systems. It focuses on the description of architectures and not on the con-
struction of their implementations. The IEEE/ISO 42010-2011 specification
is based on five core concepts and relationships that are in short: 1) every
system has architecture separate from the system, 2) architecture and the
description thereof are separated, 3) architectural standards, descriptions
and development processes are separated, 4) architectural descriptions can
be viewed from many angles, and 5) the view and the specification thereof
are separated as well. Maier and Rechtin (2000) clarify the separation be-
tween architecture and the system, stating that
. . . (a)n architectural description is a concrete artefact, but
an architecture is a concept of a system [42].
The IEEE/ISO 42010-2011 specification defines software architecture as
. . . fundamental concepts or properties of a system in its en-
vironment embodied in its elements, relationships, and in the
principles of its design and evolution [10].
The definition does not provide a definitive explanation of the fundamen-
tal concepts [67] of a system. The specification could apply equally to both
the application design (addressing functional requirements) and the archi-
tectural design (addressing non-functional requirements). The reasoning is
that in both application and architecture design the concept of populating a
model specified by views that comply with viewpoint specifications applies.
The specification also requires traceability of requirements back to design
decisions, which is again equally applicable to application and architectural
design.
Conceptual integrity is the binding principle of software, and software
architecture provides a defence against the decay of this integrity over time.
The IEEE/ISO 42010-20112 specification is an attempt at creating a com-
mon practice around the expression and communication of software-intensive
systems architectures in a structured manner [10].
The elements of Architectural Descriptions (AD) as defined by the IEEE/ISO
42010-2011 specification are: 1) stakeholders, 2) concerns, 3) architectural
views and 4) viewpoints. Stakeholders have an interest in a system. These
interests are expressed as concerns about the system’s architecture [10].
Functionality, performance, security and feasibility are concerns typically
encountered. Viewpoints frame concerns for meaningful descriptions of the
2
Compatible with other standards such as the ISO Reference Model-Open Distributed
Processing (RM-ODP)and architecture frameworks: C4ISR and DODAF [10].
30
32. Figure 2.1: The IEEE/ISO 42010-2011 conceptual model of an architecture
description
architecture. Views are representations of a set of elements within a sys-
tem and their associated relationships [10]. The concept of architectural
views has been embraced by modern software architecture. The IEEE/ISO
42010-2011 specification applies this concept and abstracts it further into
viewpoints [10] that serve as a convention for the construction of a view.
This practice provides us with reusable templates that assist in the stan-
dardisation of describing an architecture.
The IEEE/ISO 42010-2011 specification was designed to be method neu-
tral in its practice [10]. Therefore users are permitted to exploit any pre-
ferred method to construct architectural descriptions.
2.7 Other Service-Oriented Design Methodologies
A survey of service-oriented development methodologies conducted by Ramol-
lari et al. (2007) identified several methodologies of which many employ
UML and/or BPMN [57]. No reference is made to MDA integration nor to
a concrete syntax and corresponding tool support [57].
Karhunen (2005) presents a service-oriented software engineering (SOSE)
component framework [36]. It is similar to URDAD in its service-oriented
approach and integrates MDA as well [36]. This approach is, however, very
31
33. conceptual and does not provide a usable abstract syntax [36] such as that
of the URDAD DSL.
Moosavi et al. (2009) propose a method for service-oriented design sim-
ilar to URDAD [49]. The project focuses on design and employs UML as
well as BPMN but does not provide an abstract syntax or the accompanying
tooling capable of supporting the design methodology [49].
Ma et al. (2009) propose an MDA based platform for service-oriented
applications [41]. It is similar to the project in this paper in that this project
also integrates a service-oriented approach with a model-driven approach
[71]. The project progresses further in that it has tool support capable of
facilitating its implementation in a proposed platform. However, the project
diverges from this paper in using UML 2.0 in order to depict certain views
[41]. It also diverges in the views that it proposes to aid in design [41]. The
project employs OCL [41]. The project includes the development of their
own modelling tool support that leverages off existing graphical notations
[41]. The tool is capable of translating the models into executable code,
similar to research done by Edwards (2011) [25].
Quartel et al. 2004 propose a service-oriented design process with an
accompanying modelling language, Interaction System Design Language
(ISDL) [56], comparable to the URDAD DSL. The project recognises the
need for a generic service-oriented design paradigm independent of an im-
plementation technology [56]. It does not, however, integrate with MDA
and its accompanying EMOF standard, and in addition does to not provide
any tool support [56].
In research by Benguria et al. (2006) a model-driven approach integrated
with a service-oriented approach is proposed [75]. Similar views are proposed
in their PIM4SOA research project [75] and, although the nomenclature dif-
fers, the concepts are closely aligned to the workflow steps identified in UR-
DAD [68, 75]. These concepts are service, process, information and quality
of service [7]. The views generated to address the concerns defined by these
aspects are:
• the information view, representing the higher level context of the views
and forming the basis of the subsequent views,
• the service view, representing the functional technology independent
requirements,
• the process view, representing interactions among services, and
• the quality of service (QoS) view, representing the non-functional as-
pects of the services described [7].
The information aspect aligns with the proposed data structure view,
and the service view can be related to the proposed service contract view.
32
34. The PIM4SOA project has a defined meta model for a service-oriented ap-
proach as well as an abstract language expressed in the EMOF format [7].
The project similarly relies on EMF in order to provide tool support [7].
These aspects align the PIM4SOA project closely to this paper’s research
topic. The main divergence, apart from a different meta model employed
in each project, is that the PIM4SOA project employs a UML profile in
realising the visualisation of models. The PIM4SOA project also relies on a
single viewpoint against the two proposed in this project3.
Agrawal et al. 2003 [12] propose a framework for the development of
domain-specific graphical languages. The authors develop their own DSL -
MOLES with a graphical representation constructed through their Generic
Modelling Environment (GME) [12]. They employ OCL for defining con-
straints [12]. The project provides tool support for the development of DSLs
and consists of a modelling environment, meta modelling language, model
transformation engine as well as an execution engine for the model transfor-
mations [12]. The project employs the UML language in order to represent
models which lack support for conducting service-oriented analysis and de-
sign.
Delgado et al. (2010) propose a framework that, similar to URDAD,
implements service-oriented computing integrated with the MDA approach
[23]. The MINERVA framework is defined to support analysis and design
[23]. In terms of graphical representation of models the project diverges
from the project in this paper in that it employs BPMN and UML to model
business processes [23]. The project identifies the business process and the
service-oriented concerns and then goes on to define ontologies for each [23].
The project proposes tooling in order to provide automated transformation
between models [23].
G¨onczy (2007) propose the development of services independent of tech-
nology using the Service Component Architecture (SCA), but does not,
however, integrate it with an MDA approach [30]. SRML (a modelling
language for service-oriented systems [8]) is employed to describe services
in a technology-independent manner [30]. The project diverges from the
project in this paper in that it does not propose to define services using
a DSL based on MDA compliant standards and is not able to realise the
accompanying benefits. Like this paper G¨onczys project proposes tooling
developed in the Eclipse Modelling Framework (EMF) environment [30].
3
there are three viewpoints identified for URDAD in the data structure, service contract
and service viewpoints (which contains the process specification)
33
35. 2.8 Concrete Syntax Definition
2.8.1 Concrete Textual Syntax Generation
Staab et al. (2010) identify and discuss four constructs from Ecore as rele-
vant to defining an ontology in an MDE context, namely EClass, EAttribute,
EReference and EDataType [74]. A DSL for the URDAD methodology has
already been defined and includes these constructs aligned to the recom-
mendation by Staab et al. (2010) [74].
Heidenreich et al. (2009) propose a refined specification for deriving a
textual syntax from meta modelling languages automatically [35].They ar-
gue that graphical and textual syntaxes are complementary due to certain
attributes [35]. Graphical syntaxes are very capable of representing rela-
tionships as well as quantities [35]. Graphical representations also provide
the opportunity to zoom, allowing for a more comprehensible overview [35].
Textual syntaxes, however, constrain their consumption to a linear form and
ensure interpretation occurs sequentially [35]. A model expressed in a tex-
tual syntax is also more easily comparable to others through tool support
[35].
The URDAD DSL has an abstract syntax with a corresponding con-
crete textual syntax [68], and in this project a concrete graphical syntax is
defined for that abstract syntax. A concrete graphical syntax is suggested
to further simplify the requirement specification process using the URDAD
methodology.
2.8.2 Concrete Graphical Syntax Generation
Cranefield and Pan (2007) generate an ontology compliant with MDA for
use in transformation and analysis [22]. The project relies on the Resources
Description Framework (RDF) (a MOF based language similar to Ecore) for
depicting instance models [22]. The premise of the project is using existing
technologies, and in order to accomplish this the RDF standard was used.
RDF supports automated mapping of a MOF based meta model to the RDF
syntax [22], which serves as a generic DSL. Apart from the fact that this
approach is incapable of providing the associated benefits of modelling in
a DSL, it constrains the practitioner to RDF supported tooling only. The
graphical notation would have to coincide with a generic modelling language
(such as UML) which is incapable of effectively modelling a service-oriented
approach in analysis and design (as established in section 1.2).
2.9 Graphical Notation Design Principles
Notation is at the centre of concrete graphical syntax definition. A notation
provides identity to the representation and directly impacts the practical
34
36. nature of its usability. The software engineering field has employed visual
notation to depict software programs since the 1940s with Goldstine and
von Neumann’s program flowcharts [47]. The advances in the field of visual
representation culminated in the industry standard software engineering lan-
guage, UML, defined as
. . . a visual language for visualizing, specifying, constructing,
and documenting software intensive systems [47].
While UML is widely adopted, the graphical notation transgresses cer-
tain good design principles, as identified by Moody (2009) [47]. This influ-
ences the intuitiveness of visual representations produced using UML.
Moody (2009) has conducted research on well developed visualisation
notations, based on earlier work done by Tufte [47], and identifies 10 prin-
ciples capable of providing guidance in the development of notations. This
research project applies good design principles to graphical notation design
to ensure intuitiveness.
He et al. (2007) proposes a meta model for defining graphical notations
that aims to address the problems that exist in 1. defining a notation, 2.
defining the location of relationships and 3. mapping the notation onto an
abstract syntax [34]. The meta model comprises three parts, namely:
1. basic figures and layouts,
2. location relations, and
3. syntax bridges [34].
Their project employs the PKU Meta Model Tool(PKU MMT), imple-
mented in the Eclipse platform, and provides a graphical editor for defining
a concrete graphical syntax for a corresponding abstract syntax [34]. Like
this study it also generates the accompanying tooling capable of supporting
the defined graphical syntax [34], but it differs in using UML [34]. Conse-
quently it does not provide a mechanism for use with service-oriented design
methodologies. It does however provide us with the guiding framework for
defining a graphical notation used in this study.
2.10 Concrete Graphical Syntax Definition
Staab et al. (2010) define the Web Ontology Language (OWL)4 DSL [2].
The DSL employs Ecore as its meta-modelling language [74]. EMOF is
an MDA standard and serves as the meta model for Ecore [31], it is thus
the meta-meta model for the DSL. URDAD’s DSL is similarly based on
4
OWL is not a real acronym. The language started out as the Web Ontology Language
but the Working Group disliked the acronym WOL[2]
35
37. Ecore which aligns this project very closely with the research done by Staab
et al. (2010) [74]. They, however, employ UML as a concrete graphical
syntax [74]. Although the concrete syntax does not meet with the needs
of modelling requirements using a service-oriented approach, the framework
identified by Staab et al. (2010) runs parallel to the topic of research in this
paper [74]. The concrete syntax definition and tools capable of supporting
the syntax in this project are, however, divergent from those used in the
research done by Staab et al. (2010) [74].
Mum et al. (2010) investigate meta model architectures for language
specification [50]. They indicate that the OMG diagram execution standard
- UML Diagram Interchange (UML DI) - is not sufficient for defining diagram
presentations as it is not precise in defining the representation of a diagram
[50]. In motivating their architectural approach, they evaluate the OMG,
XMF, KM3, Kermeta, EMF and GMF approaches [50]. Their findings are
that there are benefits to the Kermeta as well as to the GMF architectural
approaches in that they are:
• clear,
• flexible, and
• more extensible [50].
2.11 Tooling in Support of Concrete Graphical Rep-
resentations for DSLs
Research in the field of service-oriented design methodologies, such as that
by Moosavi et al. (2009) has not produced any supporting tooling [49].
Akehurst and Patrascoiu (2004) researched OCL 2.0 and have provided
a means of applying the language to any object-oriented language such as
EMOF [13]. They provide a bridge for meta models to EMF, among others
[13]. Other tooling identified that is not able to sufficiently meet the tooling
requirements of this project includes the PIM4SOA project [7], the MIN-
ERVA framework of tools [23], G¨onczy’s proposed EMF based tooling [30]
and the PKU MetaModel Tool (PKU MMT) implemented in EMF proposed
by He et al. (2007) [34]. The incompatibility stems from a variety of fac-
tors, including an incompatible meta model and meta model based standard,
and the inability to sufficiently model requirements from a service-oriented
approach.
36
38. Chapter 3
Defining Quality
Requirements for Graphical
Notations
3.1 Quality Requirements of Graphical Notation
Design
Graphical notations are ingrained in the communication of information within
the software engineering discipline [47]. They play a critical role in commu-
nicating with practitioners such as users and customers. Visual represen-
tations are, however, just as vulnerable to the distortion of an information
message as other forms of communication [54]. Therefore quality require-
ments are needed to guide the definition of graphical notations.
A concrete graphical syntax, also known as a graphical notation1, is
widely employed in requirements engineering [48]. Text is more constrained
due to the one dimensional approach to conveying information inherent in
its linear character [54]. Information is believed to be conveyed more ef-
fectively to those less technically inclined in graphical than in text format
[47]. However, there are certain risks involved with representing informa-
tion graphically, as greater freedom increases the potential for miss-cuing
and confusion [54].
The benefits of visual representations include:
• more efficient information processing [47],
• concise communication of information [47],
• more precisely conveyed information [47],
1
also referred to as a visual notation, a diagram notation or visual language.
[48]
37
39. • that they are more likely to be remembered due to the picture superi-
ority effect,
• that diagrams can group related information, which reduces the need
to search for elements [39],
• that diagrams can use more dimensions to convey information (e.g.
location of symbols and their labels) [39], and
• that diagrams support a large number of perceptual inferences that
come natural to humans [39].
The design rationale of a visual notation justifies the symbols chosen to
perceptually represent the semantics of a visual language [47]. Graphical
symbols are the visual vocabulary of the semantic constructs they represent
[47]. Compositional rules form the visual grammar which together with
the visual vocabulary forms a concrete visual syntax [47]. The semantic
constructs we will represent are contained within the URDAD DSL.
A concrete graphical syntax requires the definition of graphical symbols
that are then mapped to the constructs they represent [47]. These symbols
can then be depicted (using the visual vocabulary) in a manner that conforms
to the compositional rules (visual grammar) to form a diagram [47].
Moody [47] states that in order to effectively define a graphical notation
a design goal should be clearly defined. Our aim is to allow practitioners to
easily work with the URDAD DSL. Our design goal is reduced complexity.
This is however vague and difficult to evaluate empirically. A more descrip-
tive definition of our design goal is Cognitive effectiveness, defined as the
speed, ease, and accuracy of processing of a representation by the human
mind [47]. Cognitive effectiveness ensures that a visual notation facili-
tates communication between practitioners, and supports their design and
problem solving ability. Moody (2009) asserts that a graphical syntax not
only contributes to aesthetics but to effectiveness as well, since form has a
profound influence on cognitive effectiveness in relation to content [47].
Absolutely paramount to graphical notation design is the comprehension
of how and why visual notations convey information. Understanding the
guiding principles allows us to improve on visual notations [47]. In order to
provide traceability in the graphical notation design process and justify the
final design we will provide a design rationale for design decisions.
3.2 Challenges in Graphical Notation Design
Ontological Analysis
Ontological analysis assesses the appropriateness of a modelling grammar
[28]. The semantic comparison of an ontology with its modelling gram-
mar serves to minimise the subjectivity of evaluating a notation [28]. The
38
40. Bunge-Wand-Weber (BWW) (see figure 3.1) ontology is widely used [47]
and provides us with an ontology capable of assessing the suitability of a
notation according to ontological fit [28].
ontology modelling grammar
(1)
(4)
(2)
(3)
(1) construct deficit
(2) construct redundancy
(3) construct overload
(4) construct excess
representation mapping
interpretation mapping
Figure 3.1: Ontological analysis
Ontological analysis involves the one-to-one mapping of the graphical
notation constructs to the modelling grammar [47] and can produce the
following anomalies:
• Construct deficit occurs if there is no construct in the notation that
corresponds to an ontological concept [28], in which case the notation
is ontologically incomplete [47].
• Construct overload occurs when a notational construct is capable
of representing multiple ontological concepts [28], so it becomes onto-
logically unclear [47].
• Construct redundancy is the inverse of construct overload and oc-
curs when multiple notation constructs are capable of representing an
ontological concept [28], in which case the notation is again ontologi-
cally unclear [47].
• Construct excess occurs when there is no mapping between a no-
tational construct and any ontological concept [28], in which case the
notation is ontologically unclear [47].
39
41. Communication of Visual Notations
Moody (2009) adapts the widely accepted theory of communication by Shan-
non and Weaver [63] to the domain of visual notation, stating that the en-
coding and decoding processes of communication need to be leveraged in
order to ensure that information is correctly conveyed [47]. The creation of a
diagram is regarded as the encoding for which the visual notation is used,
and the decoding is the interpretation of that diagram by the intended
audience [47]. In the domain of visual notation the encoding process refers
to the design of the graphical notation using graphical design variables, and
the decoding process refers to the interpretation of the notation influenced
by principles of graphical information processing [47].
3.3 Graphical Design Variables
In Semiology of Graphics, Bertin (1983) defines eight visual variables used
to define graphical information [17] (see figure 3.22). These variables can be
used to define the primary notation which indicates the formal meaning of
symbols and a secondary notation that informally emphasises or communi-
cates information [54], e.g. boldface text or a darker shade of colouring to
indicate importance.
VL]HYDOXH KXH RULHQWDWLRQWH[WXUH VKDSH SRVLWLRQ
Figure 3.2: The 8 variables (Semiology of Graphics)
Secondary notation is non-trivial and complements perceptually the in-
formation conveyed symbolically [54]. According to Shannon and Weaver’s
communication theory [63], visual noise is unintentional or random varia-
tion in visual variables that conflicts with or distorts the information con-
veyed [47]. The primary meaning falls within the scope of this project with
the influences of the secondary meaning considered where appropriate.
2
taken from Miller (2004) [44]
40
42. 3.4 Graphical Information Processing
A distinction is made between two phases when humans process graphi-
cal information. The first is perceptual processing, followed by cognitive
processing [47]. Perceptual processing is automatic and natural, making it
faster and less resource intensive as it is unconscious, whereas cognitive pro-
cessing involves understanding and analysing the information in a conscious
manner (this requires effort). Thus the effectiveness with which graphical
information is processed is largely determined by the exploitation of percep-
tual processing [47]. The stages in human graphical information processing
need to be considered in order to promote the optimal use of perceptual
processing.
The stages in human graphical information processing are identified as:
• perceptual discrimination, the play between visual variables that
allows one to discriminate between symbols,
• perceptual configuration, the interpretation and detection of the
patterns or structures in which symbols are organised,
• attention management, the conscious effort lent to the active pro-
cessing of elements,
• working memory, the limited capacity that is available at a spe-
cific point, and which influences the capability of active information
processing, and
• long-term memory, the integration of processing with prior knowl-
edge [38].
3.5 Principles for Cognitively Effective Visual No-
tation Design
In designing an effective visual notation certain factors need to be brought
into consideration, namely the recognisability of symbols, principles for con-
veying information through visual communication, secondary and primary
notation, and the possible redundancy of information that could lead to
misinformation [31]. The stages of human graphical information processing
are considered in identifying principles capable of guiding visual notation
design.
The use of filters and layers, layout, synchronisation and the depiction
and indication of relationships between graphs and sub-graphs, congruent
with the analysis of levels of granularity, require consideration in the devel-
opment of supporting tooling [31].
41
43. Figure 3.3 depicts principles for cognitively effective visual notation de-
sign. The 10 design principles outlined by Moody [47] are listed and dis-
cussed briefly.
Cognitive
Integration
Visual
Expressiveness
Dual Coding
Graphic
Economy
Cognitive Fit
Interactions
among
Principles
Interactions
among
Principles
Semiotic
Clarity
Perceptual
Discrimina
bility
Semantic
Transpare
ncy
Complexity
Manageme
nt
Cognitive
Integration
Visual
Expressive
ness
Dual
Coding
Graphic
Economy
Cognitive
Fit
Figure 3.3: Principles for cognitively effective visual notation design
Principles for Designing Cognitively Effective Visual Nota-
tions
1. Principle of semiotic clarity
2. Principle of perceptual discriminability
3. Principle of semantic transparency
4. Principle of complexity management
5. Principle of cognitive integration
6. Principle of visual expressiveness
7. Principle of dual coding
8. Principle of graphic economy
42
44. 9. Principle of cognitive fit
10. Interactions among principles
3.5.1 Principle of Semiotic Clarity
The principle of semiotic clarity extends ontological analysis to apply to a
visual syntax [47]. In order to adhere to this principle, a 1:1 correspondence
between semantic constructs and graphical symbols is required [47]. Should
a 1:1 correspondence not be maintained, the semiotic inconsistencies of sym-
bol redundancy, symbol overload, symbol excess and symbol deficit could
occur [47].
3.5.2 Principle of Perceptual Discriminability
In order to leverage off perceptual processing, clearly distinguishable sym-
bols are required to minimise cognitive load [47]. Visual distance, shape,
redundant coding, perceptual pop-out and textual differentiation contribute
to perceptual discriminability [47].
3.5.3 Principle of Semantic Transparency
The appearance of visual representations should suggest their meaning [47]
through relying on mnemonics [54].
Semantically Immediate
• Infer correct meaning from
appearance alone
Semantically Opaque
• Arbitrary learned relationship
Semantically Perverse
• Meaning misinterpreted
Semantic Translucency
Figure 3.4: A semantic transparency continuum
Often referred to as ’intuitiveness’, semantic transparency reduces cog-
nitive load by relying on the previously-learned or easily and accurately
perceived associations between objects and functions [54]. A figure is said
to be semantically immediate if its meaning can be inferred correctly
from its appearance alone [47]. At the other end of the scale a figure is said
to be semantically perverse if the meaning of the figure is misinterpreted
[47]. Should ambiguity exist toward the meaning of a figure it is said to
43
45. be semantically opaque. With semantically opaque figures meaning is
attached to the figure by a learned connotation as there is no reliance on
pre-existing connotation. The degree to which a figure meets the require-
ments on the continuum is referred to as its semantic translucency. Semantic
transparency is applied principally in the use of icons and relationships [47].
3.5.4 Principle of Complexity Management
Explicit mechanisms should be employed to effectively manage complexity
[47]. In order to prevent cognitive overload and accommodate perceptual
limits, modularisation as well as hierarchical structuring is employed. The
separation between the service contract view and data structure view can
be deemed modularisation of the URDAD PIM. Responsibility domains in-
troduce a hierarchical structure that requires representation in each of the
views.
3.5.5 Principle of Cognitive Integration
Explicit mechanisms should be employed to support information integration
from various diagrams [47]. Closely related to complexity management, this
principle applies when multiple diagrams are used to represent concepts.
It applies where mental integration of information needs to occur between
diagrams. An example would be the service contract element that requires
representation in both the service contract and data structure view. Con-
ceptual integration and perceptual integration are employed to assist.
3.5.6 Principle of Visual Expressiveness
The eight visual variables3 are capable of promoting visual expressiveness
[47]. Their full range and capacities are exploited to this end.
3.5.7 Principle of Dual Coding
When conveying information effectively the use of text and graphics is not
mutually exclusive. The dual coding theory [52, 53] states that using both
together is more effective than each on its own. This principle promotes the
use of text to complement graphics [47], but substituting graphics with text
is discouraged. The use of annotations and hybrid graphics in a diagram
are examples of this principle.
3
Semiological variables: Planar: Horizontal and vertical position and Retinal: orien-
tation, shape, texture, brightness, size, and colour. [17]
44
46. 3.5.8 Principle of Graphic Economy
Graphical symbols should not be so numerous as to be cognitively unman-
ageable [47]. Ways in which graphical complexity can be managed are
through a reduction (partitioning) in semantic complexity, by introducing
symbol deficit4, and increasing visual expressiveness. These options compete
with many of the principles that are employed to increase the practitioner’s
ability to discriminate between graphical representations. This points to the
interaction between principles and emphasises the balance that needs to be
maintained when applying these principles due to their ability to influence
each other’s effectiveness.
3.5.9 Principle of Cognitive Fit
Cognitive fit refers to the suitability of the representation of information, in
terms of either the task at hand or the intended audience [47]. Cognitive fit
can be increased through different visual dialects that depend on the skills
levels of practitioners [47]. Taking into account the representational medium
such as the task, as well as the salient characteristics that influence its
interpretation, ensures that the cognitive fit is increased [47]. This principle
suggests the use of different visual notations for each respective task or
audience in order to promote a better cognitive fit [47].
3.5.10 Interactions among Principles
The 10 principles (see figure 3.3) are not necessarily complementary and
some do conflict. Principles interact and taking this into account is paramount
in making trade-offs in situations where principles compete [47]. Principles
can also complement each other and can be wielded to enhance each other’s
effectiveness.
3.6 Defining Notations for Graphical Modelling
Languages
He et al. (2007) propose a meta model for defining graphical notations,
namely the Notation Definition Meta model (NDM) [34]. The meta model
is comprised of three parts:
1. Defining Basic Figures and Layouts
2. Defining Location Relations
3. Specifying Syntax Bridges
4
see semiotic clarity in section 3.5.1
45
47. 3.6.1 Basic Figures and Layouts
Figure designs need to be concise as this makes them easy to implement in
tools [34]. Figures are composed of basic figures which combine the rectan-
gle, rounded rectangle, diamond, triangle, polygon, ellipse, circle, straight
line, polyline, arc, text object and image [34]. Layout is paramount as ex-
plained by Gronback (2009):
Layout can go a long way toward making diagrams more read-
able and can even convey semantic information [31].
Layout aids in depicting parent and child relationships and includes flow
layout, border layout, decoration layout, role name layout, vector-graph
layout and extendible layout [34]. An ontological fit is required to allow the
sufficient mapping of notational constructs to the modelling language [47].
3.6.2 Location Relations
Location relations communicate additional information regarding the dif-
ferent structural relationships between meta-classes [34]. These are classi-
fied into nested type, connected type, port type, node-attached type and
end-attached type [34](see figure 3.5). This aspect relates to the secondary
notation [54] and aids in the cognitive efficiency of the notation.
nested type end-attached typeconnected type port type node-attached type
A
B
C
BA BA
B
A
A
C
Figure 3.5: Location relations
3.6.3 Syntax Bridges
The graphical notation serves as the concrete syntax of a modelling language
[34]. Syntax bridges are used to describe mappings between the graphical
notation and modelling language constructs (or abstract syntax) [34] and
ensure that there is an ontological fit.
The three syntax bridges are:
• model mapping, the mapping between modelling elements and no-
tation elements,
• attribute mapping, the manner in which attribute values are dis-
played, and
46
48. • relationship mapping, the mapping between meta-class relation-
ships and location relations [34].
47
49. Chapter 4
Graphical Syntax Definition
4.1 A Framework for Graphical Notation Defini-
tion
He et al. (2007) [34] identify steps in defining a graphical notation [34],
namely:
1. defining a notation,
2. defining the location of relationships, and
3. mapping the notation onto an abstract syntax [34].
These steps are followed in order to define a graphical syntax for the
URDAD DSL.
4.1.1 Defining a Notation
Defining a notation requires the identification of the semantic constructs
required to sufficiently represent a coherent model. The traceability and
consistency of the syntax depends on the 1:1 mapping of a construct to its
notation.
The URDAD meta model is specified in the Ecore format [68]. Ecore is
an implementation of EMOF [31] and can be leveraged to define the meta
model of a DSL [25]. The Ecore meta model hence serves as a meta model
for defining meta models, i.e. it is a meta-meta model. Elements from the
URDAD DSL, defined in the Ecore format, represent the semantic constructs
for which a graphical syntax is defined.
4.1.2 Defining the Location of Relationships
The principles identified by Moody (2009) (see Chapter 3), are employed
to guide the definition of the graphical notation as well as the layout for
48
