Adaptive Data Collection Front-End - ADaFE

(1)

F

ACULDADE DE

E

NGENHARIA DA

U

NIVERSIDADE DO

P

ORTO

Adaptive Data Collection FrontEnd

-ADaFE

Rui Júnio de Matos e Silva

Mestrado Integrado em Engenharia Eletrotécnica e de Computadores Supervisor: Luís Filipe Pinto de Almeida Teixeira

Second Supervisor: Pedro Arlindo Vieira Madureira

(2)

(3)

Abstract

When companies deploy applications whether through app stores or directly on their devices, they often times tend to think that the bulk of the work is done. However seldom is that the case since the maintenance of an application can take up as much time and effort through time as the development. Blaming ever-changing requirements and unexpected workflow deviations, the Software Engineering (SE) field is yet to find a consistent method of coping with such maintenance issues.

But if the awareness that project guidelines can be altered in the blink of an eye exists, why not build software in a way that is inherently already prepared to adapt? The Agile trend that has

been on the rise in the last decade or so ([1]) is trying to set a new tone; one that breaks with the

rigidity from the past and gives project management an exit to adapt quickly.

New problems are unfolding with that approach, though. Whereas the common object models in which SE stands were a perfect match for regular practices, they too are posing constraints on the speed with which one can change a system. What ADaFE proposes to do is build on a different type of system modeling, namely an AOM - Adaptive Object Modeling, minding the caveats posed by mobile design.

AOM can be thought of as a software design pattern made up of a bunch of smaller patterns directed towards creating adaptable systems. It requires modeling with an added layer of abstrac-tion, dividing the models into a knowledge (meta) level and an operational one closer to what software engineers are used to. The necessity to predict changes and apply metaprogramming brings some complexity to AOM-based systems. Adding that to the fact that a lot of developers are more coders than modelers (especially in the mobile world) tends to drive them away from such architectures.

ADaFE wants to change that paradigm. It intends to show how it is possible to allow even a non technical manager to alter front-ends and reflect those changes automatically at runtime, something especially useful in data collection where the fields presented to the end-user may need to vary a great deal. It aims at being a generic framework from which eventually any application can grow adaptive.

Based on an AOM model, a Ruby on Rails web platform was created where one can input the case-specific entities, properties and so on that make up the system. These are then provided access to via an API. The second key of ADaFE is an Android library that consumes that API and stores its data in an appropriate model so as to ease the ’plugging’ of the platform into a running Android application.

Two case-studies validate the utility of the framework. The first one produced an Android app (whose theme is questionnaires) that evinces how useful the ADaFE tool can be in reducing maintenance and change time and cost. It connects to an adaptation of the web platform so that it would be more user-friendly in handling this specific scenario. The second one represents the turning of a regular running app into an adaptive one by insetting the ADaFE components on it.

(4)

(5)

Resumo

Quando uma empresa lança uma aplicação móvel, quer seja pelas lojas de aplicações ou directa-mente nos seus próprios dispositivos, pensa-se frequentedirecta-mente que o trabalho está todo feito. No entanto raramente é esse o caso já que a manutenção de uma aplicação pode exigir tanto tempo e esforço ao longo do tempo como o desenvolvimento. Culpando as constantes mudanças de requi-sitos e desvios no processo de trabalho inesperados, o ramo da Engenharia de Software (ES) ainda procura um método consistente de lidar com os tais problemas de manutenção.

Mas se a noção de que as directrizes de projecto podem ser alteradas num piscar de olhos existe, por que não construir software já preparado de raiz para se adaptar? A tendência Agile que

tem aparecido na última década ([1]) está a tentar mudar a configuração; para uma que quebre a

rigidez do passado e dê à gestão de projectos uma alternativa para se adaptar rapidamente. No entanto novos problemas surgem com essa abordagem. Enquanto os modelos de objectos comuns nos quais a ES se baseia eram a combinação perfeita para as práticas habituais, também eles colocam restrições à velocidade com que se consegue mudar um sistema. O que o ADaFE se propõe a fazer é trabalhar sobre um tipo diferente de modelação de sistemas, designado AOM -Adaptive Object Modeling, tendo em consideração as restrições impostas pelo design para móveis. AOM pode ser considerado um padrão de projecto de software constituído por uma série de padrões mais pequenos direccionados para criar sistemas adaptáveis. Requere a modelação com um nível de abstracção adicional, dividindo os modelos num nível de conhecimento (meta) e outro operacional mais próximo do que os engenheiros de software estão habituados. A necessidade de prever mudanças e aplicar metaprogramação traz alguma complexidade aos sistemas baseados em AOM. Somando isso ao facto de que muitos engenheiros são mais programadores que mode-ladores (especialmente nos mundo dos aparelhos móveis) tende a afastá-los de tais arquitecturas.

O ADaFE quer mudar esse paradigma. Pretende mostrar como é possível permitir mesmo a um gestor não técnico mudar front-ends e reflectir essas mudanças automaticamente em execução, algo especialmente útil em recolha de dados onde os campos apresentados ao utilizador final podem variar imenso. Visa ser uma estrutura genérica a partir da qual eventualmente qualquer aplicação se pode tornar adaptável.

Com base num modelo AOM foi criada uma plataforma web em Ruby on Rails onde se podem inserir entidades, propriedades e outros componentes específicos de cada caso que compõem o sistema. Depois é providenciado acesso a esses dados através de uma API. A segunda peça-chave do ADaFE é uma biblioteca para Android que consome a API e guarda os dados num modelo apropriado de maneira a facilitar a inserção da plataforma numa aplicação de Android já existente. Dois casos de estudo validam a utilidade da estrutura. O primeiro produziu uma aplicação Android (cujo tema é questionários) que evidencia quão útil o ADaFE pode ser em reduzir tempo e custo de manutenção e mudança. Ela conecta-se a uma adaptação da plataforma web para que se tornasse mais agradável para o utilizador de utilizar nesse cenário em concreto. O segundo repre-senta a transformação de uma app em execução numa mais adaptável por recurso aos componentes ADaFE.

(6)

(7)

Agradecimentos

Gostaria de começar por agradecer aos meus orientadores Pedro Madureira e Luís Teixeira, bem como ao professor Ademar Aguiar e ao senhor Joseph Yoder, pelas dicas e conselhos que me ajudaram a concretizar este projecto. E pronto, era só isto (Haha já pensavam que isto eram uns agradecimentos normais, não? Não na tese do Mister Júnio).

