End-user development by application-domain configuration

Our reference: JSS 9263 P-authorquery-v9

AUTHOR QUERY FORM

Journal: JSS Please e-mail or fax your responses and any corrections to:

E-mail: [email protected]

Article Number: 9263 Fax: +353 6170 9272

Dear Author,

Please check your proof carefully and mark all corrections at the appropriate place in the proof (e.g., by using on-screenannotation in the PDF file) or compile them in a separate list. Note: if you opt to annotate the file with software other thanAdobe Reader then please also highlight the appropriate place in the PDF file. To ensure fast publication of your paper pleasereturn your corrections within 48 hours.

For correction or revision of any artwork, please consult http://www.elsevier.com/artworkinstructions.

Any queries or remarks that have arisen during the processing of your manuscript are listed below and highlighted by flags inthe proof. Click on the ‘Q’ link to go to the location in the proof.

Location in Query / Remark: click on the Q link to goarticle Please insert your reply or correction at the corresponding line in the proof

The reference given here is cited in the text but is missing from the reference list – please make thelist complete or remove the reference from the text: Fogli et al. (2012) and Repenning and Ioannidou(2006), Lieberman et al. (2004), Freeman (1978), Fischer (2009).

Q1 Please confirm that given names and surnames have been identified correctly.Q2 The number of keywords provided exceeds the maximum allowed by this journal. Please delete three

keywords.Q3 Ref. Fischer (2009) is cited in the text but not provided in the reference list. Please provide it in the

reference list or delete this citation from the text.Q4 Ref. Freeman (1978) is cited in the text but not provided in the reference list. Please provide it in the

reference list or delete this citation from the text.Q5 Ref. Lieberman et al. (2004) is cited in the text but not provided in the reference list. Please provide it

in the reference list or delete this citation from the text.Q6 Refs. Fogli et al. (2012) and Repenning and Ioannidou (2006) are cited in the text but not provided in

the reference list. Please provide them in the reference list or delete these citations from the text.Q7 Please provide the volume number and page range for the bibliography in reference “Smith (1990)”.Q8 Please supply the name of the city of publication for reference “Sutcliffe (2014)”.

Please check this box or indicate your approval ifyou have no corrections to make to the PDF file

Thank you for your assistance.

JSS 9263 1

ARTICLE IN PRESSG Model

The Journal of Systems and Software xxx (2014) xxx–xxx

Contents lists available at ScienceDirect

The Journal of Systems and Software

jo ur nal ho mepage: www.elsev ier .com/ locate / j ss

Highlights

The Journal of Systems and Software xxx (2014) xxx–xxxEnd-user development by application-domain configuration

Alistair Sutcliffe∗, George Papamargaritis

• Software tool helps end users develop applications without knowledge of programming languages.• System provides ‘seeding’ of domain-oriented design environments for end-user development.• Novel graphical user interface facilitates specification of temporal and spatial constraints for reservation types of applications.• Two-phase approach provides a generic architecture which can be configured for domains, which then support end-user customisation and

application generation.• Semi-automatic generation of systems for reservation/allocation applications by component composition and reuse.

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

The Journal of Systems and Software xxx (2014) xxx–xxx

Contents lists available at ScienceDirect

The Journal of Systems and Software

j our na l ho mepage: www.elsev ier .com/ locate / j ss

End-user development by application-domain configuration1

Alistair Sutcliffea,∗, George PapamargaritisbQ12

a Manchester Business School, University of Manchester, Booth Street West, Manchester M15 6PB, UK3b Intracom IT Services, Markopolou Avenue, Athens GR 19002, Greece4

5

a r t i c l e i n f o6

7

Article history:8

Received 8 February 20139

Received in revised form 7 October 201310

Accepted 30 November 201311

Available online xxx12

13

Keywords:14

End-user development15

Application generation16

Domain-oriented design17

Domain models18

Graphical user interface19

Reservation applications20

a b s t r a c t

An application generator/tailoring tool aimed at end users is described. It employs conceptual models ofproblem domains to drive configuration of an application generator suitable for a related set of applica-tions, such as reservation and resource allocation. The tool supports a two-phase approach of configuringthe general architecture for a domain, such as reservation-booking problems, then customisation andgeneration of specific applications. The tool also provides customisable natural language-style queriesfor spatial and temporal terms. Development and use of the tool to generate two applications, serviceengineer call allocation, and airline seat reservation, are reported with a specification exercise to configurethe generic architecture to a new problem domain for monitoring-sensing applications. The applicationgenerator/tailoring tool is evaluated with novice end users and experts to demonstrate its effectiveness Q2.

© 2013 Elsevier Inc. All rights reserved.

21

1. Introduction22

End-user software development is receiving increasing atten-23

tion as the number of end users practising software development24

is predicted to rise (Ko et al., 2011). While tools to generate25

user interfaces, such as screen painters and report writers, are26

familiar facilities for end users, creation of software applica-27

tions has remained in the realm of expert programmers. More28

advanced end-user development (EUD) tools have ranged from29

visual programming languages to enhanced spreadsheets and30

graphical design environments (Fischer, 1994). Another approach31

(Repenning and Ioannidou, 2004) has been to facilitate end-user32

development of interactive simulations with rule-driven agents.33

While these tools can help end users to develop educational and34

entertainment-oriented applications, they do not appear to scale35

to business domains or complex software engineering problems.36

While some genres of domain-specific tools with programmable37

scripting languages have been successful, notably spreadsheet38

(Burnett, 2009) and database (SQL) programming (Batory and39

Geraci, 1997), end users in most domains still have to learn con-40

ventional programming languages.41

Model-driven architectures have produced a range of tools42

which could potentially empower EUD. However, these tools (e.g.43

executable UML: Mellor and Balcer, 2002) rely on expert knowledge44

∗ Corresponding author. Tel.: +44 0161 306 3315.E-mail addresses: [email protected], [email protected]

(A. Sutcliffe), [email protected] (G. Papamargaritis).

for specification in semi-formal notations and an action specifica- 45

tion language for procedural detail. Action specification languages 46

follow the syntax and semantics of conventional programming lan- 47

guages and present a considerable barrier for end users (Ko et al., 48

2011). Similar problems are encountered with component-based 49

software engineering, where glue code has to be written to interface 50

components, or components have to be customised with a scripting 51

language, as in ERPs (Keller and Teufel, 1998). 52

EUD has been defined as “a set of methods, techniques, and 53

tools that allow users of software systems, who are acting as non- 54

professional software developers, at some point to create, modify, 55

or extend a software artifact” (Lieberman et al., 2006). However, the 56

boundary between language-oriented development (Batory et al., 57

2002; Myers et al., 2004) and customising, configuring (Eagan and 58

Stasko, 2008), and tailoring (Pipek and Kahler, 2006) software is 59

blurred, where the latter tend to involve parameterisation of exist- 60

ing programmes, rather than direct modification of a program’s 61

source code. In this paper we describe application generation and 62

tailoring with an end-user interface that does not require any spe- 63

cialist knowledge of programming concepts. We therefore describe 64

our EUD approach as an application generator-tailoring tool. 65

In contrast to end-user programming and end-user software 66

engineering (Burnett, 2009; Ko et al., 2011) we aim to hide 67

the complexities of programming and scripting from the users, 68

and instead facilitate application development via user-friendly 69

graphical interfaces. Question and answer dialogues with form fill- 70

ing are used to capture user requirements in two phases, first 71

by customising a generic architecture with components selected 72

from related domains; then end-user requirements are expressed 73

0164-1212/$ – see front matter © 2013 Elsevier Inc. All rights reserved.http://dx.doi.org/10.1016/j.jss.2013.11.1121

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

2 A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx

directly in a dialogue with the generated application. We explore74

two approaches to bridge the communication gap in EUD: (a)75

use of generic conceptual models of application domains, and (b)76

application customisation using diagrams representing real-world77

domains. In following sections we describe related work; the design78

and software architecture of an end-user oriented application tail-79

oring tool (EATT); its implementation; usability evaluation with80

novice end users; and configuration of the architecture to new81

domains. The paper concludes with a discussion comparing our82

approach with other EUD tools.83

2. Related work84

End-user development has followed many paths, ranging from85

domain-specific high-level languages (Batory et al., 2002; Freeman,86

1987; Neighbors, 1984) to high-level domain-oriented design envi-87

ronments (DODEs) (Fischer, 1994) that take a reuse component88

configuration approach; and hybrid environments composed of89

graphical objects, simple rule scripting and interaction to specify90

programmes (Lieberman et al., 2006; Repenning and Ioannidou,91

2004; Ioannidou et al., 2009).92

EUD via domain-specific languages was supported by high-level93

compilers or application generators, such as Draco (Freeman, 1987;94

Neighbors, 1984), that produced applications by enabling design-95

ers to create domain-tailored specification languages which could96

then be used to generate software systems within the same domain.97

The reusable Draco domains consisted of an abstract language98

containing objects and functions with alternative implementation99

routes, and a transformation engine to select optimal implementa-100

tions. However, the scope of Draco was limited by the hierarchy of101

implemented domain languages and mappings to executable com-102

ponents. KIDS (Smith, 1990) generated applications from formal103

specification of functions and high-level transformations. High-104

level requirements were expressed in a set-theoretic formalism105

which required programming expertise.106

GenVoca (Batory and Geraci, 1997; Batory et al., 2000, 2002)107

used domain analysis to specify a grammar consisting of realms108

and components, which was used to generate libraries of data109

structures, databases and graphical components. Realms mod-110

elled the problem, organising systems into parameterised layers.111

Components implemented alternative functional refinements, so112

the generator configured a multi-layer architecture by extend-113

ing component templates where extensions of components were114

formulated as type equations. This required adoption of a template-115

based programming style (Batory et al., 2000) which excludes end116

users, who have to understand the syntax and semantics of the117

GenVoca grammar.118

Restricted natural language has been advocated as one way of119

escaping from the formal language trap for end users. The unified120

approach (Zhisheng et al., 2002) supported a query-based approach121

to application generation. End users submitted their requests for122

new applications as queries, using an SQL-like natural language123

which combined a domain-specific sub-language for expressing124

requirements (e.g. banking) and quality of service constraints (e.g.125

end-to-end delay, throughput). However, reuse was limited since a126

new domain-specific sub-language had to be constructed for each127

application.128

A similar approach used a question–answer (QA) agent (Yoshida129

et al., 2004) to capture the user requirements and translate them130

into abstract classes and generation rules. The QA agent matched131

the users’ answers to design rules that generated specific appli-132

cations from a product-line component library. Although the133

QA interface was natural language-based it assumed knowledge134

of a formal domain ontology. Explore/L (Markus and Fromherz,135

1994) provided a natural language interface with a restricted136

vocabulary and syntax consisting of simple declarative sentences 137

(i.e. subject–verb–object) for expressing requirements. Although 138

the templates for expressing classes of requirements were gen- 139

eral they had to be customised with a semantic lexicon of the 140

domain, and interpreters developed to map user requirements to 141

components for application generation. Furthermore, the range of 142

requirements expressions was limited by the set of templates and 143

interpreters provided. 144

More recently, service-oriented EUD approaches have proposed 145

domain-specific languages for e-government services (Fogli and 146

Parasiliti Provenza, 2012) and navigation with location-based ser- 147

vices in mobile applications (Stav et al., 2013). While the domain 148

languages and form-filling menu-driven interfaces of these systems 149

are more end-user friendly, they do rely on domain experts to spec- 150

ify domain components and configure development environments 151

for end-user customisation in relatively restricted domains. Gen- 152

eral EUD environments based on task-tree diagram specifications 153

have also been produced for customising service applications for 154

web and mobile platforms (Paternò et al., 2011); a case study for 155

genres of reservation applications is reported. Similarly, EUD lan- 156

guages and customisation support for a reservation/allocation task 157

based on design patterns has been proposed by Seffah and Ashraf 158

(2007). While these systems enable relatively easy development 159

by menu/diagram-based interfaces, they do rely on extensive, prior 160

configuration by domain experts or service component developers. 161

Spreadsheets as an exemplar end-user tool have been exten- 162

sively researched by Burnett et al. (2002), whose aim was to 163

improve the correctness of user-generated script by algorithms 164

that detected user errors from their interaction with spreadsheets. 165

This approach is limited to configuration and validation of spread- 166

sheets, rather than a wider range of applications. Domain-oriented 167

design environments (DODEs: Fischer, 1994; Fischer et al., 2004) 168

eliminate the need for high-level languages by taking a compo- 169

nent tailoring and reuse approach. Components and design patterns 170

are represented in graphical forms mapped to the domain, then 171

end-user development is supported by explanation facilities and 172

critics which guide the users’ tailoring activities. Fischer argues 173

that the DODE concept transcends end-user development towards 174

‘meta design’ where the user is engaged in a domain-oriented 175

design activity, insulated from coding and computational seman- 176

tics (Fischer et al., 2009). However, DODEs do require configuration 177

with components and knowledge within a restricted range of appli- 178

cations (or a domain) in a seeding cycle (Fischer, 1998). 179

Graphical EUD environments generally require less specialist 180

programming knowledge from end users, since they reply on inter- 181

action with graphical objects to specify computation semantics 182

(Lieberman et al., 2006). A wide variety of notations (e.g. entity 183

relationship, data flow, flowchart diagrams) have been proposed for 184

graphical EUD as well as domain specific notations for CAD (com- 185

puter aided design) environments (Hale et al., 2012). Graphical EUD 186

has been based on agent-based paradigms and graphic templates 187

for constructing rules (Repenning and Ioannidou, 2004), while 188

Myers et al. (2004) made extensive use of graphical metaphors 189

to suggest natural programming concepts (ALICE). End users cre- 190

ate and designate graphical objects with editors and then produce 191

behaviour by a combination of rule-based specification and user 192

interface manipulations from which the environment infers rules, 193

as ‘programming by example’ However, these agent rule-based 194

programming environments have mainly been targeted at educa- 195

tional applications, games and applications where physical objects 196

are present. The graphical approach may be more difficult to 197

apply to information systems that involve transactions with virtual 198

objects. 199

Although previous research has moved some way towards end- 200

user development tools which hide programming from end users, 201

there is a contrast between application generators that span a 202

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx 3

wide range of applications but employ either restricted natural203

language or formal specification languages; and graphical EUD204

environments which have concentrated on education and games-205

style environments. The challenge we address is to preserve the206

graphical environment ease of use while extending generation to a207

wider range of domains.208

3. Domain-oriented end-user development209

The approach we investigate is to develop the domain-oriented210

approach to support end-user development (Fischer, 1998; Fischer211

et al., 2009), but overcome the ‘seeding’ problem by a new con-212

figuration tool based on generic conceptual models of problem213

domains. We explore how the domain configuration limitations of214

DODEs might be overcome in a two-phase approach:215

(i) Configure a generic application generation environment with216

high-level conceptual models.217

(ii) Specialise a selected high-level model with more domain-218

specific information to enable generation of a concrete219

application.220

Given the two-phase approach, we address two types of end221

user: first, end users who have some knowledge of computing,222

even though programming and software development is not their223

main professional role; and secondly, end users who have little or224

no knowledge of computing. The latter group are true end users,225

while the first group may be regarded as intermediary end users.226

The development strategy was to create tools so intermediary users227

could generate applications from software templates and then true228

end users could customise the generated applications without any229

specialist knowledge. This contrasts with the end-user software230

engineering view of users as technical specialists who create pro-231

grammes for their own use, where software tools are intended to232

improve software quality (Ko et al., 2011; Burnett, 2009).233

Our approach to the seeding problem is to first configure the234

environment with generic models covering a wide range of possible235

applications, in this paper, allocation/reservation-type problems,236

although we have researched generic conceptual models for other237

domains such as hiring, sales transactions, etc. (Sutcliffe, 2002;238

Sutcliffe et al., 2006). In the second phase a domain expert elab-239

orates the seed with more domain-specific detail by specialising240

classes and adding attributes. The seeded environment is then241

ready for end users to generate a range of applications within the242

scope of the generic models.243

Following our aim of hiding the complexities of programming244

from end users, application generation is based on component245

reuse, with user interface facilities for component search and tail-246

oring that combine natural language processing and programming247

by demonstration in graphical user interfaces.248

The process can be summarised in the following research ques-249

tion:250

Can the gap between programming and end-user development be251

bridged in two phases: configuring high-level conceptual mod-252

els, followed by domain customisation and automated application253

development?254

While comparison with the alternative single-phase approaches255

(generation from seeded DODEs, or generation from specifications256

in high-level language) requires a longitudinal case study compar-257

ison of implemented technologies beyond the scope of this paper,258

we intend to establish proof of concept of the approach as a first259

step.260

3.1. Process overview 261

This section introduces the EUD process based on the two- 262

phase approach. The process sequence is summarised in Fig. 1, 263

which illustrates the steps and tool support in configuring the EEAT 264

environment leading to application development. An interactive 265

configuration/customisation approach is adopted so steps 1–9 are 266

manual tasks supported by editor tools, leading to full automatic 267

application generation in step 10. 268

The process starts by the domain expert/configurer deciding the 269

terms of reference or scope of the applications to be generated. In 270

the case study this is reservation/allocation genre applications. The 271

select domain model process (step 1) is supported by the domain 272

model library and a simple browser-editor tool which helps the 273

domain expert find the most appropriate domain model family 274

for the target range of applications. In step 2 the domain expert 275

specialises the selected generic domain model by adding high- 276

level attributes from an analysis of existing domain languages. 277

Step 3 involves configuring the database and algorithms for the 278

application generator, by selecting algorithms from the appropriate 279

repository and customising them for the database schema, i.e. range 280

of data types, expected values, etc. This step is supported by editor 281

tools for configuring the database schema and specialising generic 282

algorithms from the algorithm repository. In the current version of 283

the EATT tool the choice of algorithms is constrained by the iOpt 284

library to variety of heuristic search and genetic algorithms. In the 285

case study this produces an application generator for a domain 286

genre (allocation/reservation problems), with assumptions about 287

the range of data types that can be addressed. In an alternative 288

development a generator for a range of hiring/loans applications 289

might be produced. At this stage the domain expert hands over 290