Admito que não percebo bem porque é que as pessoas se põem a agradecer à família, amigos e por aí fora neste documento. Apesar dele representar o culminar de 5 anos de trabalho, alegrias, sacrifícios, festas, muita responsabilidade e javardice em pesos equilibrados, essas pessoas em nada contribuíram directamente para a escrita, antes pelo contrário, representaram distracções da mesma. Assim sendo, aqui fica a lista de pessoas a quem eu não quero agradecer:

• Aos meus pais, que nos seus estilos completamente opostos são e sempre foram um modelo exemplar de educação (apesar de tudo três filhos fantásticos dificilmente podem ser obra do acaso);

• Aos meus irmãos, que não sabem (e provavelmente nunca vão saber porque o mais certo é não lerem isto) que é difícil estar tanto tempo longe deles e que as conversas no Skype ao longo destes meses foram dos momentos que mais me aqueceram o coração;

• Aos meus amigos do futebol e crossfit, que aturaram frequentemente a libertação das minhas frustrações, disfarçada de maluquice e traços de esquizofrenismo;

• Aos meus amigos do chat da casa, que me proporcionaram uma quantidade tão grande de gargalhadas e disparates que vai ser impossível esquecer (alguns por muito que queira) e a quem peço que guardem para sempre só para eles aquelas coisas que provavelmente nos podem levar presos;

• Aos meus amigos da Maia, que são aqueles mais importantes de todos e que deixam buracos na alma quando o Júnio parte nas suas demandas pelo mundo;

• Aos meus amigos da faculdade, de Erasmus, do estágio em Bruxelas e todos os outros que em muito contribuíram para as minhas vivências diárias que também ajudaram a moldar aquilo que eu sou hoje.

No fundo acho que o que este #sentimentalJúnioStrikesAgain quer dizer é que apesar de não terem contribuído directamente para esta tese, agradeço muito a estas pessoas porque contribuíram indirectamente pela forma como todos os dias mudam a minha visão do mundo.

Correndo o risco de parecer egoísta destaco por fim a minha própria força, que na escrita destes agradecimentos só permitiu a soltura de duas a três lágrimas (de cada vez).

Mister Júnio

(8)

(9)

“You only live once, but if you do it right, once is enough.”

Mae West

“Don’t count the days, make the days count.”

Muhammad Ali

(10)

(11)

List of Figures

1.1 Buddy chatting platform model. . . 3

1.2 TypeSquaredesign pattern. . . 4

2.1 TypeObjectdesign pattern. . . 9

2.2 Propertydesign pattern. . . 9

2.3 Dynamic Relationsdesign pattern. . . 10

2.4 Strategydesign pattern. . . 11

2.5 Presentation patterns overview. . . 12

2.6 PropertyRendererdesign pattern. . . 13

2.7 EntityViewdesign pattern. . . 13

2.8 Entity-GroupViewdesign pattern. . . 14

2.9 Builderdesign pattern. . . 15

3.1 Meta models mechanism. . . 23

3.2 Car management system example. . . 25

3.3 One option for the car management system with AOM. . . 25

3.4 Another option for the system with AOM. . . 26

3.5 Knowledge and operational layers. . . 26

3.6 Diagram of the solution. . . 30

4.1 System architecture model. . . 32

4.2 Knowledge-Operational levels separation. . . 33

4.3 Login screen. . . 36

4.4 Index of type classes. . . 36

4.5 Index of concrete classes. . . 37

4.6 Page for adding a new property-type. . . 38

4.7 Page for adding a new relation-type. . . 38

4.8 Page for adding a new property. . . 39

4.9 Page for adding a new operation. . . 39

4.10 Property-type page. . . 40

4.11 XML API. . . 41

4.12 Sample app index. . . 44

4.13 Sample app entity-types. . . 45

4.14 Sample app entity-type example. . . 45

5.2 Questionnaires main screen. . . 49

5.3 Screen for adding a new questionnaire. . . 50

5.4 Questionnaire page. . . 51

(14)

5.5 Interface for adding a new task. . . 52

5.6 Task page. . . 52

5.7 Option page. . . 53

5.8 Screen for editing a group of answers. . . 53

5.9 One way of updating group of answers. . . 54

5.10 Another way of updating group of answers. . . 54

5.11 Users index screen. . . 54

5.13 Questionnaires main screen. . . 56

5.14 Questionnaire introduction. . . 56

5.15 Questionnaire instructions. . . 57

5.16 One task questionnaire. . . 58

5.17 Application menu. . . 58

5.18 Questionnaire with two tasks. . . 59

5.19 Questionnaire with two tasks. . . 59

5.20 Questionnaire with three tasks. . . 60

5.21 Final result screen. . . 60

5.22 Push notification. . . 62

5.23 CouchDB result example. . . 63

5.24 Results index by questionnaire. . . 63

5.25 Results index by date and user. . . 64

5.26 Result from a questionnaire. . . 64

5.27 Questionnaire with three tasks partial screen. . . 65

5.28 Flowchart of the Questionnaires Application with ADaFE usage. . . 66

5.29 Communities screen. . . 67

5.30 Terrain information possibilities. . . 68

5.31 Initial web page. . . 69

5.32 Page for adding a Community entity-type. . . 69

5.33 Community constructor Java code. . . 70

5.34 Java code for adding communities in the SS app. . . 70

5.35 Page for adding a Province property-type. . . 71

5.36 Page for adding a Community entity. . . 71

5.37 Page for adding a Province property. . . 72

5.38 New Java code for adding communities. . . 72

5.39 Communities updated screen. . . 72

5.40 Initial hardcoded factors layout code. . . 73

5.41 Java code for responding to a factor selection in the SS app. . . 73

5.42 “TerrainInfo” entity-type page. . . 74

5.43 “Description” property-type page. . . 75

5.44 New Java code for adding environmental factors. . . 75

5.45 Updated terrain information possibilities. . . 76

(15)

Abbreviations and Symbols

AJAX Asynchronous JavaScript And XML

AOM Adaptive Object Model(ing)

API Application Programming Interface

APP Application

CORBA Common Object Request Broker Architecture

CRUD Create, Read, Update and Delete

DB Database

EBNF Extended Backus–Naur Form

GCM Google Cloud Management

GPS Global Positioning System

HCI Human-Computer Interaction

HTTP Hypertext Transfer Protocol

IP Internet Protocol

JSON JavaScript Object Notation

MOF Meta-Object Facility

MVC Model-View-Controller

OMG Object Management Group

PoC Proof of Concept

R&D Research And Development

RDBMS Relational Database Management System

RoR Ruby on Rails

SAX Simple API for XML

SDK Software Development Kit

SE Software Engineering

SS Syndromic Surveillance

UI User Interface

UML Unified Modeling Language

URL Uniform Resource Locator