the configured application generator to the end user. The bound- 291

ary of role responsibilities in the process is flexible; however, the 292

subsequent steps are driven by user interface wizards so the user 293

does not require knowledge of algorithm scripts, component code 294

or database schema. 295

The end user’s role commences with analysis for the specific 296

range of applications intended from the generator, i.e. either a 297

range of booking reservations/applications (hotel rooms, theatre, 298

train tickets, etc.) or allocation applications (allocating contractors 299

to jobs, tools to tasks, etc.). Domain analysis (step 5) captures ter- 300

minology in natural language, any graphical-spatial details which 301

are relevant, with the business rules and constraints to gener- 302

ate the application logic (e.g. in room booking, the size, cost, 303

facilities, days available; for theatre bookings the performance 304

ID is added; while for train tickets the time and route will be 305

necessary). These specific attributes will be edited into generic 306

placeholders created in step 3 during the database configuration. 307

There is no specific support for data analysis activities where 308

word processors and graphical drawing packages can be employed. 309

Specialising the domain model (step 6) is supported by the con- 310

straint editor for specialising algorithms for business rules which 311

work in conjunction with the domain properties mapper to create 312

〈condition, action〉 rules to deliver the desired range of reservation 313

applications. 314

The user interface for the specific application is specified in step 315

7, which involves two sub-processes; step 8 adds the commands 316

and input fields for the specific application (theatre performances, 317

times, and costs) with location and view points of the seats dis- 318

played on a theatre layout diagram, so the end user can select 319

performance dates and times with the desired seats. A form- 320

filling/menu selection tool, add UI terms and commands follows 321

(step 8), while graphical drawing tools (e.g. Photoshop) are used 322

for constructing the graphical user interface (step 9), with an editor 323

to designate which graphical objects are active for the application’s 324

operational dialogues. Graphical objects from the Photoshop image 325

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

4 A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx

Fig. 1. The EEAT configuration process, illustrated as a data flow diagram.

file are designated as active selectable objects using the Windows326

GUI icon classes.327

At this stage configuration of the EEAT generator is complete,328

so the user can execute the fully automated step 10 to gener-329

ate the specific application. The support tools, query matcher and330

search/allocation controller, build the application UI and link the331

customised algorithms to user input commands and the back-end332

database. In step 11 the specific application is run by entering val-333

ues into a form-filling user interface with menu lists to specify user334

requirements for (in a theatre booking application) a play, at a335

specific date/in date range, with seat reservations, etc. When the336

specification is complete is a matter of user judgement in light of 337

the two phases of domain analysis. In the first generic configura- 338

tion phase the initial domain model starts with a limited number 339

of generic attributes and method templates for each object. More 340

generic methods and attributes are added, and the seed ones spe- 341

cialised to cover the target range of applications. At this stage 342

over-specification is advised. In the second customisation phase all, 343

or more usually a sub-set, of the generic attributes and methods are 344

specialised according to the requirements of the applications to be 345

generated. The end user has to judge when the functional specifica- 346

tion meets the requirements, e.g. is a seat reservation service part 347

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx 5

Domain Model Library

Configuration Wizard

Database Configuration

Domain Configured Generator

Algorithm Library

Configuration

Domain Model

Configuration

Domain Generation Components (fig 3)

Fig. 2. Components of the EATT architecture supporting phase 1 (configuration),illustrated as UML packages.

of theatre booking, train ticket purchase, etc.? If generic objects for348

seats had not be added in the first configuration phase, the process349

iterates until the requirements for all the target applications are350

met.351

In the following section the process and support tools are352

described in more detail with a scenario of use illustrating how the353

domain expert and end user configure then customise and generate354

an application.355

3.2. Phase 1: configuring the system architecture356

The starting point for our approach was to develop a generic357

architecture which could be configured to generate wide-ranging358

applications within domains similar to ‘abstract’ product lines. The359

architectural concept is related to domain-oriented design environ-360

ments (DODEs: Fischer, 1994; Fischer et al., 2004) which provide361

a software framework containing generic components for manag-362

ing a reuse library, component retrieval, explanation facilities and363

critics to guide the end-user development. DODEs have to be con-364

figured with design examples and domain knowledge to power the365

advisors and critics (Fischer, 1994). However, they do not actu-366

ally generate working applications, and user developers have to367

author code to add any functionality beyond the given reusable368

components. In contrast, EATT is intended to generate executable369

applications directly via algorithm selection from a reuse library.370

The generic architecture is illustrated in Fig. 2.371

Three main components have to be configured to create a work-372

ing application generator: first, the component retriever has to be373

provided with component descriptions for algorithms and other374

reusable components; secondly, meta-data for databases to be used375

in the application has to be supplied; and finally, models of the376

domains are necessary.377

A wizard configuration editor guides the configuration pro-378

cess to populate the architecture with appropriate domain models,379

the database with meta-data, and the reuse component library380

with properties and other details. The design wizard consists381

of a dialogue management template which has to be populated382

with domain models and rules to map the user’s language to383

search parameters. Similarly, the application generator template384

has to be configured with appropriate domain and solution knowl-385

edge to enable composition rules to select, order and integrate386

search/matching algorithms, data retrieval processes and end-user387

interface components. Finally, there is a template for restricted nat-388

ural language interpretation which has to be specialised for the389

target domains.390

End-user application generation takes place in two phases: 391

(i) Domain configuration: In this phase the end user acts is a domain 392

expert intermediary with some software engineering back- 393

ground, who selects the domain models and then configures 394

the architecture for the range of applications to be generated. 395

This requires specialising the domain models with a domain 396

sub-language. 397

(ii) Application customisation and generation: In this phase further 398

detail is added by the end user then the application is generated 399

resulting in an end-user query interface or requirements input 400

dialogue. 401

The first phase of domain configuration is aimed at ‘intermedi- 402

ary users’ since although no programming or software engineering 403

is involved, some computing knowledge (i.e. requirements analysis, 404

specification and modelling) is advisable for domain configura- 405

tion. Domain models are taken from the domain theory library 406

(Sutcliffe and Maiden, 1998; Sutcliffe, 2002), which contains con- 407

ceptual models that are sufficiently abstract to cover a large number 408

of application variations, while being sufficiently concrete to be 409

comprehensible to end users. The models are essentially sets of col- 410

laborating classes motivated by a high-level functional goal, such as 411

handling hiring and rental transactions. The family of object hiring 412

‘object system models’ (OSMs) contains classes representing the 413

resources, the requesting agent, with generic methods for hand- 414

ling loans, returns, renewals, reservations, etc. Other examples of 415

OSM ‘domain families’ are object sensing for monitoring applica- 416

tions, object aggregation for compositional transactions, and agent 417

control for command and control systems. In total 11 families with 418

2–3 sub-family specialisations are described. However, the domain 419

theory models are paper-based descriptions so they have to be 420

converted to an XML machine-processable format. 421

In the case study reported in this paper, the object allocation 422

(OA) domain family was selected; this has the potential to generate 423

any application with goals involving reservation, booking, match- 424

ing or selection of resources. The OA domain consists of a set of 425

resources, resource sub-classes, a requesting agent and an allocator 426

agent with generic matching method; see Fig. 3. 427

Model specialisations within this family are for conceptual 428

objects with sub-classes for financial information, resources, tasks, 429

time-slots and goal-responsibilities; and physical object alloca- 430

tion, with lower-level sub-families for human agents, machines 431

(non-human agents), physical and spatial resources. Models can 432

be aggregated to describe problem domains; for example, allo- 433

cating courses to rooms in training/educational domains involves 434

conceptual resources being allocated to spatial physical resources 435

(rooms), and if time scheduling is needed, temporal slot alloca- 436

tion can be added. OA applications have two operational modes: 437

selecting resources for user requirements, and matching one type of 438

resource to another (e.g. allocate people to tasks). All domain mod- 439

els are linked to generic requirements which describe design issues 440

and goals relevant to the problem domain, in the allocation case 441

consideration of the complexity of the resource and client require- 442

ments, conflicts in demands between stakeholders, optimisation, 443

constraints relaxation, etc. The generic requirements indicate the 444

complexity dimensions of the problem space and other factors, 445

such as the possibility of relaxing constraints in matching and 446

search which might influence the solution. Domain analysis is car- 447

ried out to extend the OSM generic domain models to add further 448

entities, methods and attributes which may be necessary to for 449

applications in the expect scope of generation. At this stage meth- 450

ods are added as placeholder stubs or outline scripts rather than 451

detailed specifications. 452

Other operations in the configuration phase are selection of 453

any necessary databases and the search/matching algorithms to 454

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

6 A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx

Fig. 3. Object allocation domain model for booking/reservation applications with resource sub-classes and generic requirements: design issues.

be used. The British Telecom iOpt algorithm component library455

was selected to supply the application logic and search/matching456

processes. This choice was driven by pragmatic, industrial consider-457

ations: British Telecom wished to enhance the reuse of its algorithm458

library. iOpt is an object-oriented framework for solving constraint-459

based satisfaction or optimisation problems with a configurable460

library of search algorithms ranging from simple hill climbing to461

heuristic search and genetic algorithms for evolutionary comput-462

ing solutions. It supplies constraint-based problem solving and a463

variety of heuristic search algorithms, with built-in data types (e.g.464

integer, real, Boolean, string, object, and set data types), and oper-465

ators (e.g. arithmetic, logical, set) to build a constraint satisfaction466

problem solver. The library of search components is used to instan-467

tiate heuristic search algorithms which start with a basic solution468

to a search problem and then perform iterative (breadth, depth)469

moves to improve the solution. iOpt models allocation require-470

ments as constraints and provides heuristic search algorithms to471

search for feasible solutions which satisfy the constraints. Meta-472

heuristics (e.g. simulated annealing, taboo list) guide the algorithm473

in the search space towards optimal solutions. At this stage the474

configured generator is populated with Object Allocation concep-475

tual models from the domain model library, databases of searchable476

resources and iOpt constraint-based search algorithms.477

The domain model configuration dialogue is driven by the478

generator wizard which guides the user through the design pro-479

cess. After the architecture has been populated with the desired480

domain models from the domain theory OSM library, the generic481

properties for each model class are specialised with the domain482

model/properties editor. Then mappings between resources and483

related terms in the users’ requirements language are captured484

with the domain properties mapper so the iOpt algorithms can485

search resource databases. The constraint editor enables the user-486

designer to add constraints to prevent the end user from selecting487

invalid matches between resource classes, e.g. machine agents to488

training resources, and to specify domain-specific constraints. The489

results of configuration are written to XML files which are used 490

in the generation process. The last configuration task is to add 491

interpreters to handle ambiguous natural language terms in end- 492

user queries. Rules are specified for spatial and temporal terms 493

by interacting with timeline or layout diagrams to denote precise 494

interpretation of ambiguous terms. Then the wizard prompts the 495

user to generate the specific application by picking the mode of 496

operation (requirements matching or inter-resource allocation), 497

followed by the types of resource and their properties. If the 498

requirements mode has been selected then an end-user query 499

interface is generated and queries composed of property (attribute) 500

values and Boolean operators can be entered to select resources. 501

Alternatively, for the matching mode the end-user interface is 502

generated to request input of constraints for the specific resource- 503

matching problem. In both cases the iOpt search algorithm library 504

is invoked to select the appropriate resources from the database 505

and to find the optimal allocation. 506

The domain model selection/configuration dialogue is illus- 507

trated in Fig. 4. In this implementation the generator architecture 508

has been configured with the OA family of domain models for 509

matching, booking and resource allocation problems. First, the 510

intermediary user selects the domain model sub-family; in the 511

illustration, human agents and tasks-jobs have been selected for 512

the matching mode of operation. The wizard supplies concrete 513

examples of the selected domain models to guide the user. 514

3.3. Phase 2: customisation and application generation 515

This phase starts with conversion of the domain models into a 516

machine-processable XML format, and analysis of the domain sub- 517

language. The domain theory models provide a high-level set of 518

abstract properties for classes, for instance the OA family lists prop- 519

erties for physical resource objects as: identifier, size, shape, mass, 520

colour and type. However, these can be specialised with a specific 521

domain lexicon to provide more comprehensible variable names 522

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx 7

Fig. 4. Configuration interface showing domain model selection for resource allocation matching problems.

for the end-user dialogue. A domain language analysis was carried523

out to collect a corpus of terms used in scheduling and matching524

applications within British Telecom and by searching the literature525

for resource allocation case studies. This created a domain lexicon526

for reservation, booking and matching applications. Some exam-527

ples of the generic properties used to populate the design wizard528

are:529

Physical resource/human agent: Age, height, weight, role, qualifica-530

tions, skills, knowledge, generic attributes.531

Physical resource/machine agent: Type, function, inputs, outputs,532

production capacity, mass, production rate, power, resource533

requirements, generic attributes.534

Conceptual resource/task: Type, complexity, goal, inputs, out-535

puts, pre- and post-conditions, state, average duration, generic536

attributes.537

Generic attributes are placeholders which can be elaborated as538

new property types, while term instances and all synonyms can be539

added to property types during the design configuration phase of540

application generation. The components of the generator architec-541

ture are illustrated in Fig. 5.542

3.3.1. Application customisation543

Application customising is intended to be carried out by true end544

users rather than intermediaries, since all operations are driven by545

graphical user interfaces.546

Properties for the selected domain models are specialised for the547

range of applications anticipated in the domain. The end user may548

either refine the generic properties or new properties can be added,549

as illustrated in Fig. 6. This shows how an generic property in the550

OA human agent model ‘skill’ can be specialised with more specific551

skills which will be present in the databases that are expected to552

be used in application generation, e.g. engineer skills in customer553

Domain Properties

Domain Properties

Mapper

iOpt Library

Constraint Editor

End User Application Generator

Generated Application

Customisation Wizard

UI Customiser- Interpreter

Domain Model

Specialisation

Fig. 5. Architecture of the configured end-user application generator showing toolswhich support phase 2 (application customisation and generation).

service, line and server installation, etc. Properties can be refined 554

into sub-classes and instances, e.g. for human agents, the specific 555

types of skills expected in a range of domains can be given or qua- 556

lifications refined into academic and vocational, etc. Each property 557

is specified either as an enumerated set or value domains with data 558

types and ranges. 559

Once the domain sub-language and models have been loaded 560

into the generator, the next step is to supply matching rules to link 561

the user’s requirements language to resource descriptions, or guide 562

the mappings between two sets of resources in the matching mode 563

of operation. Matching rules are specified either manually by the 564

user indicating mappings on the displayed lists of properties, or 565

automatically by the system searching resource attribute lists for 566

exact or partial lexical matches. This is augmented by stemming 567

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

8 A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx

Fig. 6. Domain property specialisation dialogue in the domain mapper tool.

algorithms (University of Lancaster, 2005) and WordNet synonym568

lists, although the user has to confirm partial matches.569

The matching algorithm is:570

While requirements terms (input)For each resource classSearch Resource properties for exact lexical match

Write exact match mapping ruleSearch Resource properties for partial match

Apply Stemming algorithmAssess matchIf successful

Write mapping ruleElse

Search Wordnet for synonymsAssess synonym matchIf successful

Write mapping ruleElse

Report no matchEnd-if

End-ifEnd

Display mapping rulesRequest user to add rules for no-match termsRequest users to confirm mappings

571

The automatic process establishes mapping and then requests572

the user to supplement these with other requirement-resource573

property mappings that need domain knowledge to construct the574

rule; see Fig. 7.575

The constraint specification dialogue has a similar structure to576

the matching rules and allows the user to specify compatibility577

constraints between resource and requirement properties which578

are stored in an XML constraints file for the application schema.579

First, the user specifies one or more property values in the source580

resource class, and selects property values to specify incompatible581

requirements for the target resource class.582

3.3.2. User interface customisation583

The generated end-user interface for the allocation application584

is a simple query interface composed of menu lists of properties585

with form-filling dialogues to complete the queries with value con- 586

straints and limited Boolean operators. However, the application 587

may need further customising to fit end users’ needs. For exam- 588

ple precise lexical matching requires users to be precise in their 589

specification of queries and matching constraints, which does not 590

always come naturally. The application customising phase there- 591

fore includes a facility to generate interpreters for ambiguous and 592

fuzzy queries in natural language rather than enforcing input of 593

precise values and use of Boolean operators. Of course there is no 594

escape from the need to be precise, so the user-designer has to 595

configure natural language interpreters with semantic definitions 596

of ambiguous natural language terms. 597

Application customisation also supports specialisation for 598

expression of temporal and spatial requirements. Allocation prob- 599

lems often involve spatial resources and temporal constraints, so 600

interpreter configuration modules have been developed for a range 601

of terms such as ‘nearby’, ‘adjacent’, ‘close to’ for spatial alloca- 602

tion, and ‘before’, ‘just after’, ‘immediately after’, etc., for temporal 603

constraints. The configuration facilities allow end users to add as 604

many ambiguous terms as they wish and specify the precise inter- 605

pretation by graphical editors and timeline specification dialogue, 606

as illustrated in Fig. 8. The spatial interpreters are more restricted 607

since they rely on a domain-specific topography, e.g. layout of 608

seats in an aircraft, theatre, etc. These also support end-user cus- 609

tomisation since configuration of the interpreter is driven by user 610

interfaces of familiar graphical drawing tools with annotations on 611

diagrams of resources for a particular domain. Once an interpreter 612

has been implemented for set of spatially organised resources (e.g. 613

seating plans, room layouts), it can be rapidly reconfigured for dif- 614

ferent application versions. 615

Temporal ranges are selected for the sliders (minutes-hour, 616

hours-day, days-week, etc.), then the natural language term is 617

entered on the left-hand side of the screen and the sliders are 618

manipulated to specify the precise temporal interpretation. A sim- 619

ple lexicon allows the system to infer definitions from the slider 620

position (e.g. ‘before’, ‘after’, ‘map’ to left or right of the slider 621

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx 9

Fig. 7. Matching rules dialogue in the constraint editor tool.

Fig. 8. Temporal interpreter UI customisation dialogue, in which the user enters an ambiguous temporal term and then specifies its interpretation by moving sliders todenote time ranges.

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

10 A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx

Fig. 9. Illustration of UI customisation with a spatial interpreter illustrating a boundary being specified for interpretation of ‘next-to’.

position); durations (e.g. ‘mid-morning’) expect two sliders to be622