UX User Experience

XML Extensible Markup Language

XPath XML Path Language

(16)

(17)

Chapter 1

Introduction

The software development industry, as recent as it may be in comparison to other ancient activities, has seen quite some change over time. After a maturation period where astonishment slowly gave place to eagerness, the application boom we are witnessing today brings about the danger of uncontrolled development, one that more and more frequently fails to live up to the quality standards the users expect.

A new age begs for fresh tactics. Old methods are no longer able to contain the rapidly increas-ing demand for quickly adaptincreas-ing application businesses. The software world has already realized that and is changing its practices, mainly in the project management level with the so-called Agile movement. However, on a lower level, system design has still to find a way of accompanying that pattern. The regular rigid object models are starting to denote some inability to deal with such fast moving parts of the businesses they represent.

Adaptive Object Modeling (AOM) is possibly the only apparent solution so far. It takes a step away from the usual object models and tries to see them through a perspective with one added abstraction layer. Instead of coding system entities and properties, it focuses on types: entity types, property types and so on. This empowers an application (app) with more knowledge about itself leading to a meta-programming style.

Web applications have slowly started to set the tone for AOM but in current times the mobile industry is asking for it as well. There other considerations come into play because Human-Computer Interaction (HCI) grows even more relevant as device sizes shrink.

This chapter contains a first approach to the theme, an explanation of where the problem arose from, why it is important to produce work in the field and what kind of results are expected at the end of the project.

1.1 Context

Nowadays, in many fields related to technology, “application” has become a trendy term. Since the Internet took over, well, most of the world, “web application” has been used more and more often to refer to websites. And the rise in mobile development is a clear sign that apps are here to stay.

(18)

It becomes important to notice that an app is much more than a mere utilitarian or entertainment tool. Applications are more usually a means for companies to contact their target users.

Usually as good as a company might be, it will only be as successful as it can appeal to its clients. The use of applications follows this pattern; it allows their owner not only to approach users directly through a tangible communication line but also to receive their feedback, making them feel like their needs are taken into account and consequently upgrading their regard of the brand.

1.1.1 Changing Business Models

By creating applications companies are opening doors. They are not only more open to communi-cation but also letting some of their characteristics show. Their visual identity (the so-called “look and feel”), their values, but more importantly their system’s conduct. That is the main point here: an application is basically a product which reflects the business rules of a company.

Now, these business rules do not just magically translate into an application. Before an appli-cation is created whole (frequently very complex) diagrams are built that use entities, attributes and relationships to describe the system’s functioning. These diagrams are based on use cases and intend to show an overview of the possibilities the application will offer. They fare from small

descriptions to intricate models. Figure 1.1 presents an example of a diagram that displays the

modeling of a management platform for chatting between buddies.

From models such as this one applications can be derived. The team of developers would take the model and implement it (code it) with their favorite programming language (e.g. Java) so it would become an actual program running for instance on a web browser. This is a rough sketch of the typical process.

Now assume the company which owns this full-fledged program is changing its business rules slightly. The directors have decided that they want not only Twitter, ICQ and Jabber but also Whatsapp users to be integrated in the platform. This does not sound like a big deal but the team of developers would have to build the new model and code the new classes and interactions, and a new version of the application would have to be released.

It is not hard to imagine that for more complicated and bigger scale real-life examples things can get pretty troublesome, especially since today the world of business changes rapidly and clients urge for faster and faster adaptation from their suppliers. One could try to predict future needs and “hide” as many entities as possible behind options but that would be a non-solution, an inefficient way to cover most cases that could eventually end up unpredictably bloating the system.

This is especially a problem in data collection applications. When one tries to create some kind of questionnaire to gather a lot of users’ responses, the method is usually to formulate questions that assess as many common aspects between the people answering as possible. However, if there is even a small change in the scope of the problem that the application owner is evaluating, different questions need to be made, hence a sort of “new” application needs to be deployed.

(19)

1.2 Motivation 3

Figure 1.1: Buddy chatting platform model.

1.2 Motivation

As seen in Section1.1the fundamental problem is that after some kind of application is installed

and provided to end users, plenty of times the business rules behind it suffer changes. Not seldom there is a shift in the scope of interaction the owner wants to have with the user or, in general, a change in the topology of the system’s model.

The solution proposed in this project is based on Adaptive Object Modeling. This is a tech-nique that makes use of several design patterns - methods for developing software that are applied in habitual cases and regarded as good practice in many situations - to let the model of the system change in accordance to the user’s input. Instead of implementing predefined entities, entity types are defined. Instead of having properties as an attribute they become an entity themselves, which can in turn have different user-defined property types. This is already the translation of a design

pattern called TypeSquare, the basis of Adaptive Object Modeling. Figure1.2shows its graphical

representation.

In addition to this basic setting, associations to rules with various levels of complexity can be added. However, it is not possible to code these EntityType and PropertyType classes in a classical way, for the goal is that they are instantiated and changed at runtime by the user. This is in fact implemented through descriptions that are implanted on the application’s metadata. Those

(20)

Figure 1.2: TypeSquare design pattern.

descriptions may be stored for example in an external database and describe how new types of entities or properties are generated. They take advantage of similarities and redundancy in the original classes to create a logic behind them. Rather than a predictive one that maps all the possibilities, an intuitive one that lets the user in control of the application add and remove new types as he pleases.

Let us picture the case where a company is sending a team of investigators to study the causes and effects of say malaria in Sudan. They are providing them with an application whose goal is to address the population’s habits and social factors that may lead to the spreading of the disease. If they model the factors they want to know more about as static entities, the investigators will be forced to choose questions from a pool of predefined categories. Of course they can report back that they need this or that other characteristic and the developers can then add them but that is terribly impractical, slow and prone to errors. And what happens when the company has another team study malaria in Mozambique, which has a completely different environment? They would need to start from scratch.

If, on the other hand, the developers go for an adaptive solution, everything becomes simpler for the investigators. They can pick the types of measures that they deem relevant, that better suit the specific situation and in that way manage the questions to put to their target population better. On top of it the company ends up with an application that can easily be adapted by their own business managers to work on virtually anywhere and for any kind of setting or disease.

Some systems like this are already in place and owners claim that they are beautiful designs. The only drawback seems to be the involved complexity, given that there are not many software engineers that can grasp this type of architecture and do not even consider investing in it, preferring regular implementations and hoping for the best.

Investigation in the field is important for two main reasons. First, the more different ap-proaches are taken at it, the easier it becomes to disseminate the solution, which is all about good programming and system design practices. Second, there have not been many attempts able to successfully maintain attractive interfaces after standardizing the process. This is because a