set, while some terms such as ‘early’ may be defined as points with623

one slider or as a duration with two. Two sliders can be selected624

to express concurrency, ‘at the same time as’, although the current625

implementation has limited ability to infer more complex temporal626

semantics such as ‘start within a short while after’.627

To initialise the spatial interpreters the designer–user has to628

describe the topography of the domain with standard graphical629

drawing tools (e.g. PowerPoint, Photoshop). A dialogue then guides630

the user to specify the semantics of ambiguous natural language631

terms, such as ‘nearby’, by pointing and annotating the domain632

sketch; see Fig. 9. The system’s object management system infers a633

spatial rule from the annotations, for example, objects falling either634

side of a boundary on the diagram will be interpreted as ‘nearby’635

or ‘not nearby’.636

The user enters the term then selects objects on the diagram to637

define a precise meaning. As with the temporal interpreter the sys-638

tem users a lexicon to control the dialogue and inference process.639

Spatial definitions can be either specified by user action alone with640

multiple points, e.g. for ‘nearby’ the system takes the first selec-641

tion as the target and all subsequent selections as proximal objects.642

Alternatively the user can label objects as composites, as shown in643

Fig. 9, where blocks and rows have been specified for seat reserva-644

tion applications. ‘Nearby’ is then defined by selecting seats within645

that block. Similarly negation, ‘not too close to’, is inferred from646

gaps between the target and distal objects in a structured topology.647

In layouts without a structured topography the system provides648

a ‘bullseye’ metaphor so proximity can be defined by manipulat-649

ing the bullseye rings which are linked to customisable distance650

scales (mm, cm, metres). The system infers the meaning of ‘nearby’651

or ‘away from’ as the position of objects falling within or outside652

the ring measured from the target object. Other interpreters can653

be configured in a similar manner by the system making infer-654

ences from lines drawn on topographic sketches, e.g. directions and655

connections between objects are inferred from the coordinates of 656

lines and object locations. 657

4. Implementation 658

The generated system architecture consists of the 659

query/requirements capture interface (see Fig. 10) which employs 660

form-filling dialogues to capture either the user’s query for 661

resources or constraints when matching two sets of entities. The 662

end-user interface also calls the customised natural language 663

interpreters as required by the query dialogue. The user’s query 664

is then sent to the Allocation search controller which calls the 665

appropriate iOpt APIs, and supplies parameters to search the 666

appropriate resource databases. The search results are returned to 667

the user interface to display lists of resources, partially matched 668

resources or error messages if no matches were found. 669

In this example the user has been prompted to select their tar- 670

get location and has enquired about the availability of free places 671

close to the target. The system will highlight all contiguous avail- 672

able places; however, if the user has requested ‘nearby’ following 673

the definition shown in Fig. 9, only the places to the left and right 674

would be highlighted, since the system inferred nearby to be left, 675

right and in front of the target within the same block. 676

The generated application architecture (see Fig. 11) consists of 677

three packages: user interface classes which implement the UI 678

query/matching and results display; spatial and temporal inter- 679

preters called by UI classes to handle natural language input; and 680

the Search controller class which calls and controls iOpt library 681

components to execute database searches. 682

EATT was implemented in Java using JavaSwing UI components. 683

The lexical matching algorithms use the Java API to access the 684

WordNet dictionary (Java WordNet Library, 2013), while the lex- 685

ical matching process uses the Paice/Husk stemming algorithm 686

(University of Lancaster, 2005). The spatial editor for building 687

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx 11

Fig. 10. The generated end user interface for room booking applications.

spatial models and spatial interpreters is based on the JHotDraw688

tool (JHotDraw, 2013) which generates two-dimensional graphics.689

The Arch4J (Arch4J, 2004) open-source library generated the source690

code for Java classes, while iOpt supplied constraint-based problem691

solving and a variety of heuristic search algorithms. iOpt provides692

built-in data types (e.g. integer, real, Boolean, string, object, and set693

data types), and operators (e.g. arithmetic, logical, and set) to build694

a constraint satisfaction problem solver. A library of search compo-695

nents is used to instantiate heuristic search algorithms which start696

with a basic solution to a search problem and then perform itera-697

tive (breadth and depth) moves to improve the solution. Evaluation698

heuristics assess the efficiency of the solution in comparison to the699

objective function of the input problem. The heuristic search tem-700

plate binds generative (constructive) heuristics, neighbourhood701

search, neighbourhood move functions, evaluation functions, etc.702

In the same way, genetic algorithm templates assemble generative703

heuristics with crossover, mutation, and selection operators. The704

complexity of the input problem can be classified by the complex-705

ity of integrity constraints, and data dependencies expressed in the706

Fig. 11. Generated components in the architecture for the resource allocation appli-cation.

database and in the user’s requirements. Complexity metrics facil- 707

itate semi-automatic selection of the appropriate heuristic search 708

or evolutionary computing processes according to the complexity 709

of the domain. If many data dependencies restrict generate-and- 710

test style search then heuristic search is preferred; alternatively, 711

genetic algorithms or simulated annealing can be used to gener- 712

ate new potential solutions. In the resource allocation case study, 713

heuristic search templates were used as most resource allocation 714

problems implied a high level of data dependencies and integrity 715

constraints. 716

5. Evaluation 717

The first versions of EATT were evaluated in the domain config- 718

uration phase with intermediary users (British Telecom software 719

engineers), then examples of the generated applications were 720

tested with end users. Initial tests demonstrated that the applica- 721

tion generation and customisation could be successfully completed 722

once the system library had been loaded with the appropriate 723

domain models and algorithms. End users found the generated 724

query requirement interfaces easy to use with few usability prob- 725

lems. 726

Two iterations of further usability evaluation were carried out 727

on an improved prototype with six software engineers (who per- 728

formed the intermediary role) and seven novice end users drawn 729

from British Telecom and University of Manchester computer sci- 730

ence undergraduates respectively. The six British Telecom software 731

engineers (domain expert/intermediary role) all had several years 732

(>5) of programming experience in Java and other languages; the 733

novice users were first year students in the School of Informatics, 734

University of Manchester, who had limited programming experi- 735

ence as they had not completed the initial course in Java. Both 736

groups were introduced to the EEAT system in a 30-min train- 737

ing session when the purpose and operation of all features were 738

explained, with hands-on demonstration of editor-customisation 739

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

12 A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx

Table 1Frequency of problems encountered during usability testing of both phases withnovice and intermediary end users.

Subjects Properties Mapping rules Interpreters Query UI Total

Novice, n = 7 25 12 2 17 60Intermed, n = 6 12 2 0 3 17

Total 37 14 2 20 67% 48 18 ∼0 26 100

tools. Participants were encouraged to asked questions to clarify740

any concepts or operations they did not understand.741

In these evaluations both user groups were asked to test the742

whole system, so this represented a more severe stress test for the743

configuration/generation part of the system with novice end users.744

Both groups were asked to configure the generic architecture for745

resource allocation domains; to generate end-user applications for746

two scenarios, room booking and service engineering call alloca-747

tion; and then to operate the generated applications to reserve a748

specific room for a class within a time period (query mode), and749

allocate a set of engineers to a database of outstanding jobs (match-750

ing mode). The test system was configured with databases and the751

iOpt library so these aspects of the first configuration phases were752

not tested; however, all users did have to select the appropriate753

domain model from the library. A lexicon of domain properties754

was provided to enable the domain customisation phase to begin.755

Both novice and expert users completed both tasks in reasonable756

time (range from 22 to 45 min), although the novices required more757

help from the researcher when problems were encountered. The758

problems encountered during the evaluation are shown in Table 1.759

Usability problems encountered by novice and expert users are760

categorised into function areas: specialisation of properties, map-761

ping rules, and user interaction with spatial interpreters, as well as762

usability problems with operating the generated query user inter-763

face.764

Usability problems were defined as critical incidents when the765

users needed help in operating the user interface and experienced766

difficulties in understanding the system so they had to ask the eval-767

uator to explain the meaning of terms. Not surprisingly, novices768

encountered more usability problems than did intermediary users,769

although the distribution was similar with specialisation of domain770

properties accounting for most problems (48%). For both sets of771

users, terminology comprehension problems were most frequent772

(60% of total usability problems) and the majority of these were773

concentrated in the specialised properties task; in contrast, the774

remaining 40% of usability problems were spread more evenly775

with a concentration in the operation of the end-user query inter-776

face. One reason for the high number of problems in the query777

interface of the generated application was the provision of both778

form-fill/natural language queries and the option of using Boolean779

operators. This made the user interface too complex and con-780

fusing for novice users. When the complexity was reduced by781

removing Boolean operators option and simplifying the natural lan-782

guage queries as sets of selections from menu lists, the error rate783

was reduced to low levels. Other parts of the configuration inter-784

face (mapping rules and configuration interpreters) performed785

well with few usability problems. Evaluations of the configura-786

tion facilities of the generator demonstrated that intermediaries787

and novice end users could use the system and successfully cus-788

tomise the generator architecture for resource allocation problems,789

and subsequently generate room-booking and service engineer-job790

allocation applications.791

A usability survey captured the attitudes towards the EATT sys-792

tem of both novice and intermediary users after they had completed793

the configuration, generation and use of the test applications. The794

post-test questionnaires, indicated a positive view of EATT with795

mean rating of the configuration ad customisation interfaces for 796

novices and intermediaries 4.5 and 4.8 (on a 1–7 scale where 797

7 = very ease to use). The most commonly reported problems in 798

open-ended questions were comprehension of domain terms in 799

property selection and specialisation, creation of lexical matching 800

rules and the formulation of matching queries. Users encoun- 801

tered difficulties when specialising generic properties (e.g. task 802

goals and human roles) to more specialised concepts (e.g. job 803

categories). Terminology such as sub-classes, measured property 804

values and enumeration types were too abstract and need to be 805

replaced by simpler expressions. When creating matching rules 806

some irrelevant properties were chosen and users failed to spe- 807

cialise temporal and spatial expressions. The few comprehension 808

difficulties with natural language expressions in the temporal and 809

spatial components were resolved when the configuration dia- 810

grams were used to explain how ambiguous terms were being 811

defined. 812

In the customisation phase 2, novice users experienced difficul- 813

ties when selecting properties associated to enumeration classes 814

(e.g. skills). The graphical user interface controls for moving prop- 815

erty values on the search panels was considered too complex. The 816

number of usability problems declined by over 50% (novice total 22 817

and intermediary total 9) in the second round of testing after design 818

improvements had been made to the configuration/customisation 819

wizard dialogues and end-user interface. Most of the residual 820

problems concerned comprehension of terms in the configuration 821

dialogue which could be alleviated with improved training. All the 822

residual usability problems could be solved with modest effort 823

and addition of explanation facilities to guide end users. In gen- 824

eral, the wizard-based dialogue successfully assisted the users in 825

both phases with step-by-step guidance, demonstrating that the 826

generator was suitable for end users who were novices, as well as 827

intermediary users with some computing expertise. 828

6. Assessment of reusability 829

The usability evaluation demonstrated that EATT showed some 830

promise as an end-user application development tool; however, the 831

development assumed the presence of specifications for allocation 832

domain problems and the iOpt search algorithms library to provide 833

the generated solution. To investigate wider-ranging application of 834

the EATT architecture, a paper-based validation study was under- 835

taken to assess the redesign of EATT necessary for a new domain. 836

This involved the paper’s authors and two colleagues in the Uni- 837

versity of Manchester who were experienced software engineers. 838

Hiring, loans and rental applications were selected since these 839

are all specified as another domain theory OSM family (Sutcliffe, 840

2002). Specific application scenarios of library loans, bicycle rental 841

and fancy dress hire were used to test the customisation process. 842

Table 2 summarises the main changes for the new domain. The 843

configuration wizard enables a new set of generic models to be 844

loaded; however, the object system models and their associated 845

generic properties have to be coded as XML files. The design wizard 846

then controls the specialisation process as in the resource allo- 847

cation domain. The domain properties editor, rule mappers, and 848

interpreter configuration can be reused as they stand. The iOpt 849

algorithm library can also be reused to search for objects for hire 850

in response to users’ requirements. Some changes are necessary so 851

the generator can create the user interface dialogue for loans, hiring 852

operations (request loan, reserve, loan, return, etc.) with new meth- 853

ods for database updating when loaned resources are returned. The 854

effort to configure EATT for the hiring/loans domain was estimated 855

to be approximately five days, consisting of a domain analysis for 856

the hiring/loans lexicon, and modification of four methods in the 857

generator and database update classes. 858

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx 13

Table 2Changes to configure EATT for hiring, loans application domain.

Design wizard Domain properties and mappers Interpreters Generator Algorithm library

Load new OSM family Add properties Reuse as appropriate Reuse Reuse search algorithmsCode XML files Code as XML file Add new terms as required Change UI dialogue Add new database methods

To test more wide-ranging reuse, a second generic domain859

of monitoring applications was selected (object sensing domain860

model family). The domain properties editors and interpreters861

could be reused without change, although a more sophisticated862

temporal interpreter may be required. Mapping rule classes were863

not directly applicable, although they might be reused in event864

interpreters to map signals to higher-level events. The specific865

example used to test customisation was monitoring patients (heart866

rate, EEG, etc.) in long-term healthcare. Configuration of EATT to867

this domain necessitated more extensive changes to the generator868

to implement methods for detecting and interpreting patterns of869

events and then displaying alerts for unusual events as well as nor-870

mal patterns. The iOpt solution library was no longer appropriate871

so a new reuse library would have to be found, e.g. digital sig-872

nal processing and data-mining algorithms. Estimating the effort873

required for this configuration was not possible without further874

specification; however, it was at least two or three times the875

resource for the hiring control domain.876

The reuse testing demonstrated that the EATT architecture could877

be easily transferred to domains with similar transaction properties878

and requirements for searching and matching, for example sales879

order processing, financial transactions, as well as loans and hir-880

ing. However, for domains not related to information system-style881

applications, more effort was required to configure the genera-882

tor, although the basic architectural template and customisation883

wizards were still reusable.884

7. Discussion885

The development of the EATT tool has demonstrated the feasi-886

bility and proof of concept of a two-phase approach for end-user887

development, and extended the DODE approach with a novel888

means of assisting ‘seeding’ design environments with high-level889

conceptual models. Although we did not add critics and expla-890

nation components of DODEs (Fischer, 2009), the domain modelsQ3891

act as design patterns; furthermore, the generic requirements and892

issues associated with the models provide reusable knowledge that893

could be implemented as knowledge-based assistant tools. The894

two-phase approach may empower end-user development with895

simple user interfaces, coupled with powerful configuration tools,896

enabling end users to generate, tailor and use a wide range of897

related applications. It combines a natural language approach for898

components search with specification-based user demonstrations899

and manipulations in a graphical environment, following the inter-900

action style of AgentSheets (Ioannidou et al., 2009). We extended901

the graphical EUD approach into business-oriented applications902

such as booking reservation systems. Usability testing demon-903

strated the effectiveness of the approach, although the range of904

specific applications tested was limited, and large-scale system905

testing was not carried out. Nevertheless, the EATT tool proved906

the viability of end-user application generation/customising tools907

based on models of problem domains. XML-based customisation for908

generating financial applications (Emmerich et al., 2001) is similar909

to our approach, although the range of applications which could be910

generated by TIGRA was more limited.911

The user interface contribution of EATT extends work on UIDE912

(user interface development environments) which have used task913

models to specify the application structure and logic, combined914

with design patterns to semi-automatically generate the user915

interface (Ahmed and Ashraf, 2007). The application of search 916

allocation tasks in a hotel room reservations system was demon- 917

strated in Ahmed and Ashraf; we have extended this with more 918

complex spatial and temporal configuration support for such appli- 919

cations using user-oriented language, e.g. ‘nearby’, and graphical 920

tools to develop reservation/allocation interfaces. A similar task- 921

based approach for end user UI development has been applied 922

to service composition (Paternò et al., 2011), with search-browse 923

tasks in media resource selection applications. In this case the UI 924

and application were generated semi-automatically from service 925

components with embedded UI design knowledge in the tool; how- 926

ever, only simple list-based search was supported, rather than the 927

richer graphical world interaction provided in our system. 928

Unlike many application generators (Freeman, 1978; Smith, Q4929

1990; Markus and Fromherz, 1994; Batory et al., 2000), no 930

knowledge of a formal specification language is necessary in our 931

two-phase approach. The model-driven dialogue allows users to 932

customise the generators to a range of applications, resembling 933

product-line configuration of variation points. The approach is 934

related to model-driven architecture (Mellor and Balcer, 2002), but 935

extends the concept with ‘problem domain MDA’ by using models 936

of application requirements which are closer to the users’ perspec- 937

tive. Models from the domain theory (Sutcliffe, 2002) provide a 938

bridge which proved to be sufficiently abstract to enable customi- 939

sation of a wide range of applications, while being comprehensible 940

to end users. We argue that these domain abstractions are closer to 941

the end-user perspective than GenVoca (Batory and Geraci, 1997; 942

Batory et al., 2000) generators which are focused on technical spe- 943

cialists in database applications. However, even end-user oriented 944

domain models are not easy to understand as most of the user 945

problems in testing the EATT tool involved misunderstanding of 946

terminology. 947

Our work builds on the DODEs approach (Fischer, 1994, 1998; 948

Fischer et al., 2009), in that both are component-reuse based, 949

end users interact via simple dialogues, and both require seeding 950

with models, components and knowledge pertaining to a domain. 951

EATT provides a seeding assistant tool for DODEs since configu- 952

ration requires domain models, solution algorithms and a domain 953

lexicon. DODEs provide a generic architecture for end user devel- 954

opment to build design tools, critics and explanation facilities, 955

but the architecture needs more specific, design knowledge to 956

power explanation and critic facilities. EATT and the domain theory 957

models provide such knowledge, while the combination of natu- 958

ral language and graphical demonstration also enables end-user 959

configuration of user interfaces to specify rules generally appli- 960

cable to temporal and spatial problems. This aspect of EATT is 961