(21)

sub-1.3 Place of Work 5

liminal problem appears when going for this design, that is one related to the connection between the model and the graphical user interface. Interface fragments also need to support implementa-tion of different types so that they fit in the new modular entity definiimplementa-tion.

1.2.1 Agile Trend

In order to cope with the steady rise in the need for flexibility that companies around the world are evincing, new methodologies have surged that aim at harnessing the cost and time of change. The last decade’s trend in software development (and applied more and more to other business areas)

is Agile ([1]).

Agile is not exactly a methodology, it is more of a movement that seeks alternatives to

tradi-tional project management and software development ([2]). One could say it represents the utmost

opposite to the early days’ waterfall cycle. Instead of producing an initial schedule with the goal of carrying it out straight on and making merely small adjustments along the way, Agile ways (e.g. Scrum) try to minimize the cost of change by assuming that errors will probably often happen and working with a plan of short iterations that is already prepared for handling them.

Facing towards practical project implementation aspects, this is something which can greatly benefit from AOM chiming in. While Scrum may be a tremendously advantageous tool on the management side of things, AOM can become just as useful in model design thinking.

Let us take the example from subsection1.1.1and say that the company launching the buddy

chatting platform was able to transmit to the team of developers that things such as which user platforms should be supported would be open to extension or adaptation. That would not normally influence the system model design. However with AOM certain modeling practices can be put in place to account for that adaptation prediction.

After all, if it seems obvious that a system will inevitably need to drift at least a little bit from its original specifications so that it will always be incomplete by design, why not account for that in an early stage and design for its incompleteness?

1.3 Place of Work

As a final introductory note it is important to mention the institution where the ADaFE project was developed and that is referenced henceforth. It is Associação Fraunhofer Portugal Research (Fraunhofer Portugal), a non-for-profit association founded by Fraunhofer-Gesellschaft, the biggest organization of applied research in Europe. More specifically the investigation center Fraunhofer Portugal Research Center for Assistive Information and Communication Solutions (Fraunhofer AICOS).

(22)

(23)

Chapter 2

Bibliography revision

Quite some relevant work has already been developed on the AOM topic. Interest arose around the turn of the millennium, strongly driven forward by Joseph W. Yoder who, together with Ralph

Johnson, published several papers (e.g. [3], [4]) delving deep into the architecture and patterns

used for AOM development. This set an important underlying working layer and served as a motto for further research.

Later, people such as Léon Welicki and Rebecca Wirfs-Brock “tagged in” and carried the

studies onto a more “rendering” perspective (e.g. [5], [6]), exploring more patterns useful in the

presentation aspect of an AOM system.

Human-Computer Interaction is a trickier area of study. In the last decade it garnered a lot of focus with the explosion in web development but the turn to mobile has shifted research on the topic to different concepts. Today it is more common to hear the term User Experience. Nevertheless, it is important to understand what challenges have unfolded for HCI in this mobile transition and how can they be harnessed so that the conjugation with AOM is possible. Articles

[7] and [8] are of help in this matter.

This bibliography revision presents the state of the art in what relates to AOM. The themes treated in the works introduced above will be explored two by two, segregated in the following sub-topics: AOM Architecture; Rendering Patters; Mobile HCI.

Over the past few years a lot more people have been taking an interest in this kind of system. Some of the most active are based in Porto, which raises special attention with respect to this project. Papers from Hugo Sereno Ferreira, Filipe Figueiredo Correia and Ademar Aguiar (e.g.

[9], [10]) have contributed to a broader awareness in planning and designing AOM systems.

2.1 AOM Architecture

By the year 2000 what is nowadays generally accepted as the AOM style had a lot of surrogate names: “Active Object Model”, “Dynamic Object Model” or even “User Defined Product”. All these names meant to convey the idea that an information system or a business product shall not be stiff, but rather quickly adjustable to the business needs. As will be seen shortly in fact AOM

(24)

has got all those names covered. The paradigm that AOM follows in order to accomplish such flexibility is what clearly makes it stand out and break with traditional approaches.

AOM is a reflexive architecture in the way that it represents classes, attributes, relationships,

and behavior as metadata [3]. Instead of having programmers code the entities of the system, that

“code” is derived from descriptions stored for instance in an external database. Changes to that database, to those descriptions, are accessible for the typical user because they are closer to natural language and can be depicted through simple interfaces. The delay from program re-building to re-installation is virtually erased since the system is able to interpret the change in the descriptions and react accordingly. Therefore business rules can be altered on the fly (hence the “Active Object Model”).

A typical programmer is not used to this level of abstraction. The mechanisms that have to be put in place so that the system is able to interpret the (new) rules that dictate its behavior are in a way detached from the coding itself. It is more about designing the model to perfection than actually finding ways to execute it correctly. Instead of implementing the entities and relationships that characterize a business model, one wants to “teach” that business model to our platforms in order to make them just as dynamic as the owner’s decisions (hence the “Dynamic Object Model”).

Due to the higher abstraction, an AOM system is not easy to get up and running. However, the big advantages can be felt once it is in place, because the developer’s work is very limited from then on. Everything gets placed on the manager’s plate, allowing him to fully control the fate of the product (hence the “User Defined Product”). The business decisions are left for whomever really understands them, and the product is able to follow along.

The actual AOM architecture can be thought of as a single complex design pattern, a compi-lation of good practices leading to a very easily manageable program. Yet it is usually regarded as based on a list of smaller and more or less well-known design patterns. Some insight on the fundamental ones and the way in which the whole architecture is sustained follows.

2.1.1 TypeObject

TypeObjectis possibly the most vital pattern for AOM topologies. It is common in object modeling

for classes that belong to a certain type to be defined as subclasses of a general one, with as many subclasses appearing as there are different entities in the domain. TypeObject allows the creation

of those predefined classes through instantiation at runtime, as implicit in Figure2.1.

Objects will belong to classes that represent types instead of single regular classes. For in-stance, if there was a class “Car” with subclasses “Caravan”, “Camry”, and “Explorer”, that would be translated into a “CarType” class that would specify the type attributes and some common op-erations and a single “Car” with the specific behavior that each car object will assume. This is

(25)

2.1 AOM Architecture 9

Figure 2.1: TypeObject design pattern.

2.1.2 Property

Another basic concept in object modeling is the concept of property. Properties are usually attributes of an object because each object is related to a class. However since in AOM different objects can be mapped on the same entity there is the need to withdraw the properties onto a “dictionary”, a different entity associated to the main class with a given multiplicity, as shown in

Figure2.2. This way properties can also be attributed dynamically, in what is called the Property

pattern.

Figure 2.2: Property design pattern.