similar to AgentSheets (Repenning and Ioannidou, 2004), although 962

we have not implemented an explicit rule-based system; instead, 963

rules are inferred by graphical annotations on diagrams, adopt- 964

ing a programming-by-example approach (Lieberman et al., 2004); Q5965

however, more complex ‘drag and drop’ style manipulations would 966

require new interpreters to be implemented. 967

EATT extends previous two-phase approaches to end-user 968

development by providing a library of generic conceptual models as 969

a starting point and a range of tools to support the process of devel- 970

opment via progressive refinement of these models and integration 971

with appropriate algorithms to automatically generate solutions 972

via component based reuse. Fogli and Parasiliti Provenza (2012) 973

adopt a similar two-phase approach to EUD for e-government 974

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

14 A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx

services, although their development support environment is tail-975

ored more directly to services for data entry administration and976

reservation/search functions in e-government with a six-step task977

model, so it is not clear how their tools could be adapted for other978

application domains. Another phased but domain-centric approach979

proposed by Drey and Consel (2012) supports EUD for sensors and980

device control in home-based services. However, their approach981

in the Pantagruel programming language provides a more general982

meta-model of sensor–controller–actuator which can be adapted to983

a wide variety of monitor-control oriented applications. The Pan-984

tagruel meta-model is similar to generic problem models in the985

domain theory (object sensing and agent control) (Sutcliffe, 2002,986

2014) which can be used in EATT. In contrast, Stav et al. (2013)987

use three phases/roles from domain developer to service composer988

(app level), then service end user with support for specifying and989

implementing domain-specific languages to drive a menu/form990

filling EUD tool set. Although they illustrate application of their991

approach in the development of mobile apps for navigation and992

location-based services, no evaluation with end users was reported;993

also, transfer to another domain appears to require development994

of a new domain-specific toolkit.995

Application generators with natural language front ends (Mellor996

and Balcer, 2002; Smith et al., 2000; Pane and Myers, 2006) are997

similar to EATT, but they require a more comprehensive configu-998

ration with a restricted natural language ontology and grammar,999

to customise parsers and the generator. In contrast, EATT pro-1000

vides an initial domain ontology and requires less customisation1001

via a limited domain analysis, and simple extension of the domain1002

lexicon. The mapping rules component avoids the complexity of1003

natural language parsing. Although EATT is limited to informa-1004

tion system transactional domains, we believe the model-driven1005

generator approach may involve less configuration than building1006

new natural language parsers. Another contribution of EATT is sup-1007

port for specify rules by graphical metaphors, e.g. timeline sliders,1008

rather than ambiguous natural language terms Although use of dia-1009

grams to express specification concepts is well known in visual1010

programming languages, we believe the diagram-based tempo-1011

ral and spatial interpreters provide a novel extension to natural1012

language interfaces. Diagram-based interfaces capture user inter-1013

actions to infer computational semantics, such as relationships1014

between components in web applications (Newman et al., 2003).1015

Testing inter-domain transformation of EATT showed that core1016

customisation wizards and generation components can be reused1017

across many different domains, while most of the architecture1018

transferred easily within information system transaction-style1019

domains. Our future research will test the prototype generator1020

introduced in this paper for scaling with larger databases, and appli-1021

cations with detailed requirements, e.g. flight booking and seat1022

reservation with constraint relaxation so alternatives can be sug-1023

gested for user choices which cannot be initially satisfied. Another1024

possible improvement is using natural language similarity match-1025

ing algorithms such as latent semantic indexing (LSI) to automate1026

the mapping rules between the user’s requirements language and1027

database terms; however, these algorithms work more effectively1028

with phrases and longer texts then with single keywords. Also, the1029

interpreter package will be extended to add more natural language1030

terms and more complex expression of queries and requirements;1031

in this case, LSI might be more productive.1032

The EATT approach could be incorporated within Software1033

Shaping Workshops – VIS (visual interactive systems end user1034

development) approach (Costabile et al., 2007) which proposes a1035

series of workshops facilitated by HCI (human computer interac-1036

tion) and Software Engineering experts, who help end users specify1037

computational semantics and processes by discussion of images,1038

diagrams and processes. In Costabile et al.’s example of an MRI1039

scan analysis application, computational objects are annotated on1040

images and associated with operations denoted by user-crafted 1041

icons. EATT users created diagrams and images in a similar man- 1042

ner, but combines this customising with component-based reuse. 1043

We agree that a participatory design approach is necessary, which 1044

we tested in iterations of systems evaluation to improve termi- 1045

nology and tool usability. Participatory design involving both end 1046

users and intermediaries could also help to mitigate terminology 1047

problems we discovered during the evaluation. 1048

8. Conclusions 1049

In conclusion, we have described a proof of concept end- 1050

user application generator-customising tool, validated its use with 1051

end users, and demonstrated the reusability of this ‘problem 1052

model’-driven architecture approach. The contribution of the EATT 1053

application generator has been to extend previous two-phase EUD 1054

approaches with configuration based on a library of generic con- 1055

ceptual models that provide a sound starting point to guide further 1056

specialisation. Previous approaches have proposed modelling lan- 1057

guages or conceptual schema; however, modelling has been left to 1058

the user developer with limited guidance. Our two-phase approach 1059

still relies on an intermediary domain expert role which assumes 1060

some software engineering knowledge to interpret computing ter- 1061

minology and select appropriate algorithms; however, domain 1062

experts with such computing/development knowledge are not 1063

unusual in some end-user domains, such as medical informatics 1064

(Driedger et al., 2007; Thew et al., 2009). Furthermore, we contend 1065

that the intermediary role could be achieved by end users with 1066

reasonable training, i.e. introduction to computing with limited 1067

programming/Javascript-style development. 1068

There are several limitations to our work so far, which has 1069

only demonstrated the feasibility of the two-phase approach to 1070

EUD tools. EEAT can be configured to generate applications in a 1071

wide range of domains but it is dependent on the range of the 1072

models in the domain theory library (Sutcliffe, 2002). The appli- 1073

cations generated depend on choice of algorithm library and user 1074

interface toolkit which limited generation to Java environments 1075

using the British Telecom iOpt library. Further work is neces- 1076

sary to reuse other algorithm libraries. The tools are prototypes 1077

which would need development to address the usability prob- 1078

lems identified during the evaluation, as well as further testing for 1079

robustness, so further development would depend on the skills of 1080

the domain expert intermediary user. The evaluation of EEAT was 1081

conducted with a limited number of users and tasks; furthermore, 1082

we did not test the effectiveness of the generated applications, 1083

although informal evaluations did demonstrate their usability. Fur- 1084

ther evaluations will be carried out on the generated tools and 1085

applications with a range of end users with skills varying from 1086

no computer knowledge, domain experts with limited computer 1087

knowledge and more skilled software developers. Only one appli- 1088

cation area, allocation/reservation, was tested, and the range of 1089

applications problems was relatively simple, so in our future work 1090

we will stress-test generation with more complex constraint-based 1091

matching in other reservation problems. Assessment of the gener- 1092

alisability of the architecture was limited to a single paper-based 1093

exercise for configuration to monitoring applications, so while this 1094

provided insight into the modest extent of additional work to trans- 1095

fer EEAT to another problem class, realistic software customising 1096

needs to be undertaken. In spite of these limitations, the work we 1097

have reported suggests that our approach merits further inves- 1098

tigation. However, the ultimate test will involve examining the 1099

trade-off between the effort expended in our two-phase approach 1100

which addresses a wide range of application areas, versus the 1101

configuration effort and ease of use pay-off in more constrained 1102

DODE environments (Fischer et al., 2009). Future work could also 1103

Please cite this article in press as: Sutcliffe, A., Papamargaritis, G., End-user development by application-domain configuration. J. Syst.Software (2014), http://dx.doi.org/10.1016/j.jss.2013.11.1121

ARTICLE IN PRESSG ModelJSS 9263 1–15

A. Sutcliffe, G. Papamargaritis / The Journal of Systems and Software xxx (2014) xxx–xxx 15

investigate the economics of different architectural approaches1104

(Sutcliffe, 2008, 2014) to compare the usability and utility of more1105

domain specific EUD tools (e.g. Fogli et al., 2012) with generic high-Q61106

level specification languages (Repenning and Ioannidou, 2006;1107

Pane & Myers, 2006) for EUD development.1108

Acknowledgement1109

The authors wish to thank British Telecom for use of the iOpt1110

library and support for this research.1111

References1112

Ahmed, S., Ashraf, G., 2007. Model-based user interface engineering with design1113

patterns. J. Syst. Softw. 80 (8), 1408–1422.1114

Arch4J, 2004. Available online at http://arch4j.sourceforge.net/ (accessed 06.02.13).1115

Batory, D., Gang, C., Robertson, E., Wang, T., 2000. Design wizards and visual1116

programming environments for GenVoca generators. IEEE Trans. Softw. Eng.,1117

441–452.1118

Batory, D., Geraci, B.J., 1997. Composition validation and subjectivity in GenVoca1119

generators. IEEE Trans. Softw. Eng., 67–82.1120

Batory, D., Johnson, C., MacDonald, B., Von Heeder, D., 2002. Achieving extensibility1121