Most of the times TypeObject is then applied to properties themselves, resulting in the

Type-Squarepattern that was introduced in Section1.2. The same way that entities are materialized in

entity types, properties are materialized in property types. Entity types have property types and the concrete entities can then specify which concrete properties they possess from those types.

2.1.3 Entity-Relationship

Relationships are normally two-way bindings between entities. There are three ways in which they can be implemented in an AOM system. First, the Property pattern can be applied a second time for associations. As a second option Property can be split into two subclasses, one for at-tributes and another for associations, in which case the latter know their cardinality (also called Accountability). Finally relationships can be set apart from properties through a Value class which would hold the “normal” (numerical, textual or other) values for attributes and the other entity for associations.

In 2010 a group of Brazilian researchers has come up with an innovative way of modeling

relationships: the Dynamic Relations Pattern ([11]). The idea behind this design pattern (modeled

in Figure2.3) is to hold more information about the relationships, making them more dynamic in

(26)

TypeObjectpattern is applied to relations, control is delegated to the concrete relationships put up at runtime.

Figure 2.3: Dynamic Relations design pattern.

2.1.4 Strategy and RuleObjects

The last of the most important concepts in object modeling is behavior. Behavior is obtained through methods, which are operations that an object is able to perform. These are usually what is subject to restrictions or the so-called business rules. In order to enforce those rules, algorithms that can verify their integrity have to be attached to our class types.

The way in which this is done is through the Strategy pattern. As seen in Figure2.4, it provides

interfaces for sets of primary and/or composite rules that will be drawn from the user descriptions. More details are given later on but for now let us notice that composite rules are obtained via a Composite, and state that some more patterns will come into play for the system presentation design.

2.1.5 Interpreters of the Metadata

After the model has been developed, it needs to be able to read indications on how the system is supposed to operate and reflect those indications. The metadata that describes them is first interpreted when the objects are instantiated, and afterwards at runtime for employing the business rules. The information is usually stored in a database and read via Extensible Markup Language (XML) format but may take other shapes as long as patterns such as the Interpreter and the Builder are able to analyze it. From the moment the descriptions - and thus the metadata - change, the new model comes to life and those changes are transported immediately onto the running application.

(27)

2.2 Rendering Patters 11

Figure 2.4: Strategy design pattern.

2.1.6 User Interface for Defining Types

It is one of the goals of AOM to transfer a lot of the system control to the end users. In order to do so, interfaces have to be created for them to be able to engage. Given that they generally are not programming savvy and that rules can be hard to write, a special dedicated interface is required so that they can build those rules through a more visual language. If only programmers are responsible for maintaining the system they can probably do it resorting to their regular coding environment but it is still a good idea to put up a specialized User Interface (UI), in line with the AOM practices: spend more time in careful preparation so that the implementation comes easier.

2.1.7 About AOM

After this architectural overview, papers [3] and [4] present some examples of projects built based

on AOM. Those will not be discussed here for brevity but there is an important point that can be inferred from studying them. AOM is but a gathering of patterns that together are able to accomplish the deployment of rapidly-changing business rules to applications or other products. In no case does it constitute a framework for building the subjacent models, mainly because every case has its own specifications and requirements that can widely vary from one to another. So the work is still all on the developer’s side to create an adequate structure for his AOM system.

2.2 Rendering Patters

The patterns introduced in Section2.1are only a few of those which are frequently used in AOM.

There is a common structure that organizes AOM patterns into categories. The Core patterns, which represent the architecture kernel (e.g. TypeObject, Property). The Process patterns, which provide some guidelines and good practices for AOM’s design. The Presentation patterns, which worry about the interfaces of the system. The Creational patterns, which take care of the in-stantiation of the model into objects. The Behavioral patterns, used for altering the behavior and

(28)

enforcing rules (e.g. Strategy). And some Miscellaneous patterns, which focus on more non-functional aspects such as usage and control parameters.

This section presents the most relevant Presentation patterns based on [5] and the fundamental

Creational pattern, the Builder, based on [6]. Together these patterns allow for all the necessary

rendering, meaning that they are responsible for making the translation from the model constructed by the Core and Behavioral patterns to the actual platforms where the user interacts.

2.2.1 Presentation Patterns

After a developer comes up with an AOM, he needs to worry about how it will be presented to the end users. Presentation patterns help by being “plugged in” to the model entities. If correctly

applied they allow for a seamless visual representation of the whole model. Figure 2.5 shows

the basic Presentation patterns and the relation between them: entity views can coordinate several property renderers and entity group views can use both types. Each of the patterns is then analyzed in greater detail.

Figure 2.5: Presentation patterns overview.

2.2.1.1 PropertyRenderer

The PropertyRenderer is logically the first Presentation pattern because it is the most low-level

pattern of the three. From Figure2.6it can be seen that it is attached to properties: each property

will have a PropertyRenderer object which encapsulates its presentation code. When the objects of the system are instantiated the renderers of their properties are able to bring up the presentation of the object within the specific context. Renderers can be primitive or composite (through the

Compositepattern as usual) and they can be provided by a “factory” following the Factory pattern.

PropertyRendereris rarely used alone due to its extremely fine-grained nature, it is most of the

times coordinated by an EntityView as explained later. Although many renderers can be created according to presentation needs their small scale is very important since it promotes strong code isolation.

2.2.1.2 EntityView

Conjugating the use of several property renderers in a higher scale leads to the EntityView pattern. As the name indicates entity views are associated with entities much like property renderers are

(29)

2.2 Rendering Patters 13

Figure 2.6: PropertyRenderer design pattern.

with properties. Except that in this case the EntityView is context-aware which allows it to pick

suitable property renderers. Figure2.7shows how an EntityView (which again can be composite)

aggregates PropertyRenderer while being connected with the RenderingContext. Additionally constraints such as validation requirements can be placed on the views. These are however limited to the UI and should be used for client side verifications only as business rules are already taken care of in the core system design.

Figure 2.7: EntityView design pattern.

EntityViewis usually associated with UI fragments. Even though these can get quite complex

(30)

They are easy to maintain because they reside in a well-known location and have the plus of being reusable through applications, which is specially important if there is a need for keeping the same “look and feel”. The redundancy decrease is also a major advantage: single changes in the base code are automatically reflected everywhere they appear.

Some fragments are very common in application design (e.g. form entries, table rows) so that set of customary variants can be found in a lot of system interfaces. When the developer aims for a collection of those fragments such as a complete form or a complete table he falls into the

Entity-GroupViewpattern that will be presented next.

2.2.1.3 Entity-GroupView

Once one gets up to the highest abstraction level it becomes noticeable how the Entity-GroupView pattern reveals a Model-View-Controller (MVC) structure. This pattern describes a modular ap-proach in which the code generation for the presentation side is pulled into a view component that

processes all the entities. This decoupling (depicted in Figure2.8) eases the maintainability and

much enhances the modularity, making it almost as simple as a plugging in and out of views on the model whilst keeping the redundancy at check. The concrete group-view builders can either come up with a whole view or glue property renderers and/or entity views to build the interfaces.

Figure 2.8: Entity-GroupView design pattern.

Having explained how advantageous these patterns can be it needs to be said that one problem arises from their use. All the information needed for applying these methods still has to reach the system via metadata. The indirection caused by the transcription of the metadata can sometimes see a slowdown in performance hence one should strive to keep the complexity of the views as low as possible.

(31)

2.3 Mobile HCI 15

2.2.2 Creational Pattern - the Builder

The Builder is the fundamental Creational pattern. It is based on the premise that constructing a complex system like an AOM has to be done as a sequence of small steps instead of a huge one-time operation. So the model is not built at once; an interface takes the metadata and extracts steps based on each entitiy’s type and only then are the steps executed. On the other hand one does not want to have pieces of conditional code at every step so Builder also pays attention to maintainability and control issues in order to avoid bloating the development project.

But if different rules need to be applied for different entities how can the construction code be

encapsulated? Figure2.9shows the pattern model used to explain the process. An AOMBuilder

works as a turntable throughout. It starts by gathering entity data from the MetadataReader and passing it to BuildContext, responsible for setting the context for the step list that follows. That step list is created in BuildStepList usually by a Factory. Finally BuildStep is called from the

AOMBuilder and launches the series of steps (which can be defined in other packages) to be

executed. AOMBuilder then executes those steps in order and taking the context into account.

Figure 2.9: Builder design pattern.

One setback of this process is that there is no verification of the correctness at compile time because the pipeline depends on the metadata entries. Nevertheless Builder leads to single and well-known locations of encapsulated code that can quickly be changed, promoting maintainabil-ity.

Once the Presentation and Creation patterns are introduced in an AOM system based on

Type-Squareor other the developer should be able to obtain a concretion of the core model presented

with the programmed interfaces.

2.3 Mobile HCI

In a world that is turning to mobile, presentation regarding mobile devices becomes more and more important. This section presents some challenges that arose when this trend started and what kind of aspects should be taken into consideration when pondering solutions.

(32)

2.3.1 Challenges

[7] raised a compilation of challenges that affect design for mobile devices. The most common

problem in what has later become known as handheld devices is the small interface that is available to access larger and larger sets of resources and data.

Even though technology is evolving and upgrading pretty much every feature about smart-phones, some of the original questions remain valid. It is ordinary for audio systems not to present very good quality, which affects the way in which the application experience is perceived. Input techniques are very limited as there is no keyboard or mouse, everything being based on touch. Network access is often unsteady. And people are not always in the same position facing the gad-get (they may be lying down on their sides). All these things impact the way in which the users feel the product.

Even demographic topics such as the aging of the population and the spread of devices through all age groups, professions and ethnicities plays a part. The ideal interfaces would be such that satisfy all people’s requirements at all times. Since that is impracticable designers must weigh every challenge and aim to minimize their effects. Some of the main challenges are the following:

• Mobility: rapidly changing environments for the user holding the device;

• Population: large amounts of users that merely want to use gadgets without prior knowl-edge or teaching (self-learning interfaces);

• Input/output: limited screen size that refrains both the user’s actions and the system’s feedback;

• Context: interfaces can be modified by analyzing GPS and other sensors’ data;

• Multitasking: distracting information floats everywhere and task interruption is a constant. Again, these challenges are easily transported to the present as a definitive solution is unob-tainable. Once they are clearly identified and accounted for one can look into different approaches and extra factors to look upon.

2.3.2 Factors to look upon

As seen in Subsection 2.3.1 there is not much a developer or designer can do to fight off the

consequences of programming for mobile devices but to bear in mind the challenges and avoid blatant violations of the good practices normally followed to overcome them. By 2006 the mobile market was starting to establish itself and the design practices have not changed much over time. A lot of predictions that were made back then are actually being considered at this very moment.

Until recently the surge of handheld devices (mainly mobile phones) and wearables (e.g. smart watches) had driven the research to focus on the devices themselves. Smaller and smaller, smarter and smarter and more and more reliable devices are in order to meet customer demand. However soon people will probably get bored from the lack of innovation. Same as happened with desktops,

(33)

2.4 Other bibliography 17

external factors further than UI proper need to be considered. According to [8] those factors are

“(1) the overall aging of the population; (2) the increasing amount of personal computing done away from the desktop; (3) the increasing capabilities of ever-smaller devices; and, perhaps most importantly, (4) the convergence of computing capabilities onto the mobile phone”.

• (1): Aging brings about physical problems such as diminished visual acuity, loss of strength and coordination and joint pain. Strategies to overcome such problems may well end up improving the experience of even regular users.

• (2): Sunny weather asks for different interfaces than cold weather, for the reflections on the screen are different with sun and people tend to use gloves with cold. Usage while walking also needs investigating. This kind of problems can be compared to the physical issues in the previous bullet. By making use of sensor data (for instance knowing if the place is crowded or if the temperature is high or low) the system can adapt its parameters to better suit the situation.

• (3): New capabilities raise the need for a generalized input mechanism so that the user can follow the so-called “ubi-input”. He only needs to learn once how to interact with a mobile device to be able to interact with all of them.

• (4): The amazing growth in computational power opens new horizons where to benefit from technology. New possibilities arise for education and medicine, specially in underdeveloped countries where distribution of hand gadgets is much easier than desktops.

2.4 Other bibliography

The examples studied in Sections2.1 to2.3 examine the general topics around which the main

concepts of interest revolve. This section briefly summarizes the themes treated in several other articles and papers within the AOM and Mobile HCI areas, especially in the ways they differ from the above study. The works are addressed in chronological order.

2.4.1 AOM

• [12] and [13]

Aforementioned Ralph Johnson was one of the precursors of AOM. These two papers (which he took a part in) introduced the Dynamic Object Model pattern mentioned in

Sec-tion 2.1. It was one of the first models to account for types of entities instead of regular

classes, using the TypeSquare pattern as base structure. [12] went deeper into the workflow

dealt with when working with such a model while [13] focused on its advantages and

(34)

• [14]

In 2000 Joseph W. Yoder presented the idea of using metadata to convey to a system what functionality it should show without the need to (re)program it. He introduced the concepts of “metamodeling” to models built under that assumption and “end-user programming” to refer to the natural language driven style adopted by such systems.