through product-lines and domain-specific languages: a case-study. ACM Trans.1122

Softw. Eng. Methods, 191–214.1123

Burnett, M.M., 2009. What is end-user software engineering and why does it matter?1124

In: Pipek, V., et al. (Eds.), End-User Development: 2nd International Symposium,1125

IS-EUD-09. Springer-Verlag, Berlin, pp. 15–28.1126

Burnett, M.M., Sheretov, A., Ren, B., Rothermel, G., 2002. Testing homogeneous1127

spreadsheet grids with the what you see is what you test methodology. IEEE1128

Trans. Softw. Eng., 576–594.1129

Costabile, M.F., Fogli, D., Mussio, P., Piccinno, A., 2007. Visual interactive systems for1130

end-user development: a model-based design methodology. IEEE Trans. Syst.1131

Man Cybern., 1029–1046.1132

Drey, Z., Consel, C., 2012. Taxonomy-driven prototyping of home automation appli-1133

cations: a novice-programmer visual language and its evaluation. J. Vis. Lang.1134

Comput. 23 (6), 311–326.1135

Driedger, S.M., Kothari, A., Morrison, J., Sawada, M., Crighton, E., Graham, I., 2007.1136

Correction: using participatory design to develop (public) health decision sup-1137

port systems through GIS. Int. J. Health Geograph. 6, 53–62.1138

Eagan, J.R., Stasko, J.T.,2008. The buzz: supporting user tailorability in awareness1139

applications. In: Proc. CHI-08. ACM Press, New York, pp. 1729–1738.1140

Emmerich, W., Ellmer, E., Fieglein, H.,2001. TIGRA: an architectural style for enter-1141

prise application integration. In: Proc. SE-01. IEEE Computer Society Press, Los1142

Alamitos, CA, pp. 567–576.1143

Fischer, G., 1994. Domain-oriented design environments. Autom. Softw. Eng.,1144

177–203.1145

Fischer, G., 1998. Seeding, evolutionary growth and reseeding: constructing, captur-1146

ing and evolving knowledge in domain-oriented design environments. Autom.1147

Softw. Eng. 5 (4), 447–464.1148

Fischer, G., et al., 2004. A framework for end-user development: socio-technical1149

perspectives and meta-design. Commun. ACM, 33–39.1150

Fischer, G., et al., 2009. Metadesign: guidelines for supporting domain experts in1151

software development. IEEE Softw., 37–44.1152

Fogli, D., Parasiliti Provenza, L., 2012. A meta-design approach to the development1153

of e-government services. J. Vis. Lang. Comput. 23 (2), 47–62.1154

Freeman, P.A., 1987. A conceptual analysis of the Draco approach to constructing1155

software systems. IEEE Trans. Softw. Eng., 830–844.1156

Hale, P., Solomonides, A.E., Beeson, I., 2012. User-driven modeling: visualisation1157

and systematic interaction for end user programming. J. Vis. Lang. Comput. 23,1158

354–379.1159

Ioannidou, A., Repenning, A., Webb, D., 2009. AgentCubes: incremental 3D end-user1160

development. J. Vis. Lang. Comput., 236–251.1161

Java WordNet Library, 2013. Java API for Accessing the WordNet Dictionary, Avail-1162

able online at http://sourceforge.net/projects/jwordnet (accessed 06.02.13).1163

JHotDraw, 2013. JHotDraw as Open-Source Project, Available online at1164

http://www.jhotdraw.org/ (accessed 06.02.13).1165

Keller, G., Teufel, T., 1998. SAP/R3 Process Oriented Implementation. Addison1166

Wesley-Longman, Reading, MA.1167

Ko, A.J., et al., 2011. The state of the art in end-user software engineering. ACM1168

Comput. Surv., 1–61.

Lieberman, H., et al., 2006. End-user development: an emerging paradigm. In: Lieber- 1169

man, H., Paternó, F., Wulf, V. (Eds.), End-user Development. Kluwer/Springer, 1170

Amsterdam. 1171

Markus, P., Fromherz, J., 1994. Software Development Based on Executable Specifica- 1172

tions and Transformations (Technical Report). Department of Computer Science, 1173

University of Zurich. 1174

Mellor, S., Balcer, M., 2002. Executable UML: A Foundation for Model Driven Archi- 1175

tecture. Addison-Wesley, Reading, MA. 1176

Myers, B.A., Pane, J.F., Ko, A., 2004. Natural programming languages and environ- 1177

ments. Commun. ACM, 47–52. 1178

Neighbors, J., 1984. The Draco approach to constructing software from reusable 1179

components. IEEE Trans. Softw. Eng., 564–574. 1180

Newman, M.W., et al., 2003. DENIM: an informal web site design tool inspired by 1181

observations of practice. Hum. Comput. Interact., 259–324. 1182

Pane, J.F., Myers, B.A., 2006. More natural programming languages and environ- 1183

ments. In: Lieberman, H., Paternó, F., Wulf, V. (Eds.), End-user Development. 1184

Kluwer/Springer, Amsterdam. 1185

Paternò, F., Santoro, C., Spano, L.D., 2011. Engineering the authoring of usable service 1186

front ends. J. Syst. Softw. 84 (10), 1806–1822. 1187

Pipek, V., Kahler, H., 2006. Supporting collaborative tailoring. In: Lieberman, H., 1188

Paternó, F., Wulf, V. (Eds.), End-user Development. Kluwer/Springer, Amster- 1189

dam, pp. 315–345. 1190

Repenning, A., Ioannidou, A., 2004. Agent based end user development. Commun. 1191

ACM, 43–46. 1192

Seffah, A., Ashraf, G., 2007. Model based user interface engineering with design 1193

patterns. J. Syst. Softw. 80 (8), 1408–1422. 1194

Smith, D., 1990. KIDS: a semi-automatic program development system. IEEE Trans. Q71195

Softw. Eng.. 1196

Smith, D., Cypher, A., Tesler, L., 2000. Programming by example: novice program- 1197

ming comes of age. Commun. ACM, 75–81. 1198

Stav, E., Floch, J., Khan, M.U., Sætre, R.,2013. Using meta-modelling for construction 1199

of an end-user development framework. In: End-user Development, LNCS, vol. 1200

7897. Springer, Berlin, pp. 72–87. 1201

Sutcliffe, A.G., 2002. The Domain Theory: Patterns for Knowledge and Software 1202

Reuse. Lawrence Erlbaum Associates, Mahwah, NJ. 1203

Sutcliffe, A.G., Maiden, N.A.M., 1998. The domain theory for requirements engineer- 1204

ing. IEEE Trans. Softw. Eng., 174–196. 1205

Sutcliffe, A.G., Papamargaritis, G., Zhao, L., 2006. Comparing requirements analy- 1206

sis methods for developing reusable component libraries. J. Syst. Softw. 79 (2), 1207

273–289. 1208

Sutcliffe, A.G., 2008. The socio-economics of software architecture. Autom. Softw. 1209

Eng. 15, 343–363. 1210

Sutcliffe, A.G., 2014. An architecture framework for self-aware adaptive systems. Q81211

In: Mistrík, I., Bahsoon, R., Kazman, R., Sullivan, E., Zhang, Y. (Eds.), Economics- 1212

Driven Software Architecture (EDSA). Elsevier. 1213

Thew, S., Sutcliffe, A.G., Procter, R., De Bruijn, O., McNaught, J., Venters, C., Buchan, 1214

I., 2009. Requirements engineering for e-science: experiences in epidemiology. 1215

IEEE Softw. 26 (1), 80–87. 1216

University of Lancaster, 2005. The Lancaster (Paice-Husk) Stemming Algo- 1217

rithm, Available online at http://www.comp.lancs.ac.uk/computing/research/ 1218

stemming/ (accessed 06.02.13). 1219

Yoshida, M., Iwane, N., Matsubara, Y., 2004. The integrated software product line 1220

model. In: Proc. Conf. on Cybernetics and Intelligent Systems, vol. 1, Los Alamitos, 1221

CA. IEEE Computer Society Press, pp. 538–543. 1222

Zhisheng, H., et al., 2002. Unified approach for system-level generative program- 1223

ming. In: Proc. 5th International Conference on Algorithms and Architectures 1224

for Parallel Processing, pp. 136–142. 1225

Alistair Sutcliffe retired in October 2011 from the University of Manchester, where 1226

he is now Emeritus professor. However, he continues his research as a visiting 1227

professor at University College London and the University of Lancaster. He has 1228

been principle investigator on numerous EPSRC and European Union projects. 1229

His research interests in HCI are theory and models of user experience, inter- 1230

action design, social media, and design of complex socio-technical systems. In 1231

software engineering he specialises in requirements engineering methods and tools, 1232

scenario-based design, and theories of domain knowledge. He has over 250 publi- 1233

cations including five books and was awarded the IFIP Silver Core in 2000. 1234

George Papamargaritis gained his PhD on domain modelling for software archi- 1235

tecture development from the University of Manchester Institute of Science and 1236

Technology in 2007. He worked as a software engineer for British Telecom in the 1237

UK from 2000 to 2006, when he moved to Greece to take up his current position as 1238

software architect at Intracom IT Services in Athens. 1239