• [15], [9] and [10]

A nucleus of people in Portugal have largely contributed for a novel approach to AOM. They have mainly reunited a lot of valuable information concerning good design practices, including system design guidelines that help prevent incompleteness and undesired com-plexity, among other topics around careful design of an AOM’s supporting structure.

[15] explains three design patterns on evolution rather than architectural issues: History,

Versioningand Migration. [9] takes a use case to investigate “integrity, runtime co-evolution,

persistency, user-interface generation, communication and concurrency”, basically setting

the scene for a complete AOM framework. And [10] provides a comprehensive theoretical

study of the state-of-the-art in AOM, adding a roadmap for empirical validation.

• [16] and [17]

These papers come a bit in line with the work produced by the people referred to in the previous point. Even in AOM systems carefully built there may be a need to adapt the archi-tectural structure after the output is deployed and running. In order to do this, some patterns

called evolution patterns need to be employed upon the initial design. [16] describes a

way in which that can be done, analyzing the evolution of an AOM system and what can be

done to respond to it. [17] comes up with two concrete patterns - Break and Correct and

Evolution Resilient Scripts- that enable the refinement of the AOM so as to ensure that its

core code does not change and, at the same time, that all entities are consistent with their definitions.

2.4.2 Mobile HCI

• [18]

Before mobile was even a big thing (as compared to the almost ubiquitous smartphone usage per person of today), people were already interested in investigating the challenges associated with mobile systems, whichever they might be, as far back as the early 90’s. This work presents some of the first investigated techniques to overcome display limitations.

• [19]

Most of the times, at least up until 2003, to study mobile HCI was to perform tests under

laboratory settings in a very empirical and subjective approach to research. [19] points out

several methods such as action research, case studies, field studies and basic research that should be used in order to standardized the research practice in mobile HCI.

(35)

2.4 Other bibliography 19

• [20]

[20] appears as a continuation of the previous entry. By 2005 some of the research

meth-ods proposed in [19] were already being applied. However the upgrade in complexity and

technology development lead to the need for an update on the framework that these methods were following. Only in that way a greater understanding of the on-the-rise use of mobile devices could be attained.

• [21]

This paper explores a different side of mobile HCI. It focuses on cognitive persistence and the paradigms used to scrutinize it. It not only hands out a very complete study of the several factors that influence cognition while using a device but it also provides a lot of practical data gathered in various experimental activities.

• [22]

By 2012 we were right in the middle of the mobile boom, with more and more people

paying attention to advances in the mobile area. [22] is an extensive collection of the most

important research methods to the date, centered mainly around the study of the context of use of a mobile application.

(36)

(37)

Chapter 3

Challenges and Goals

From the bibliography revision some conclusions can be drawn. AOM is already quite well-known, however it is still very seldom used given its complexity and level of abstraction. It just feels more comfortable for a developer to model in the regular old way and code using the same tactics as always. Furthermore the examples that are available have not really been too careful about the interface design, which maybe contributes to scare designers away from such a style of architecture.

There are yet several other forces that bestow a certain difficulty feeling to AOM. Metapro-gramming has never been highly regarded due to its complexity, the fact that regular developers do not fully comprehend what dynamic models are able to provide that static ones are not, the need to limit the scope of what may vary, among other limitations, tend to put a brake on progress in the area. If you add that to mobile design which can be a source of migraines on its own, the combination has the power to bring down any not fully committed developer.

On the other hand, only when one starts grasping the bare surface of AOM can he realize the technological potential it may unlock. Possibilities go far beyond what anyone has been able to reach so far. A sustained investment in adaptive systems and interfaces may very well overcome some obstacles posed by the sometimes overly utilitarian side of applications, onto a more generic framework. One that is able to fit any type of project on design level, similarly to what is happening with Agile methodologies (which are embraced by more and more types of business) on the project side.

This chapter aims at connecting the theoretical background provided by the state-of-the-art study with the actual project implementation of ADaFE. First an analysis of the common chal-lenges or forces that usually rise on this field of work is performed. Having those issues in mind, more concrete project objectives are crafted looking on forward to the development outcomes themselves.

(38)

3.1 Main Forces and Limitations

Before plunging onto software development it is always a good practice to invest time in carefully designing and modeling all the features of the product one wants to reach. That is even more the case with AOM-based systems, where, as has already been deepened, the design and base architecture play the major part of all results.

This section explores which features of AOM are more likely to pose constraints on the de-velopment, either by introducing complexity or merely putting the designer in front of decisive choices. A developer should weigh his options for each force with caution and keeping in mind that the goal is always to reach a compromise between how much or in what ways they affect the system and what value can they add to it.

3.1.1 Metaprogramming

It has already been established that AOM is rather complex. It takes a very different mindset to be able to get a handle of it, given how it completely changes the way a developer or designer looks at an object model. The main reason why that happens is the extra layer of abstraction one needs to grasp in order to fulfill an AOM system’s requirements. Instead of having a regular user-defined model, this type of system demands a meta model, one that contains information about his own components.

In object modeling not only one but more layers of abstraction can be considered. There is a

well-known set of levels that explains how the meta model mechanism works. Figure3.1 shows

those levels. Let us walk through them.

• Level M0 describes the actual objects that are created once a program is running. These may be cars, videos, plants, really any object of reality that the program is trying to represent. Thus M0 is the System level, the one that is closest to the real world.

• Level M1 is the one most developers and designers around the world are comfortable work-ing with. M1 is the Model level where classes are put up with their methods and properties

resorting to tools such as UML (e.g. Figure 1.1). Then that model is simply “translated”

into a program by coding the model with the developer’s preferred or the most suitable pro-gramming language such as Java for example. The level M0 diagram that then unfolds at runtime becomes an instance of this one.

• Level M2 is the focus of ADaFE and other adaptive solutions. It also makes use of UML but for describing a Model of a Model (so UML itself) rather than a simple model, hence

a meta model appears. As deepened previously in Section 2.1usually both methods and

properties become their own class. Like that, if one thinks further on how design patterns are successively applied to abstract the model entities onto descriptions that can be stored for later interpretation, what that is basically allowing is the construction of a language rather than a program given the flexibility to better handle the moving parts that is gained.

(39)

3.1 Main Forces and Limitations 23

Figure 3.1: Meta models mechanism.

Thus instead of a Java program, level M2’s output would be more like the very own Java language. The power to “toy around” with the system entities is deferred to the end-user,

as will be seen in subsection3.1.4. The “metaprogramming” this involves is what brings

complexity and one of the main challenges of working with AOM.

• Level M3 carries the knowledge boundary one step further. The Object Management Group (OMG), which is a consortium focused on developing and maintaining standards mostly for object-oriented systems, has a standard especially dedicated to ruling the kind of

model-driven engineering level M3 deals with: the Meta-Object Facility (MOF) ([23]). MOF

is a type system representing a Model of a Model of a Model (a meta meta model) able to “feed” CORBA (Common Object Request Broker Architecture), an architecture by the OMG which aims at enabling collaboration between systems built with different operating systems, hardware and even programming languages. Rather than a language we are talking about a language description such as EBNF (Extended Backus–Naur Form). This is an even more complicated schema that slips out of the scope of this project.

Again, AOM works at the M2 level. It points at a base meta model describing entities, prop-erties, methods and relationships as their own classes in order to delegate control of them (i.e.

(40)

definition of the real program) to a non-technical user. However, a direct consequence is that the meta model needs to have knowledge of the moving parts of the user model before the user

actu-ally starts changing them. Subsection3.1.2provides more insight on what is and is not possibly

changeable.

3.1.2 Predicting Changes

After reading Subsection3.1.1giddier minds may think that with meta modeling everything about

a system can be made mutable. So why not create a framework that grabs an existing object model and abstracts all its components up to a meta model level? In theory it should be possible.

However assuming the model has a significant size (as in quantity of entities and attributes) it becomes impractical and even unnecessary to do so seeing as the amount of information (as in number of classes) would outgrow the benefits of keeping and processing it. Plus trying to describe a model’s description means adding even one more abstraction layer which would make it fall into the M3 level. This subsection intends to show how it should work the other way around. Because there needs to be a meta model to be instantiated, what may change needs to be known by the system designer a priori. The usefulness of AOM resides in abstracting only the common parts of an application. At the bare minimum the types of entities, properties, operations and relationships present in the process need to be clearly understood and modeled before further development. Otherwise the project could eventually end up falling into the error of needing a

new entity of a type that was not there to begin with. Like the next subsection (Subsection3.1.3)

explains, the knowledge level must possess all the scope information so that the operational level is able to parse and handle it.

While it should be rather obvious that not any random custom change can be applied, the metamodeling technique may be misleading, hence it is better illustrated with a concrete example.

Take the model presented in Figure3.2, which represents an extremely simplified model for a car

management system.

Already from a model as simple as this one several AOM design options could take place (and even with the same design pattern), depending on the business needs. The most obvious one, before even contacting the business manager, would be to abstract the different types of cars

using the TypeObject pattern introduced in Subsection2.1.1. Like that, the result shown in Figure

3.3 would allow the manager to add or remove whatever types of cars he deemed necessary by

himself after the system was deployed, based on a CarType containing the common characteristics and behavior.

However, the situation could be very different. The company owner could eventually be very convinced that his lot of current car brands is not going to change. Instead, he wants to expand the business over to managing trucks as well as cars. In this case TypeObject could still be applied

but in a new way, as Figure3.4depicts. This new setting would allow new types of vehicles to be

defined by the client rather than new brands.

Of course the whole system could aggregate the two options. One could have a VehicleType, a

(41)

Figure 3.2: Car management system example.

Figure 3.3: One option for the car management system with AOM.

is one cannot alter everything, only what has been previously prepared by the system’s modeler. And to know what should be prepared can only be achieved by working together with a business manager, who understand the business on a deep level and can predict in which directions it may eventually glide.

In the Case-Studies chapter (Chapter5) one extra challenge will be seen. When the system

design is built from root it is ok to apply suggested changes prior to deployment, because the inter-face definition will stand on the model. On the other hand if an application is already running and one wants to turn it into a more adaptable one, there is much more work involved in understanding how the interfaces correlate with the model, so modifications are necessarily much more surgical.

(42)

Figure 3.4: Another option for the system with AOM.

3.1.3 Scope vs. Utility

Subsection3.1.2introduced how there are two very distinct levels when working with AOM

sys-tems. There is a more abstract level with respects to the modeler in which the types of elements the system will have are defined. And then there is another relative to the end-user where the

concrete elements from those types are materialized. Figure3.5summarizes the two layers under

consideration. Further on they are referred to as the “knowledge level” and the “operational level”.

Figure 3.5: Knowledge and operational layers.

(43)

(it is the meta one in a way). Types of entities, types of properties that those entity-types might possess and types of relations they may establish with one another are kept, usually in a database. Then there is a middle tier component: the operations. Although every operation is associ-ated to a certain EntityType, it will be the actual entities that perform the work, usually through predefined interfaces following a Strategy pattern.

And finally there is the operational level, the concrete components that will make up the run-ning program. Entities implement their general entity-type, adding their own specifications. Prop-erties relate to their property-type, gaining the given values at runtime. And relations are defined between entities on the fly, associated with the corresponding relation-type between entity-types.

Now, the two main layers translate a common duality present not only in adaptable systems but also in other Research And Development (R&D) areas. On one hand there is a constant need to broaden the scope of each project. The more generic one can be within a certain limit usually brings added value to the work because the applicability tends to have more targets in its range. On the contrary if one aims at creating tools that are so generic that they can comprise more and more cases there is the risk that utility is lost because there will always be specifics that cannot me mapped to the general use.

[24] explains how this flexibility vs. specialization is a common force regarding AOM. While

in other fields there is normally a well-defined scope with people working “inside” it, when de-signing an AOM (as seen in the previous subsection) the scope is basically defined by the designer himself. Thus he needs to be extra careful so as to find the right balance between how far wide among the “entity world” he wants to go and how useful will that really be for the system in practice.

3.1.4 End-User Control

One more challenge seems to drive developers away from AOM experiences. Whether they like to admit it or not they are usually much more interested / entertained in solving problems as they arise than in preventing them in early stages. It is a common pattern that the better one is as a technical programmer, the worse he is as a model designer. And that clashes with the AOM methodology, which sees a decrease in the role of the developer as a maintenance tool and regards him more as a careful preparation instrument. Code maintenance is virtually eliminated in favor of business rules maintenance, which are more effectively enacted by a business manager.

So after a program is up and running, control is passed onto the client side. Despite the small adjustments that are always needed, the bulk of the meta work is done prior to deployment.

Relating to Figure3.1, after an M2 model is set the M1 can be created as an instance of it; the user

model becomes an instance of the meta one. But how can the developer empower the manager with the ability to perform that instantiation?

He needs to create tools that are more user-friendly and transparently bear the facade between the knowledge level he crafted and the operational level that needs filling. Let us go back to the

example from Subsection3.1.2for illustration. The business people need not know what kind of