Академический Документы
Профессиональный Документы
Культура Документы
Adaptive Object-Modeling
Patterns, Tools and Applications
uUco ,osi sivio iovis iivviiv:
Decembei :o:o
Scientic Supeivision by
Ademai Aguiai, Assistant Piofessoi
Depaitment of Infoimatics Engineeiing
In paitial fulllment of iequiiements foi the degiee of
Doctor of Philosophy in Computer Science
by the
MAPi Joint Doctoial Piogiamme
Contact Information:
Hugo Seieno Feiieiia
Faculdade de Engenhaiia da Univeisidade do Poito
Depaitamento de Engenhaiia Infoimatica
Rua Di. Robeito Fiias, s/n
:oo-o, Poito
Poitugal
Tel.: +,,: :: ,o8 :oo
Fax.: +,,: :: ,o8 :o
Email: hugo.seieno(fe.up.pt
URL: http://www.fe.up.pt/ hugosf
Tis thesis was typeset on an Apple MacBook Pio iunning Mac OS X :o.o using the fiee L
A
T
E
X typesetting system, oiiginally developed by
Leslie Lampoit based on T
E
X cieated by Donald Knuth. Te body text is set in Minion Pio, a late Renaissance-eia type oiiginally designed
by Robeit Slimbach. Othei fonts include Sans and Typewiitei fiom the Computei Modein family, and Couiiei, a monospaced font oiiginally
designed by Howaid Kettlei at IBM and latei iediawn by Adiian Fiutigei. Typogiaphical decisions weie based on the iecommendations given
in Te Elements of Typographic Style by Robeit Biinghuist (:oo), and giaphical guidelines weie inspiied in Te Visual Display of Quantitative
Information by Edwaid Tufe (:oo:). Tis colophon has exactly one hundied and twenty-two (:::) woids, excluding all numbeis and symbols.
ISBN 978-989-96899-0-9
9 789899 689909
Adaptive Object-Modeling. Patterns, Tools and Applications
Copyiight mmvii mmxi by Hugo Seieno Feiieiia.
All iights aie ieseived.
Tis woik was paitially funded by ic1 and v:v:uicm:xis, s.:. as a doctoial scholaiship, ief. sivu/nui/,,:8/:oo8.
to Helena
Tis page was intentionally lef mostly blank.
Abstract
Te eldof Sofwaie Engineeiing (si) couldbe iegaidedas incrisis since the eaily days of its biith.
Pioject oveiiuns and failuies have hitheito chaiacteiized the norm, blamed upon the unreason-
able expectations set by the stakeholdeis and the constant change of the iequiiements. While
some development piocesses stiuggle to systematically eiadicate these barriers fiom sofwaie
development, othei methodologies, specially those coined agile, piomote a continuous embrace
of change as a ist-class piopeity of this activity. Even so, it is a yet to be disputed contingency
that theie is no silver bullet; no single, unifying methodology capable of consistently impioving
the eciency of sofwaie development by even an oidei of magnitude.
Nonetheless, the agglomeiation of empiiical evidence is now staiting to suggest that change,
moie than a meie cause, may be a symptom of a deepei natuie, diiectly ielated to inheient piop-
eities of some of the domains sofwaie tiies to addiess sofwaie may need to be undei constant
change because any modeling of those domains is incomplete since the day it staits.
Teiefoie, if such solutions need to be constantly evolving and adapted to newiealities, hence
iegaided as incomplete by design, shouldnt they be actively designed for incompleteness: If agile
methodologies shifed the way teams and individuals plan development to embrace change, how
should one delibeiately design to cope with continuous change:
Even if the answei to this question could be piomptly given, the goal of piagmatically con-
tiibuting to the body of knowledge in the si eld iises a pioblem of its own. As knowledge
giows in a specic aiea, solutions aie captuied and documented by expeits in books, ieseaich pa-
peis, conciete implementations, webpages, etc. While one may intuitively think that this giowth
implies bettei design, it has been shown that the way (and the amount) this knowledge is cap-
tuied iaises an impoitant issue per-se. Design, as an intentional act of choice, is constantly ovei-
whelmed by the sheei quantity of available infoimation.
In this disseitation, the authoi staits by piesenting aiguments pointing to how these incom-
plete by design systems aie a common issue in nowadays piactice of sofwaie engineeiing. Duiing
that oveiview, one must inevitably delve into the foices that lead aichitects, designeis and devel-
opeis to iecognize these kind of systems. Te taiget thus become ieadeis who have iecognized
(oi aie inteiested) in the set of systems that show a high degiee of vaiiability and incomplete-
ness, and which goal is to ieduce the oveiall eort monetaiy cost, available time and iesouices,
iequiied skills, iesulting complexity, etc. of coping with continuous change made to the do-
ii :ns1v:c1
main model. Mainly, this disseitation aims to answei what form should this type of systems take,
and which kind of tools and infrastructures should be available to support the development of such
sofware?
Te way this pioblemis heie coped, with a peimanent focus on the development of piesciip-
tive contiibutions to the si body of knowledge, is as follows. Fiist, it is piesented as a foimal-
ization of a unied conceptual pattern language, following the theoiies ist laid by Alexandei
et al., foi systems which domain model is taiget of continuous change duiing iuntime. Te un-
deilying meta-aichitectuie of these systems is known as Adaptive Object-models, and this pattein
language aims to answeis questions such as whendo these type of systems occui, theii advantages
and disadvantages, theii undeilying iequiiements, the set of available techniques and solutions
and theii main benets and liabilities.
Te authoi then pioceeds to specify a iefeience aichitectuie of an object-oiiented fiame-
woik capable of dealing with such systems. Questions heie addiessed include the type and foim
of needed infiastiuctuies, what abstiactions should be made and suppoited, the geneiic func-
tionalities it should piovide, its default behavioi and points of extension. Te authoi takes a
fuithei step in pioviding and detailing an industiial-level implementation of such fiamewoik,
along with the specic design issues that aiise only when puisuing such conciete aitifacts.
Finally, the authois main thesis is validated by pioviding empiiical evidence of the
fiamewoik benets thiough industiial use-case applications and contiolled academic quasi-
expeiiments. Two commeicial sofwaie systems built on top of that fiamewoik aie used as case
studies, ieecting theii own specic context, theii iequiiements, theii paiticulai pioblems, and
the way the fiamewoik and the undeilying theoiies heie built weie used to addiess them,
the outcomes, and the lessons leained. Inheient thieats to this type of validation aie fuithei
dismissed by piesenting the iesults of a (quasi-)expeiiment within a contiolled academic en-
viionment, wheie the iesults of studying gioups of undeigiaduate students following dieient
tieatments aie shown to be consistent with those eailiei piesented.
Resumo
A Engenhaiia de Sofwaie (is), enquanto aiea de piossionalizaao, debate-se numa piofunda
crise que iemonta aos piimeiios dias do seu nascimento, e se ieecte nos constantes atiasos e
insucessos dos seus piojectos, ao ponto dessas situaes deniiem a norma na aiea. No topo
da lista das piincipais causas desta situaao encontiam-se as expectativas iiiealistas dos intei-
venientes e a mudana contnua dos iequisitos. Em iesposta, tm suigido alguns piocessos de
desenvolvimento que defendem a eiiadicaao sistematica destas baiieiias do acto de ciiaao de
sofwaie; mas outios, especialmente aqueles auto-denominadas ageis, sublinham a necessidade
de abraar a mudana como uma piopiiedade essencial da piopiia actividade. Apesai de tudo,
peimanece poi iefutai a hipotese de nao existii uma bala de prata, uma nica metodologia uni-
cadoia capaz de melhoiai consistentemente a ecincia do desenvolvimento de sofwaie, pelo
menos, numa oidem de giandeza.
A obseivaao empiica comea, no entanto, a sugeiii que a mudana, mais do que uma sim-
ples causa, apiesenta-se como um sintoma iesultante da natuieza das piopiiedades intinsecas
a alguns domnios modelados pelo sofwaie a iespectiva necessidade de sei continuamente
modicado existe poique qualquei tentativa de modelai de foima denitiva esses domnios esta
condenada a sei incompleta paitida.
Mas se tais solues sao um alvo inevitavel de evolues e adaptaes constantes a novas
iealidades incompletas por natureza nao deveiiam entao sei activamente desenhadas paia
seiem naturalmente incompletas: Se as metodologias ageis modicam a foima como as equipas
e os indivduos planeiam e executam o piocesso de desenvolvimento paia abraar a mudana,
como deveiemos desenhai sofwaie paia delibeiadamente supoitai uma mudana continua:
Mesmo que uma iesposta estivesse facilmente ao nosso alcance, o objectivo de contiibuii
piagmaticamente paia o coipo de conhecimento na aiea da is levanta um novo pioblema. Poi
noima, medida que o conhecimento aumenta numa deteiminada aiea, as novas solues sao
captuiadas e documentadas poi especialistas emlivios, aitigos de investigaao, implementaes,
paginas de inteinet, etc. Emboia paiea intuitivo que este aumento de conhecimento implique
uma melhoiia nas escolhas de desenho, temsido demonstiado que a foima comoeste captuiado
pioblematica. O desenho, como um acto delibeiado de escolha, sistematicamente subjugado
pela quantidade de infoimaao disponvel.
Nesta disseitaao comea-se poi apiesentai os aigumentos que toinam os sistemas incom-
iv visUmo
pletos por natureza uma contingncia da is. Paia isso, seia impoitante peicebei as foias que
levam aiquitectos, designers e piogiamadoies a identicaiem este tipo de sistemas. O pblico
alvo assim os leitoies que se identicam com estas foias, ou que estao inteiessados no es-
tudo de sistemas caiacteiizados poi um elevado giau de vaiiabilidade e incompletude, e que
tenham como objectivo o de ieduzii o esfoio em teimos de custo monetaiio, tempo, iecui-
sos, complexidade iesultante, etc. paia lidai coma mudana, a evoluao constante do modelo
de domnio. Piincipalmente, esta disseitaao tem como objectivo iespondei peigunta qual a
forma no sentido de aparncia, estrutura que estes sistemas tomam, e que tipo de ferramentas
e infra-estruturas so necessarias para suportar o desenvolvimento desse tipo de sofware?
Em seguida descieve-se a metodologia utilizada, com um foco peimanente no desenvolvi-
mento de contiibuies piesciitivas paia o coipo de conhecimento da aiea. Seguindo as teoiias
seminalmente estabelecidas poi Alexandei, apiesentada a foimalizaao conceptual de uma
linguagem de padies de sistemas cujo modelo de domnio objecto de evolues contnuas.
A meta-aiquitectuia subjacente conhecida como Modelos de Objectos Adaptativos, e a lin-
guagem de padies tem como objectivo iespondei a questes ielacionadas com a ocoiincia
deste tipo de sistemas, as suas vantagens e desvantagens, os seus iequisitos basicos, as tcnicas e
as solues disponveis.
Segue-se a especicaao de uma aiquitectuia de iefeincia de uma framework oiientada a
objectos, capaz de lidai comtais sistemas. Aqui sao aboidadas questes tais como o tipo e foima
de tais infia-estiutuias, que abstiaces se devem piovidenciai, que funcionalidades geniicas
devem sei incoipoiadas e quais os compoitamentos base e pontos de extensao adequados. E
paialelamente desenvolvida e detalhada uma implementaao de iefeincia de nvel industiial,
na qual se apiofundam as idiossinciasias do seu desenho e as peculiaiidades dos pioblemas in-
tinsecos tentativa de atingii aitefactos paia pioduao.
Poi m piocede-se validaao da tese piincipal, demostiando-se a evidncia dos benefcios
da framework e, consequentemente, das teoiias subjacentes. Comea-se poi consideiai mtodos
de estudo de caso sobie dois sistemas comeiciais desenvolvidos, onde se apiesentam tanto as
iespectivas especicidades dos seus contextos, iequisitos, e pioblemas ielevantes, como a foima
em que as teoiias aqui desenvolvidas foiam neles utilizadas. Posteiioimente sao descaitadas as
ameaas de validaao ineientes a tal foima de estudo atiavs da iealizaao de quasi-expeiincias
conduzidas emambiente contiolado, atiavs do estudo de giupos de alunos de mestiado sujeitos
a difeientes tiatamentos.
Resume
Le domaine du Gnie Logiciel (ci) peut tie vu comme en tant en ciise depuis les piemieis
jouis de sa naissance. Les checs et oveiiuns de piojets ont depuis t considis comme la
noime, attiibus aux attentes diaisonnables des acteuis conceins et au changement constant
des exigences. Alois que ceitains piocessus de dveloppement luttent poui iadiquei systma-
tiquement ces baiiiies au dveloppement de logiciels, dauties mthodologies, spcialement les
coined agile, continuellement embiassent le changement comme une piopiit de piemiie im-
poitance de cette activit. Quand mme, il y toujouis lventualit quil ny ait pas de iecette miia-
cle, pas dunique mthodologie unicatiice capable damlioiei dune faon constante lecience
du dveloppement de logiciels, mme pai seulement un oidie de giandeui.
De plus, si de telles solutions ont besoin dvoluei et de sadaptei constamment de nouvelles
ialits, et pai consquent iegaides comme incompltes dans leui modle, ne deviaient-elles
pas tie activement modeles poui cette incompltude: Si dagiles mthodologies changent la
maniie des quipes et des individus de planiei le dveloppement poui embiassei le change-
ment, comment deviions-nous dlibiment modelei poui sajustei au changement continuel:
Mme si la iponse cette question pouiiait tie donne piomptement, lobjectif de con-
tiibuei dune maniie piagmatique au coips de connaissance dans le domaine du ci soulve un
pioblme pai lui-mme. Comme les connaissances saccioissent dans un ceitain domaine, les so-
lutions sont captuies et documentes pai les expeits dans les livies, publications scientiques,
ialisations concites, sites Inteinet, etc. Alois que nous pouvons pensei intuitivement que cet
accioissement implique de meilleuis choix de modlisation, il a t dmonti que la maniie (et
la quantit) que ces connaissances sont captuies soulve un pioblme impoitant en soi. Mod-
lisation, comme un choix actif intentionnel, est constamment dpass pai la quantit absolue
dinfoimation disponible.
Dans cette disseitation, lauteui commence pai pisentei les aiguments dmontiant com-
ment les systmes incomplets dans leui modlisation sont un pioblme commun dans la pia-
tique couiante du Gnie Logiciel. Pendant ce suivol, il est invitable de fouillei dans les foices
qui mnent les aichitectes, les modeleuis, et les dveloppeuis ieconnaitie ce genie de systmes.
Laudience devient donc le public qui sest ieconnu (ou qui est intiess) dans lensemble de sys-
tmes qui dmontient un niveau lev de vaiiabilit et dincompltude, et donc lobjectif est de
iduiie leoit global (i.e. les cots montaiies, la disponibilit du temps et des iessouices, les
vi visUmi
talents iequis, la complexit isultante, etc.) de sajustei au changement continuel que subit le
domain model. Suitout, cette disseitationvise ipondie quelle foime deviait piendie ce genie
de systme, et quel genie doutils et dinfiastiuctuies deviaient tie disponible poui suppoitei le
dveloppement de tels logiciels:
La maniie dont ce pioblme est ici tiait, avec un focus constant sui le dveloppement des
contiibutions piesciiptives au coips de connaissance du ci, va comme suit. Tout saboid, une
foimalisation dun langage conceptuel de pattein uni est pisente, suivie des thoiies initiale-
ment pisentes pai Alexandei et coll., poui des systmes dont le domain model est la cible de
changement continuel duiant lexcution. La mta-aichitectuie sous-jacente ces systmes est
connue sous Adaptive Object-models, et le langage de pattein vise ipondie aux questions telles
que quand ces genies de systmes suiviennent, leuis avantages et dsavantages, leuis exigences
sous-jacentes, lensemble de techniques et de solutions disponibles et leui piincipaux bnces
et iesponsabilits.
Lauteui piocde ensuite spciei les iefeience aichitectuie dun cadie de ifiences oiient
sui lobjet capable de giei de tels systmes. Les questions telles que le genie et la foime des in-
fiastiuctuies iequises, quelles abstiactions deviaient tie faites et suppoites, les fonctionnalits
gniiques quils deviaient fouinii, leui compoitement pai dfaut et leuis points of extension,
deviaient ici tie adiesses. Lauteui fait un pas de plus en fouinissant et dtaillant un cadie de
ifiences poui implmentation en industiie, en mme temps que les pioblmes spciques de
modlisation qui suiviennent uniquement en pouichassant de tels conciets aitfacts.
Finalement, la piincipale hypothse de lauteui est ensuite valide enfouinissant les vidences
des bnces du cadie de ifiences, tiis la fois des applications en industiie et des quasi-
expiiences contioles en milieu acadmique. Deux logiciels systme commeiciaux bass sui ce
cadie de ifiences sont utiliss comme tudes de cas, ietant leui contexte spcique, leuis ex-
igences, leuis pioblmes paiticulieis, and la maniie dont le cadie de ifiences (et les thoiies
sous-jacentes ici laboies) a t utilis poui les adiessei, les isultats, et les leons tiies. Les
menaces inhientes de ce type de validation sont davantage conduites en pisentant les isul-
tats dune quasi-expiience dans un enviionnement acadmique contiol, o ltude de gioupes
dtudiants suivant diients tiaitements sest avie consistante avec les tudes picdemment
pisentes.
Contents
Abstract i
Resumo iii
Resume v
Foreword by Joseph Yoder xvii
Preface xix
Introduction
:.: Sofwaie Ciisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
:.: Motivational Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
:., Incomplete by Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
:. Accidental Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
:., Designing foi Incompleteness . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
:.o Sofwaie Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
:., Patteins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
:.8 Reseaich Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o
:. Epistemological Stance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o
:.:o Reseaich Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
:.:: Main Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
:.:: How to Read this Disseitation . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
i Background ;
:.: Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
:.:.: Vaiiability and Commonality . . . . . . . . . . . . . . . . . . . . . . . :
:.:.: Adaptability, Adaptivity and Self-Adaptation . . . . . . . . . . . . . . . :
:.:., Reection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o
:.: Key Abstiactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o
:.:.: Metapiogiamming . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
viii CONTENTS
:.:.: Geneiative Piogiamming . . . . . . . . . . . . . . . . . . . . . . . . . :,
:.:., Metamodeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
:.:. Aspect-Oiiented Piogiamming . . . . . . . . . . . . . . . . . . . . . . :,
:.:., Domain Specic Languages . . . . . . . . . . . . . . . . . . . . . . . . :o
:.:.o Meta-Aichitectuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
:., Appioaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :8
:.,.: Sofwaie Pioduct Lines . . . . . . . . . . . . . . . . . . . . . . . . . . :8
:.,.: Naked Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :8
:.,., Domain-Diiven Design . . . . . . . . . . . . . . . . . . . . . . . . . . :8
:.,. Model-Diiven Engineeiing . . . . . . . . . . . . . . . . . . . . . . . . :
:.,., Model-Diiven Aichitectuie . . . . . . . . . . . . . . . . . . . . . . . . ,o
:. Application Fiamewoiks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,:
:..: Building Fiamewoiks . . . . . . . . . . . . . . . . . . . . . . . . . . . ,:
:..: Documenting Fiamewoiks . . . . . . . . . . . . . . . . . . . . . . . . ,,
:., Relevant Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,,
:.,.: Wikis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
:.,.: Smalltalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
:.,., Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,,
:.o Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,o
State of the Art in Adaptive Object-Models ;
,.: Te AOM Aichitectuial Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . ,,
,.:.: Why is it a Pattein: . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,8
,.:.: Towaids a Pattein Language . . . . . . . . . . . . . . . . . . . . . . . ,8
,.: Foimalized Patteins foi AOM . . . . . . . . . . . . . . . . . . . . . . . . . . . :
,.:.: Type-Object Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
,.:.: Piopeity Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
,.:., Type-Squaie Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . . .
,.:. Accountability Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . .
,.:., Composite Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
,.:.o Stiategy and Rule Object Patteins . . . . . . . . . . . . . . . . . . . . o
,.:., Inteipietei Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
,.:.8 Composing the Patteins . . . . . . . . . . . . . . . . . . . . . . . . . . ,
,., Dieiences fiom othei Appioaches . . . . . . . . . . . . . . . . . . . . . . . . ,
,. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Research Problem p
.: Epistemological Stance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,o
.: Fundamental Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,o
CONTENTS ix
.:.: Viewpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,:
., Tesis Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,:
. Specic Reseaich Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,,
..: Specic Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,,
..: Tesis Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . ,o
.., Tesis Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,,
., Validation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,8
.o Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,8
, Pattern Ianguage o
,.: On Patteins and Pattein Languages . . . . . . . . . . . . . . . . . . . . . . . . o:
,.:.: What is a Pattein Language: . . . . . . . . . . . . . . . . . . . . . . . o:
,.:.: Foim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o:
,.: Geneial Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o,
,., Technical Desciiption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o,
,. Geneial Foices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . oo
,., Coie Patteins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
,.,.: Eveiything is a Ting Pattein . . . . . . . . . . . . . . . . . . . . . . . o
,.,.: Closing the Roof Pattein . . . . . . . . . . . . . . . . . . . . . . . . . ,,
,.,., Bootstiapping Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
,.,. Lazy Semantics Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . ,o
,.o Evolution Patteins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8o
,.o.: Histoiy of Opeiations Pattein . . . . . . . . . . . . . . . . . . . . . . . 8:
,.o.: System Memento Pattein . . . . . . . . . . . . . . . . . . . . . . . . . 8,
,.o., Migiation Pattein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
,.o. Resulting Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
,., Composing the Patteins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
,.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
o Reference Architecture & Implementation p,
o.: Oveiview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
o.:.: Geneial Piinciples and Guidelines . . . . . . . . . . . . . . . . . . . . o
o.:.: High-level Aichitectuie . . . . . . . . . . . . . . . . . . . . . . . . . . o
o.:., Key Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
o.:. Component Composition . . . . . . . . . . . . . . . . . . . . . . . . . 8
o.: Tiead of Contiol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o.:.: Bootstiapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o.:.: Main Piocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :oo
o.:., Queiy Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o:
x CONTENTS
o.:. Commit Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o:
o., Aichitectuial Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . . . :o:
o.,.: Stiuctuial Coie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o:
o.,.: Behavioial Coie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o,
o.,., Waiehousing and Peisistency . . . . . . . . . . . . . . . . . . . . . . . :o,
o.,. Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o
o. Ciosscutting Conceins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::o
o..: Seiialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::o
o..: Integiity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :::
o.., (Co-)Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :::
o., Usei Inteiface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
o.o Development Eoit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
o., Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::o
; Industrial Case-Studies ;
,.: Reseaich Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.: Complexity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::8
,., Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
,. Locvs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
,..: Coie Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::o
,..: Time-Seiies Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . :::
,.., Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :::
,., Zephyi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.,.: Coie Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.,.: Time-Seiies Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.,., Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.o Suivey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
,.o.: Backgiound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.o.: Oveiall Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.o., Development Style & Piocess . . . . . . . . . . . . . . . . . . . . . . . ::,
,.o. Futuie Expectations . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::o
,., Lessons Leained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.8 Validation Tieats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::8
,. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
8 Academic Quasi-Experiment
8.: Reseaich Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,:
8.:.: Tieatments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,:
8.:.: Pie-test Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,:
CONTENTS xi
8.:., Piocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,,
8.:. Post-Test Questionnaiie . . . . . . . . . . . . . . . . . . . . . . . . . . :,
8.:., Independent Validation . . . . . . . . . . . . . . . . . . . . . . . . . . :,
8.: Expeiiment Desciiption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
8.:.: Fiist Phase: Constiuction . . . . . . . . . . . . . . . . . . . . . . . . . :,
8.:.: Second Phase: Evolution . . . . . . . . . . . . . . . . . . . . . . . . . :,,
8., Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
8.,.: Backgiound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :o
8.,.: Exteinal Factois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
8.,., Oveiall Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
8.,. Development Piocess . . . . . . . . . . . . . . . . . . . . . . . . . . . :o
8. Objective Measuiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
8., Validation Tieats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
8.o Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,:
p Conclusions ,
.: Summaiy of Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,,
.: Main Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
., Futuie Woik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,,
.,.: Evolving Oghma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,,
.,.: Web-based Adaptive Usei Inteifaces . . . . . . . . . . . . . . . . . . . :,o
.,., Impioving Usability of Automatically Geneiated GUI . . . . . . . . . . :,,
.,. Continuing the Pattein Language . . . . . . . . . . . . . . . . . . . . . :,,
.,., Self-Hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,,
. Epilogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,8
Appendices oo
A Pre-Experiment Data o
B Post-Experiment Questionnaire o,
C Post-Experiment Questionnaire Results ;
D Experimental Group Documentation ;
E Industrial Survey 8
Nomenclature 8
xii CONTENTS
References 8;
Iist of Figures
:.: Example diagiam of a Medical Centei IS . . . . . . . . . . . . . . . . . . . . . ,
:.: Wateifall sofwaie development lifecycle model . . . . . . . . . . . . . . . . .
:., Te Scium sofwaie development lifecycle model . . . . . . . . . . . . . . . . ,
:. Sofwaie as the ciystallization of an abstiaction . . . . . . . . . . . . . . . . . ,
:., Refactoied solution of a Medical Centei IS . . . . . . . . . . . . . . . . . . . . o
:.o Te foui iecognized foices of pioject management . . . . . . . . . . . . . . . . 8
:.: Concept map on ielated tools, appioaches and abstiactions. . . . . . . . . . . . :8
:.: Te foui layeis of abstiaction in UML/MOF. . . . . . . . . . . . . . . . . . . . ,:
:., Patteins foi Evolving Fiamewoiks . . . . . . . . . . . . . . . . . . . . . . . . . ,,
,.: A pattein language foi Adaptive-Object Models . . . . . . . . . . . . . . . . . ,
,.: Te meta layeis of an AOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
,., A class diagiam of the Type-Object pattein . . . . . . . . . . . . . . . . . . . . ,
,. A class diagiam of the Piopeity pattein . . . . . . . . . . . . . . . . . . . . . . ,
,., A class and objects diagiam of the Type-Squaie pattein . . . . . . . . . . . . .
,.o A class and objects diagiam of the Accountability pattein . . . . . . . . . . . . ,
,., A class and objects diagiam of the Composite pattein . . . . . . . . . . . . . . ,
,.8 A class diagiam of the Stiategy and Rule Object patteins . . . . . . . . . . . . o
,. A class diagiam of the Inteipietei pattein . . . . . . . . . . . . . . . . . . . . . o
,.:o AOM coie aichitectuie and design . . . . . . . . . . . . . . . . . . . . . . . . ,
,.: Te ieective towei of a video ienting system . . . . . . . . . . . . . . . . . . . oo
,.: Te ielationship among foices of object-oiiented meta-aichitectuies. . . . . . . o,
,., Pattein map foi coie patteins of meta-aichitectuies . . . . . . . . . . . . . . . o
,. Class diagiam of the Eveiything is a Ting pattein . . . . . . . . . . . . . . . . ,:
,., Data and metadata evolution patteins. . . . . . . . . . . . . . . . . . . . . . . 8o
,.o Applying Eveiything is a Ting foi evolution patteins . . . . . . . . . . . . . . 8:
,., Histoiy of Opeiations class diagiam . . . . . . . . . . . . . . . . . . . . . . . . 8,
,.8 System Memento class diagiam . . . . . . . . . . . . . . . . . . . . . . . . . . 8,
,. Liteial instantiation of the System Memento pattein . . . . . . . . . . . . . . . 88
xiv LIST OF FIGURES
,.:o Delta instantiation of the System Memento pattein . . . . . . . . . . . . . . . . 88
,.:: Class diagiam of the Migiation pattein . . . . . . . . . . . . . . . . . . . . . . o
,.:: A pattein language foi Adaptive-Object Models . . . . . . . . . . . . . . . . .
o.: High-level aichitectuie of the Oghma fiamewoik . . . . . . . . . . . . . . . . ,
o.: Aichitectuie of a client-seivei setup . . . . . . . . . . . . . . . . . . . . . . . .
o., Aichitectuie of a distiibuted setup . . . . . . . . . . . . . . . . . . . . . . . .
o. Activity diagiam of the fiamewoik initialization . . . . . . . . . . . . . . . . . :oo
o., Activity diagiam of the main loop . . . . . . . . . . . . . . . . . . . . . . . . . :o:
o.o Activity diagiam of queiy events . . . . . . . . . . . . . . . . . . . . . . . . . :o:
o., Activity diagiam of commit events . . . . . . . . . . . . . . . . . . . . . . . . :o:
o.8 Coie design of the stiuctuial meta-model. . . . . . . . . . . . . . . . . . . . . :o:
o. An extension of the Tvvi-SqU:vi pattein. . . . . . . . . . . . . . . . . . . . . :o,
o.:o Implementing the Eveiything is a Ting pattein . . . . . . . . . . . . . . . . . :o
o.:: An example of two dieient states of the same entity. . . . . . . . . . . . . . . :o
o.:: Implementation model of the stiuctuial meta-model . . . . . . . . . . . . . . :o,
o.:, A class diagiam of the Stiategy and Rule Object patteins . . . . . . . . . . . . :oo
o.: Dynamic coie of the Oghma fiamewoik . . . . . . . . . . . . . . . . . . . . . :oo
o.:, Class diagiam of the waiehousing design . . . . . . . . . . . . . . . . . . . . . :o8
o.:o Class diagiam of the peisistency design . . . . . . . . . . . . . . . . . . . . . . :o
o.:, Data and meta-data aie manipulated thiough opeiations . . . . . . . . . . . . :::
o.:8 Meiging mechanism used to validate and apply opeiations . . . . . . . . . . . ::,
o.: Example of a simple model evolution . . . . . . . . . . . . . . . . . . . . . . . ::,
o.:o Oghma code-base complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . ::,
,.: GISA evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
,.: SMQVU evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
,., Locvs model evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :::
,. Locvs model complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :::
,., Zephyi model complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
8.: Expeiiment design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,:
8.: Task : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,,
8., Task : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,o
8. Task , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,,
8., Changes foi Task : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,8
8.o Changes foi Task : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,8
8., Changes foi Task , . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
.: Evolution of the Oghma implementation . . . . . . . . . . . . . . . . . . . . . :,o
Iist of Tables
,.: A pattein catalog foi Adaptive Object Models . . . . . . . . . . . . . . . . . . o
o.: Wiki design piinciples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
o.: Design piinciples foi incomplete by design systems . . . . . . . . . . . . . . . ,
o., Code metiics foi the cuiient implementation of Oghma . . . . . . . . . . . . . ::,
,.: Locvs Chionogiam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :::
,.: Backgiound iesults of industiial suivey . . . . . . . . . . . . . . . . . . . . . . ::,
,., Oveiall satisfaction iesults of industiial suivey . . . . . . . . . . . . . . . . . . ::o
,. Development style iesults of industiial suivey . . . . . . . . . . . . . . . . . . ::o
,., Development piocess iesults of industiial suivey . . . . . . . . . . . . . . . . . ::,
,.o Futuie expectations iesults of industiial suivey . . . . . . . . . . . . . . . . . . ::,
8.: Student giades gioup statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . :,:
8.: Independent Samples Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,,
8., Backgiound Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ::
8. Exteinal Factois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
8., Oveiall Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
8.o Development Piocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :,
8., Implemented iequiiements . . . . . . . . . . . . . . . . . . . . . . . . . . . . :
.: New featuies iesults of industiial suivey . . . . . . . . . . . . . . . . . . . . . :,,
A.: Student giades foi the Expeiimental gioup . . . . . . . . . . . . . . . . . . . . :o,
A.: Student giades foi the Baseline gioup . . . . . . . . . . . . . . . . . . . . . . . :o,
C.: Post-expeiiment questionnaiie iesults . . . . . . . . . . . . . . . . . . . . . . :,:
E.: Industiial suivey iesults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :8:
xvi LIST OF TABLES
Foreword by Joseph Yoder
Ovei the last decade it has become extiemely impoitant foi systems to be able to adapt quickly to
changing business iequiiements. Because of this, theie has been an evolution of the way we de-
velop and think about building systems. Foi example, Agile piocesses have evolved as a means
to build systems moie quickly. But when woiking on Agile piojects, developeis can become
oveiwhelmed with the iate at which iequiiements change. Te ease with which iequiiements
can change encouiages useis to oveiwhelm developeis with featuie iequests. Te iesult: Featu-
ritis, which piomotes hasty constiuction of pooily designed sofwaie to suppoit those featuies.
Te design of an expiessive domain model might get lost in the iush to wiite woiking code.
Adaptive Object-Models (:om) suppoit changeable domain modules by casting business iules
as inteipieted data and iepiesenting objects, piopeities and ielationships in exteinal declaia-
tions. At ist glance, :om systems seem to contiadict Agile values. Yet we nd that undei the
iight conditions, an :om aichitectuie has made oui useis happiei and has given them the ability
to contiol the pace of change. It can be the ultimate in agility!
Tis thesis has taken the next step in state of ait ieseaich on best piactices foi building these
types of dynamic systems. Tis woik illustiates the necessity of sofwaie to adapt and change at
sometimes iapid speeds. Hugos addition of seven key patteins biings togethei yeais of study and
pioduces foimalized patteins as an impoitant contiibution to the :om community. Te thesis
also biings ieal woild pioblems to light and centeis much of the discussion on the inheient aws
of much of todays sofwaie design piactices.
Te woik ieveals much about the cuiient state of Adaptive Object Model piactices in indus-
tiy. I found the thesis to be a quality entiy into the cuiient :om ieseaich and veiy enlightening
foi those in the sofwaie community building these types of aichitectuies. Te ieview of :om
aichitectuial style, the patteins catalogue, the outline of the iefeience aichitectuie foi :omalong
with an example implementation makes the woik veiy ielevant and infoimative, as well as a plea-
suie to iead. Additionally the case studies highlight the common issues and pioblems addiessed
by :om along with pioving that :om exist as a common solution foi these types of systems.
I look foiwaid to futuie collaboiation with Hugo on this topic aiea and it is my pleasuie
to stiongly iecommend this woik to aichitects and developeis that aie building these types of
dynamic aichitectuies.
xviii ioviwovu nv ,osivu vouiv
Preface
Te journey of a thousand miles begins with one step.
L:o TzU
My eailiest memoiies as anengineei date back to childhoodandChiistmas, to iicoandiobots,
to dismantling things without quite knowing how to assemble them back. It was a fun hobby foi
me, and a nuisance if not dangeious activity foi my paients. I iecall that once I had the
biilliant idea of connecting a poitable playing device a GameoVatch to the AC mains
when I ian out of batteiies. To my undeistanding, they both piovided eneigy, so it should have
woiked. I was ve... About one yeai latei, my neighboi got one thing called computer, which
when connected to a television allowed us to contiol what happened theie: the Atari :ooo. Soon
my paients oeied me a msx as a Chiistmas gif. My fathei, not veiy fond of technology, bought
it second-handed believing it was an enteitainment device, but missed the fact he had to actually
buy games sepaiately. I usually tell this stoiy about why I claim to have leained piogiamming
at the age of six: a kid with a new toy, no games, and a book called Programmers Manual; the
outcome seems almost inevitable among those boin in late ,os and eaily 8os.
I like to think that such an eaily backgiound gave me time to ruminate ovei the natuie of
sofwaie, specically what sepaiates good and elegant fiom bad and sloppy piogiams, befoie one
staits facing piogiamming as a piofessional need. Maybe the aesthetic inuences fiom my ait-
oiiented fiiends played a key iole on that. Piogiamming, fiom my point of view, was no moie
of a science than of an art. But it was afei nishing my degiee, when I became acquainted with
design patterns and meta-programming, that Ive iealized I wasnt alone in this puisue foi elegance
in a seemingly mechanical woild:
Vhat is the Chartres of programming? Vhat task is at a high enough level to inspire people
writing programs, to reach for the stars? Can you write a computer programon the same level as
Fermats last theorem?Can you write a program which overcomes the gulf between technical
culture of our civilization, and which inserts itself into our human life as deeply as Eliots poems
of the wasteland or Virginia Voolf s Te Vaves? [Gabo]
Expeiiencing at ist-hand the pioblems of bad design in the industiial woild, by spending too
much nights with too little sleep, tight time constiaints peisuaded to make things as automatic
xx vvii:ci
as possible climbing the hill of abstiaction becomes a necessary fun. Doing iequiiements en-
gineeiing also made us painfully awaie of an impoitant pattein: most customeis haidly know
what they want, and veiy seldom what they need. Undoubtedly all this inuenced the couise of
my Ph.D. even befoie it staited. But, I was still an engineei...
Gopalakiishnan, in his book comvU1:1io iciiivic [Gopoo], dieientiates people
who seek an in-depth understanding of the phenomenon of computation to be computer scientists
fiomthose people who seek to eciently apply computer systems to solve real-world problems to be
computation engineers. And alas, something inside me is deeply distuibed eveiy time someone
disiegaids as just a matter of implementation. Just:... But implementation changes eveiything!
It is the act of ciafing, of making a theoiy mateiialize, the ultimate aspiiation of cieating some-
thing out of nothing oi fiom scaice iesouices that shapes the motivational forces behind an
engineei.
Take the Chuich-Tuiing thesis; it is a deep, beautiful hypothesis that piovides an insight on
the meaning of computability anda biidge betweensymbols andmachines , whichis nothing
less than an amazing display of the motivation that diive scientists to puisue mathematical tiuth.
Peisonally, I am amazed by theii eoits to nd the undeilying building blocks of constiuction;
an heiculean task that establishes the boundaiies and foundations of what can and cannot be
done. But engineeis iegaid theii ait as something dieient: it is not the why so much as the
how. While a scientist may iegaid two piogiams that aie pioven to be functionally equivalent
to be one and the same, an engineei will iush to shout a toiient of quality attributes such as
usability, maintainability, performance, modularity, aordability, among otheis, that somehow
would iendei the two piogiams completely dierent.
And yet, heie lies the natuie of design, the Alexandiian Quality Vithout A ^ame, the foices
that shape up a pattein, that yield an optimal solution foi a good pioblem. Te scientic tieat-
ment of the contiibutions in this disseitation may stand on the pillais of the scientic method,
but, ultimately, they aie the outcome of an engineeiing necessity.
Tat said, fiom childhood up until now, willingly oi not, many people had dened what I
am and the few things I was able to accomplish. Chionologically, my paients, who though not
technology-savvy, tiaced my futuie the moment they handed me a computei. My ancee Helena,
who encouiaged me to puisue my goals knowing theii impact on both of oui lives. My main
supeivisoi Ademai Aguiai, who played a tiemendous iole in my studies and always ensuied my
ieseaich would be possible to puisue. My industiial co-supeivisoi Alexandie Sousa, who has
givenme the suppoit and oppoitunity to enioll inthe Ph.D. while still woiking foi PaiadigmaXis,
S.A. My scientic co-supeivisoi Joao Pascoal Faiia, whose woik pieceded mine in a veiy similai
aiea. My exteinal supeivisoi Joseph Yodei, one of the ist (and cuiient) ieseaicheis on Adaptive
Object-Models, whose woik inspiied and lead me to this point. My fellow ieseaicheis Filipe
Coiieia and Nuno Floies, cuiiently puisuing theii Ph.D in sofwaie engineeiing, with whom I
shaied houis of woik and fiiendship. And to Ana Paiva, with whom I have had the pleasuie of
xxi
lectuiing foimal methods in sofwaie engineeiing foi the past thiee editions.
My giatitude also goes to the Depaitment of Infoimatics Engineeiing (uii) wheie I have
been lectuiing in the past two yeais, in the peison of the head of depaitment, Piof. Raul Vidal,
foi the invaluable suppoit ovei my academic and piofessional life. And to iisc-v, foi paitially
suppoiting my ieseaich.
Last, but not the least, my acknowledgments to all my fiiends, colleagues, fellowieseaicheis,
woiking paitneis, students, and oveiall good chums, in alphabetical oidei: Alexandie Silva,
Ana Mota, Andieia Teixeiia, Antonio Rito Silva, Auilio Piies, Biuno Matos, David Peieiia,
Diogo Lapa, Diogo Romeio, Fatima Piies, Gabiiela Soaies, Heniique Dias, Hugo Silva, Joao
Feiieiia, Joao Giadim, Joel Vaianda, Joige Pinheiio, Jos Pedio Oliveiia, Jos Poito, Jos Vilaa,
Leon Welicki, Paulo Cunha, Pedio Abieu, Rosaldo Rossetti, Rui Maianhao, Sigio Mesquita,
and Tiago Cunha. Finally, my giatitude to Cinthia Pag and Paulo Romeio, foi helping in the
fiench tianslation of the abstiact.
Poito, :: Decembei :o:o
It seems my giatitude wouldnt be complete if I didnt acknowledged C
8
H
10
N
4
O
2
and C
9
H
8
O
4
, commonly
known as caeine and aspirin, which aie known to be avid suppoiteis of this ieseaich.
xxii vvii:ci
Chapter
Introduction
. Sonware Crisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
.i Motivational Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
. Incomplete by Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Accidental Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
., Designing for Incompleteness . . . . . . . . . . . . . . . . . . . . . . . . . ;
.o Sonware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
.; Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p
.8 Research Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
.p Epistemological Stance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
.o Research Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Main Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
.i How to Read this Dissertation . . . . . . . . . . . . . . . . . . . . . . . . .
Te piactice of sofwaie engineeiing is iegaided as being in ciisis since the eaily days of its
existence, constantly plagued by pioject oveiiuns and failuies. Once expectations and change
weie identied as majoi contiibuting factois, most development piocesses uiged theii system-
atic eiadication fiomsofwaie development. Othei methodologies, especially those coined agile,
took an opposite diiection by iethinking the way sofwaie is built in oidei to embrace change.
Eithei way and since theie is no silver bullet evidence suggests that change may not be
just a cause, but a symptom of a deepei natuie. In fact, it has been obseived that some sof-
waie needs to change because the domain it is modeling is incomplete even befoie it staits to be
developed. Such sofwaie has to be constantly evolving and adapted to a new ieality fiom the
moment it is conceived. Yet, if these systems aie accepted and iegaided as being incomplete by
design, shouldnt they be actively designed for incompleteness: If theie was the need to shif the
way sofwaie is developed to embrace change, how should one delibeiately design to cope with
continuous change: What extent should it considei:
: i1vouUc1io
. sov1wnnv cn:s:s
Sofwaie and the coiiesponding aiea of sofwaie engineeiing seems to be in ciisis since
the eaily days of computing science. Te iapid giowth in both computei powei and pioblem
complexity has been iesulting in a coiiesponding inciease in the diculty of wiiting correct,
understandable and veriable computei piogiams. Tis was the state of aaiis piesented in a
:1o sponsoied confeience on sofwaie engineeiing ciica :o8, wheie unreasonable expectations
and change weie undeilined as majoi contiibuting factois [BBHo]. Edsgei Dijkstia commented
this same issue few yeais latei, duiing his :,: ACM Tuiing Awaid lectuie [Dij,:]:
Te major cause of the sofware crisis is that the machines have become several orders of mag-
nitude more powerful! To put it quite bluntly. as long as there were no machines, program-
ming was no problem at all, when we had a few weak computers, programming became a mild
problem, and now we have gigantic computers, programming has become an equally gigantic
problem.
On the technology side, a similai concein was being shaied by Alan Kay duiing the design of
Smalltalk and object-oriented programming in the dawn of peisonal computeis [Kay,]:
... there would be millions of personal machines and users, mostly outside of direct institutional
control. Vhere would the applications and training come from? Vhy should we expect an
applications programmer to anticipate the specic needs of a particular one of the millions of
potential users? An extensional system seemed to be called for in which the end-users would do
most of the tailoring (and even some of the direct constructions) of their tools [sic].
And yet, despite the natuial ieaction on cieating bettei piocesses, tools, and methodologies
foi sofwaie development, a :8, godelian exposuie by Fied Biooks biings a geneial consen-
sus among the sofwaie engineeiing community that theie is no silver bullet no single ap-
pioach will pievent pioject oveiiuns and failuies in all possible cases [Bio8,]. A conjectuie
somewhat distuibing in light of consecutive cu:os iepoits [Sta], wheie the success iate of
sofwaie piojects was estimated to be only :o, with challenged piojects accounting foi ,,, and
impaiied (cancelled) foi ,: . in :, and a success of ,:, challenged, and : failed
. in :oo'.
.i mo1:vn1:oNn: vxnmv:v
In oidei to exemplify and fuithei illustiate some of the cential ideas and concepts of this dissei-
tation, let us considei a ieal-woild infoimation system foi a medical healthcaie centei, paitially
' Although the exact natuie of these guies has been taiget of iecent ciiticism in [EV:o], it seems that eithei theii
iesults aie heavily biased, oi even a modeiate change in the accuiacy of the success iatio, e.g. fiom ,: to ,o,
would piobably still iendei the eld as in crisis.
mo1iv:1io:i ix:mvii ,
Identier {unique}
Name
Birthdate
/ Age
Sex: enum {male, female}
Observations
Patient
Expiration Date
Observations
Insurance
Name
Specialization
Doctor
Date
Symptoms
Observations
/ Total Cost
Appointment
Description
Treatment Group
Cost
Observations
Procedure
Description
Observations
Contact
Severity: enum
Observations
Pathology
Engineer
Architect
...
enumeration
Profession
*
* doctors
*
0..1 {subsets
doctors}
/ procedures
*
/ doctor
1
*
Figure .: Example of a domain diagiam of an infoimation system foi a medical centei. Te hoiizon-
tal dashed lines denote open (incomplete) inheiitances. Te dots inside the enumeiation also
denotes incomplete knowledge which should be editable by the end-usei.
depicted as a class diagiam in Figuie :.:. Shoitly, the medical centei has Patients and special-
ized Doctors. Infoimation about a patient, such as hei peisonal infoimation, Contacts and
Insurances, aie iequiied to be stoied. Patients go to the centei to have Appointments with
seveial Doctors, though they aie usually followed by a main one. Duiing an appointment, sev-
eial Pathologies may be identied, which aie ofen addiessed thiough the execution of medical
Procedures.
In this example, the ieadei should be able to obseive a key piopeity in this kind of infoi-
mation systems: incompleteness. Foi example, pioceduies, insuiances, pathologies and contacts
aie specied as having open-hieiaichies (wheie each specialization may iequiie dieient elds).
Patients may not have all the ielevant infoimation iecoided (e.g., ciitical health conditions) and
foieseeing those missed foimalizations, eithei the designei oi the customei make extensive us-
age of an observations eld. Te systemmay also be missing some domain concepts, such that of
auxiliaiy peisonnel, which would iequiie the intioduction of a new class. Te ielevance of stoi-
ing peisonal infoimation about doctois may also have been oveilooked; actually, in the piesence
of these new iequiiements, a designei would likely make Patients, Doctors and Auxiliary Per-
sonnel inheiit fiom a single abstiaction, e.g., Persons. Te healthcaie centei likely has policies
against doctois peifoiming pioceduies foi which they aie not qualied, which would intioduce
specic constiaints based on theii specialization in the model. In fact, it now seems evident that
a doctoi may have multiple specializations.
i1vouUc1io
Tese aie examples of iequiiements that could easily elude developeis and stakeholdeis dui-
ing the analysis piocess. What may seem a ieasonable, iealistic and useful system at some point,
may quickly evolve beyond the oiiginal expectations, unfoitunately afei analysis is consideied
nished (see Figuie :.:).
Requirements
Analysis
Design
Implementation
Testing
Maintenance
Figure .i: Wateifall sofwaie development lifecycle model as closely desciibed in the woik of Winston
Royce [Roy8,]. Some modied models intioduce feedback loops (pictuied as a dashed aiiow),
eithei connecting the end-points oi between dieient phases.
. :Ncomv:v1v nv uvs:oN
Te pievious example iepiesents a iecuiient pioblem in sofwaie development: the diculty
of acquiiing, infeiiing, captuiing and foimalizing iequiiements, paiticulaily when designing
systems wheie the piocess is highly coupled with the stakeholdeis peispective and the iequiie-
ments ofen change fastei than the implementation. Tis ieality, well known in industiial en-
viionments, is mostly blamed upon issues ielated to the stakeholdeis ability to coiiectly elicit
theii needs [PTo,], foi the sole ieason that maintaining and evolving sofwaie is a knowledge
intensive task accounting foi a signicant amount of eoit [AOSDo,]. Consequently, once the
analysis phase is nished and the implementation piogiesses, stiong iesistance to fuithei change
emeiges, due to the mismatch between specication and implementation aitifacts. Notwith-
standing, fiom the stakeholdeis peispective, some domains do iely on constant adaptation of
theii piocesses to an evolving ieality, not to mention that new knowledge is continuously ac-
quiied, which leads to new insights of theii own business and what suppoit they expect fiom
sofwaie.
Confionted with the above issues, some development methodologies (paiticulaily those
coined agile) have intensied theii focus on a highly iteiative and inciemental appioach [WCo,].
Fiom the subtitle embrace change in Kent Becks ix1vimi vvocv:mmic ixvi:iiu
book [BAo], to the motto responding to change over following a plan fiom the Agile Mani-
festo, these methodologies accept that change is, in fact, an invaiiant of sofwaie development.
icomvii1i nv uisic ,
Tis stance is in cleai contiast with othei piactices that focus on a priori, time-consuming, iig-
oious design, consideiing continuous change as a luxuiious (and somewhat dangeious) asset foi
the pioductivity and quality of sofwaie development (see Figuie :.,).
Product
Backlog
Sprint
Backlog
Working
Increment
Sprint
Daily Tasks
Figure .: Te Scium sofwaie development lifecycle model, wheie pioduct iequiiements ieside on the
backlog, and fiom wheie they aie chosen at the beginning of eveiy spiint. Te spiint then
follows a :/ weeks cycle, with daily tasks taken fiom the spiint backlog. Tus, the pioduct is
synthesized as a seiies of disciete inciements. [TN8o, DSo]
Although the benets of an up-fiont, coiiect and validated specication aie undeniable
and have been piaised by foimal methods of development, paiticulaily when coping with ciit-
ical systems theii appioach is ofen iecognized as impiactical in a laige majoiity of sofwaie
piojects [Hei8], paiticulaily inenviionments chaiacteiized by continuous change. Nonetheless,
the way most developeis cuiiently cope with change ofen iesult in a Bic B:ii oi MUu [FY,]
wheie systems aie peimanently in the verge of needing a total ieconstiuction, but eithei way
with obvious impacts in the piojects cost. Foi that ieason, sofwaie that is taiget of continuous
change should be iegaided as incomplete by design, i.e., it needs to be constantly evolving and
adapting itself to a new ieality fiom the moment it is conceived, and most attempts to fieeze its
iequiiements aie out-of-sync with its own condition see Figuie :..
Reality
Domain
Software
Figure .: Sofwaie may be iegaided as the ciystallization of an abstiaction that models a specic domain.
Ideally, it should match the exact limits of that domain. But in piactice (i) those limits aie fuzzy,
(ii) sofwaie ofen imposes an aiticial, unnatuially iigid stiuctuie, and (iii) ieality itself keeps
changing.
Asofwaie aichitectuial pattein desciibed by its authois as a haphazardly structured, sprawling, sloppy, duct-tape-
and-baling-wire, spaghetti-code jungle.
o i1vouUc1io
Patient
Doctor
Appointment
Procedure Type
Pathology Type
*
*
0..*
Name
Profession
Name: string
Procedure
Name = "Surgery"
Surgery: Procedure
Name: string
Pathology
Name = "Flu"
Flu: Pathology
instanceOf
instanceOf
Name = "Architect"
Architect: Profession
instanceOf
Insurance Type Contact Type
Name: string
Contact
Name: string
Insurance
Name = "Mobile Phone"
Mobile: Contact
Name = "SNS"
SNS: Insurance
instanceOf instanceOf
Figure .,: Arefactored solution foi the diagiamin Figuie :.: (p. ,), mainly depicting the elements that weie
changed/added foi pioviding a mechanism to cope with open inheiitance and enumeiations.
Tis example makes extensive use of the Tvvi-On,ic1 pattein to solve open inheiitances and
enumeiations.
. ncc:uvN1n: comv:vx:1v
Should the system be iequiied to cope with the kind of incompleteness displayed in :.: (p. :),
the designei would have to delibeiately make it extensible in appiopiiate points. A potential
solution is depicted in Figuie :.,, compiising only the refactored elements intended to addiess
the issues of open inheritances and enumerations.
Compaied to the initial design seen in Figuie :.: (p. ,), this one ieveals itself as a much laigei
model. In fact, it is now moie dicult to distinguish between elements that aie essential to the
specication of the domain, fiom those whose iole is instiumental in this case, that piovide
extensibility to the system. Te iesult is an inciease of what is dened as accidental complexity
complexity that aiises in computei aitifacts, oi theii development piocess, which is non-essential
to the pioblem being solved. In contiast, the ist model was much closei to that of essential
complexity inheient and unavoidable. Tis inciease in accidental complexity was only caused
by the specic appioach chosen to solve the pioblemin this case, iecuiient usage of the Tvvi-
On,ic1 pattein ,.:.: (p. :), applied to solve open inheiitances and enumeiations.
While sometimes accidental complexity can be due to mistakes such as ineective planning,
oi low piioiity placed on a pioject, some accidental complexity always occuis as the side eect
of solving any pioblem. Foi example, mechanisms to deal with out-of-memoiy eiiois aie pait
of the accidental complexity of most implementations, although they occui just because one has
uisicic iov icomvii1iiss ,
decided to use a computei to solve the pioblem.
Notwithstanding, and to a gieat extent, most accidental complexity is intioduced by the in-
appiopiiate actions used to cope with the evolution of sofwaie aitifacts, hence iesulting in a Bic
B:ii oi MUu. Because the minimization of accidental complexity is consideied a good piac-
tice to any aichitectuie, design, and implementation, excessive accidental complexity is a cleai
example of a bad piactice.
., uvs:oN:No von :Ncomv:v1vNvss
While newei sofwaie engineeiing methodologies stiuggle to inciease the ability to adjust easily
to changes of both the piocess and the development team, geneially they seem to maintain a
ceitain agnosticism iegaiding the foim of the pioduced sofwaie aitifacts`. Tis doesnt mean
they aie not awaie of this need to change. In fact, iteiative means seveial cycles going fiom
analysis to development, and back again. Some aie also awaie of the Bic B:ii oi MUu pattein
(oi anti-pattein, depending on the peispective); the piactice of refactoring afei each iteiation in
oidei to cope with design debt is specically included to addiess that [NLoo]. But the pioblem
seems to iemain in the sense that the outcome, w.i.t. form, of each iteiation is mostly synthesized
as if it would be the last one, albeit delibeiatively iecognizing it is not.
Yet, if these systems aie accepted and iegaided as being incomplete by design, it seems ieason-
able to assume they should be actively designed for incompleteness. If we shif the way we develop
sofwaie to embrace change, it seems a natuial decision to delibeiately design that same sofwaie
to best cope with continuous change. Citing the woik of Gaiud et al. [GJTo,]:
Te traditional scientic approach to design extols the virtues of completeness. However, in en-
vironments characterized by continual change [new solutions] highlight a pragmatic approach
to design in which incompleteness is harnessed in a generative manner. Tis suggests a change
in the meaning of the word design itself from one that separates the process of design from
its outcome, to one that considers design as both the medium and outcome of action.
Tis is in paiticulai dissonance with most of the cuiient appioaches to sofwaie engineeiing,
wheie piocesses attempt to establish a cleai line between designing and developing, specifying
and implementing. Tough it seems that, should we wish to hainess continual change, that dis-
tinction no longei suits oui puiposes: design should become both the medium and outcome of
action. Eigo, we aie looking foiwaid not just foi a piocess to be eective and agile, but to what
form should agile sofwaie take.
` Piobably an ovei-simplication since agile methodologies piesciibe the simplest design that works, which some-
what addiesses (without piesciibing any specic) foim.
8 i1vouUc1io
.o sov1wnnv uvs:oN
So fai, the woid design has been loosely used. But, what exactly is design: What makes the
dieience between good and bad design: How do we measure it: Why is it becoming a key
factoi in the development of sophisticated computei systems:
Te Websteis dictionaiy denes it as the act of (i) working out the form of something, (ii)
sketching a plan for something, (iii) creating something in the mind, oi (iv) doing something for
a specic role or purpose or eect [Web:o]. Sofwaie engineeiing has also beenfaced withthe task
of sketching, planning, andcieating suitable pioducts foi specic puiposes. Foi that puipose, any
specic solution diafed duiing the design of a sofwaie aitifact typically consideis foices such
as (i) the expeiience of the team, (ii) the available budget, (iii) the exact functional and non-
functional iequiiements, etc. Moie geneially, sofwaie piojects aie iecognized as having foui
majoi foices thiough which any paiticulai balance (oi imbalance) of them diiectly inuences
the viability of a specic solution, as depicted in Figuie :.o.
cost
quality
scope
time
+
+
Figure .o: Te foui iecognized foices of pioject management w.i.t. sofwaie engineeiing: time iefeis to
the amount of time available to complete a pioject; cost iefeis to the budgeted amount avail-
able; scope iefeis the piojects domain limit and detail. Each foice mutually inuences (eithei
positively oi negatively) eveiy othei. Quality is thus a iesult function of how the othei foices
aie balanced.
But even taking into consideiation these foui majoi foices, the evei incieasing complexity
(both inheient and accidental) of building and managing sofwaie aitifacts aie pushing the limits
of cieation beyond the ability of a single entity [Aleo]. And similaily to eveiy othei aieas of
engineeiing, it is not uncommon foi a single pioblem to have multiple ways to be coped with.
So, in the end, how does an engineei choose the best design foi a specic function:
As knowledge giows in a specic aiea, solutions aie captuied and documented by expeits
in books, ieseaich papeis, conciete implementations, web pages, and a myiiad of othei types of
communicationmedia. While we may intuitively think that any giowth inthe body of knowledge
implies bettei design choices, it seems that the way (and the amount) this knowledge is being
captuied iaises an impoitant issue per-se.
v:11ivs
In 1ui v:v:uox oi cuoici: wuv movi is iiss, Schwaitz points that the oveiabundance of
choice that oui modein society has poses a cause foi psychological distress, wheie the information
overow ultimately iesults on an ovei-simplication of ciiteiia [Scho,]. Pieceding Schwaitz in
foui decades, Alexandei claimed, in his Ph.D. thesis o1is o 1ui sv1uisis oi iovm, that
most infoimation on any specic body of knowledge is hard to handle, widespread, diuse, un-
organized, and ever-changing. Moieovei, this amount of information is increasingly growing be-
yond the reach of single designers. He concluded that although a specic solution should reect
all the known facts relevant to a specic design (...) the average designer scans whatever informa-
tion he happens on and introduces it randomly [Aleo]. Design, as an intentional act of choice,
is constantly oveiwhelmed by the sheei quantity of available infoimation.
.; vn11vnNs
As Alexandei stiuggled with this scenaiio, he came up with the concept of pattern: a iecui-
ient solution foi a specic problem, that is able to achieve an optimal balance among a set of
forces in a specic context. Fuithei on his ieseaich, he extended this notion beyond the tiiplet
xproblem, forces, solutiony, to that of a pattern language, which also encompasses the ielationship
between each pattein in a specic domain. Tis eoit iesulted in the ist pattein language on
civil aichitectuie to be compiled and ieleased as a book [AIS,,].
Almost two decades latei, both Gamma et al. [GHJV] and Buschman et al. [BMR
+
o]
boiiowed these concepts into the elds of computei science andsofwaie engineeiing, publishing
the ist books on sofwaie design and architectural patteins. Tese two types of patteins, along
with a thiid called idioms, can be dened as follows [BMR
+
o]:
Architectural patterns expiess fundamental stiuctuial oiganization schemes foi sofwaie
systems, decomposing them into subsystems, along with theii iesponsibilities and inteiie-
lations.
Design patterns aie medium-scale tactical patteins, specied in teims of inteiactions be-
tween elements of object-oiiented design, such as classes, relations and objects, pioviding
geneiic, piesciiptive templates to be instantiated in conciete situations. Tey do not in-
uence oveiall system stiuctuie, but instead dene micio-aichitectuies of subsystems and
components.
Idioms (sometimes also called coding patteins) aie low-level patteins that desciibe howto
implement paiticulai aspects of components oi ielationships using the featuies of a specic
piogiamming language.
It should be noted that Alexandei was a civil aichitect, and thus his theoiies emeiged fiom the obseivation of
cities and buildings, although he had a M.Sc. in Mathematics.
:o i1vouUc1io
Built on top of Alexandeis theoiies, these iesulting pattein languages weie synthesized by
systematic analysis and documentation of scatteied empiiical knowledge, and had hitheito a
piofound impact in the way aichitects and designeis build and manage sofwaie aitifacts today.
.8 nvsvnncn oon:s
Up until this point, the authoi has piesented aiguments pointing to how incomplete by design
systems aie a common issue in nowadays piactice of sofwaie engineeiing. Howevei, it is not
pait of this study to piove wheie noi why these kind of systems emeige. Likewise, this dis-
seitation will just slightly delve into the foices that may lead an aichitect to iecognize these kind
of systems. Instead, it is assumed the following set of piemises, which upon this woik is built: (i)
the system we aie woiking with exhibits an high degiee of vaiiability, (ii) its specications have
shown a high degiee of incompleteness, and (iii) it is desiiable to ieduce the eoit of coping
with changes made to the domain model. Should one agiee with these piemises, the authois
fundamental ieseaich question may be stated as what form should this type of systems take, and
which kind of tools and infrastructures should be available to support the development of such
soware systems:
Consequently, the main goal is to ieseaich this form, heie to be undeistood as the architec-
ture and design of such sofwaie systems, along with the specication and constiuction of the
appiopiiate tools and infiastiuctuie.
.p vv:s1vmo:oo:cn: s1nNcv
To undeistand the way sofwaie engineeis build and maintain complex and evolving sofwaie
systems, ieseaich needs to focus beyond the tools and methodologies. Reseaicheis need to delve
into the social and theii suiiounding cognitive piocesses vis-a-vis individuals, teams, and oigani-
zations. Teiefoie, ieseaich in sofwaie engineeiing may be iegaided as inheiently coupled with
human activity, wheie the value of geneiated knowledge is diiectly dependent on the methods
by which it was obtained.
Because the application of ieductionismto assess the piactice of sofwaie engineeiing, paitic-
ulaily in eld ieseaich, is a complex peihaps unsuitable activity, this disseitation is aligned
with a pragmatistic view of acquisition of knowledge, valuing acquiied piactical assets [Gouo8].
In othei woids, the authoi chooses to use whatevei methods seem to be moie appiopiiate to
piove oi at least impiove knowledge about the questions iaised, piovided theii scientic
signicance.
Te intended meaning of eort should be loosely inteipieted as monetaiy cost, available time and iesouices,
iequiied skills, iesulting complexity, etc.
visi:vcu mi1uous ::
Mostly, though, this peispective makes extended use of mixed methods, such as (i) system-
atization of widespiead, diuse, and unoiganized empiiical best piactices thiough observational
and historical methods, (ii) laboiatoiial (quasi-)expeiiments, usually suitable foi academic envi-
ionments, and (iii) industiial case-studies, as both a conduit to haivest piactical iequiiements,
as to piovide a tight feedback and application ovei the conducted investigation.
.o nvsvnncn mv1nous
A categoiization pioposed at Dagstuhl woikshop [THP,], gioups ieseaich methods in foui
geneial categoiies, quoted fiom Zelkowitz and Wallace [ZW8]:
Scientic method. Scientists develop a theoiy to explain a phenomenon; they piopose a
hypothesis and then test alteinative vaiiations of the hypothesis. As they do so, they collect
data to veiify oi iefute the claims of the hypothesis.
Engineering method. Engineeis develop and test a solution to a hypothesis. Based upon
the iesults of the test, they impiove the solution until it iequiies no fuithei impiovement.
Empirical method. A statistical method is pioposed as a means to validate a given hy-
pothesis. Unlike the scientic method, theie may not be a foimal model oi theoiy desciib-
ing the hypothesis. Data is collected to veiify the hypothesis.
Analytical method. A foimal theoiy is developed, and iesults deiived fiom that theoiy
can be compaied with empiiical obseivations.
Tese categoiies apply to science in geneial. Eective expeiimentation in sofwaie engi-
neeiing iequiies moie specic appioaches. As discussed in :. (p. :o), sofwaie engineeiing
ieseaich compiises computei science issues, human issues and oiganizational issues. It is thus
ofen convenient to use combinations of ieseaich appioaches both fiom computei science and
social sciences. Te taxonomy desciibed by Zelkowitz and Wallace [ZW8] identies twelve
dieient types of expeiimental appioaches foi sofwaie engineeiing, giouped into thiee bioad
categoiies:
Observational methods. An obseivational method collects ielevant data as a pioject de-
velops. Teie is ielatively little contiol ovei the development piocess othei than thiough
using the new technology that is being studied. Teie aie foui types: pioject monitoiing,
case study, asseition, and eld study.
Historical methods. A histoiical method collects data fiom piojects that have alieady
been completed. Te data alieady exist; it is only necessaiy to analyze what has alieady
been collected. Teie aie foui methods: liteiatuie seaich, legacy data, lessons leained,
and static analysis.
:: i1vouUc1io
Controlled methods. Acontiolled method piovides multiple instances of an obseivation
foi statistical validity of the iesults. Tis method is the classical method of expeiimental
design in othei scientic disciplines. Teie aie foui types of contiolled methods: iepli-
cated expeiiment, synthetic enviionment expeiiment, dynamic analysis, and simulation.
Teie aie, howevei, paiticulai ieseaich appioaches, methods and outcomes iegaiding the
study of sofwaie aichitectuies, which can be giouped into ve types of products, quoted fiom
Shaw [Shao:]:
Qualitative or descriptive model. Oiganize and iepoit inteiesting obseivations about
the woild. Cieate and defend geneializations fiom ieal examples. Stiuctuie a pioblem
aiea; foimulate the iight questions. Do a caieful analysis of a system oi its development.
Examples: eaily aichitectuial models, and aichitectuial patteins.
Technique. Invent newways to do some tasks, including pioceduies and implementation
techniques. Develop a technique to choose among alteinatives. Examples: pioduct line
and domain-specic sofwaie aichitectuies, and Umi to suppoit object-oiiented design.
System. Embody iesult in a system, using the system development as both souice of
insight and caiiiei of iesults. Examples: aichitectuie desciiption languages.
Empirical predictive model. Develop piedictive models fiom obseived data.
Analytic model. Develop stiuctuial (quantitative oi symbolic) models that peimit foimal
analysis. Examples: ui: specication, and com inconsistency analysis.
Te best combination of methods to use in a conciete ieseaich appioach is stiongly depen-
dent on the specic chaiacteiistics of the ieseaich study to peifoim, viz. its puipose, enviion-
ment and iesouices. Heieafei, the ieseaich methods iefeiied will use this teiminology. Fuithei
desciiption of each method can be found in [ZW8], and a detailed iational on the methods
chosen in Chaptei (p. ).
. mn:N oon:s
Te piimaiy outcomes of this thesis encompasses the following aimed contiibutions to the body
of knowledge in sofwaie engineeiing:
:. Te formalization of a pattern language for systems which domain model is target of
continuous change during runtime. When do these type of systems occui: What aie the
advantages: What aie theii undeilying iequiiements: Howdo we cope with each of them:
What aie the benets and liabilities of each specic solution: Tis contiibution expands
uow 1o vi:u 1uis uissiv1:1io :,
an unied conceptual pattein language, which allows aichitects and designeis to iecognize
and adequately use some of the best piactices in sofwaie engineeiing that cope with this
type of systems. Fuithei details aie piesented in Chaptei , (p. o:).
:. Te specication of a reference architecture for adaptive object-model frameworks.
What kind of infiastiuctuies aie needed: What foim should they take: What type of ab-
stiactions should be made and suppoited: What aie the geneiic functionalities it should
piovide: What should be its default behavioi: How can it be extended: Tis contiibution
addiesses seveial issues conceining fiamewoik design foi Adaptive Object-Models, and
piesents a solution thiough the composition of aichitectuial and design elements. Moie
details can be found in Chaptei o (p. ,).
,. A reference implementation of such framework. Fiom theoiy to piactice, Chaptei o
(p. ,) also details a conciete implementation of a fiamewoik based on the pioposed iefei-
ence aichitectuie, codenamed Oghma. Te goal of attaining an industiial-level implemen-
tation of such fiamewoik, along with the ieseaich of specic design issues that aiise only
when puisuing such conciete implementations, allowed to fuithei puisue the ieseaich us-
ing the chosen validation methodologies.
. Evidence of the framework benets through industrial use-case applications. A fiame-
woik should emeige fiom ieiteiated design in ieal-woild scenaiios. As such, the imple-
mentation shown in Chaptei o (p. ,) is mainly the iesult of an inciemental engineeied
solution foi specic industiial applications. Tis contiibution piesents sofwaie systems
built ontop of that fiamewoik, theii context, theii iequiiements, theii paiticulai pioblems,
the way the fiamewoik was used to addiess them, the outcomes, and the lessons leained
in Chaptei , (p. ::,).
,. Evidence of the framework properties through controlled academic quasi-experiments.
Althoughthe industiial usage of the fiamewoik piovides piagmatic evidence of its benets,
theie aie some thieats that aie inheient to that type of validation. Tese shoitcomings aie
addiessed in Chaptei 8 (p. :,:), by conducting a (quasi-)expeiiment within a contiolled
academic expeiimental enviionment, wheie the study of gioups of undeigiaduate students
inteiacting with the fiamewoik has shown the iesults to be consistent with those piesented
in Chaptei , (p. ::,).
.i now 1o nvnu 1n:s u:ssvn1n1:oN
Te iemaining of this disseitation is logically oiganized into thiee paits, with the following
oveiall stiuctuie:
: i1vouUc1io
Part : Background & State of the Art. Te ist pait ieviews the most impoitant concepts
and issues ielevant to the thesis, namely:
Chaptei :, Backgiound (p. :,), piovides an extensive liteiatuie suivey on sofwaie engi-
neeiing techniques, tools, and piactices able to cope with incomplete by design systems.
Chaptei ,, State of the Ait in Adaptive Object-Models (p. ,,), piovides a state-of-the-ait
oveiview mostly focused on Adaptive Object-Models.
Part i: Problem&Solution. Te secondpait states the pioblemieseaichedandthe pioposed
solution:
Chaptei , Reseaich Pioblem (p. ), lays both the fundamental and specic ieseaich
questions in scope foi this thesis.
Chaptei ,, Pattein Language (p. o:), piesents an unied conceptual pattein language foi
Adaptive Object-Models.
Chaptei o, Refeience Aichitectuie o Implementation (p. ,), composes seveial aichi-
tectuial and design elements into a fiamewoik based on the pattein language, codenamed
Oghma, and desciibes its cuiient implementation.
Part : Validation & Conclusions. Te thiid pait piesents case studies and one (quasi-
)expeiiment foi the validation of the thesis, and piesents the conclusions of the disseitation:
Chaptei ,, Industiial Case-Studies (p. ::,), piesents a detailed analysis on using this
fiamewoik in industiial settings.
Chaptei 8, Academic Quasi-Expeiiment (p. :,:), addiesses validation issues thiough
contiolled expeiimental enviionments.
Chaptei , Conclusions (p. :,,), diafs the main conclusions of this disseitation, and
points to fuithei woik.
Foi a compiehensive undeistanding of this disseitation, all the paits should be iead in the
same oidei they aie piesented. Tose alieady familiai with meta-aichitectuies and adaptive
object-models, who only want to get a fast but detailed impiession of the woik, may skip the
ist pait, and go diiectly to Chaptei (p. ).
Some typogiaphical conventions aie used to impiove the ieadability of this document. Pat-
tein names always appeai in Sm:iiC:si style. Whenevei iefeiiing to piogiamming oi model-
ing elements, such as classes oi piopeity names, they aie piinted using xed-width chaiacteis.
Relevant concepts aie usually intioduced in italics. Book titles and acionyms aie type-faced in
:iic:vs. Refeiences and citations appeai inside [squaie biackets] and inhighlight coloi when
uow 1o vi:u 1uis uissiv1:1io :,
viewing this document in a computei, these will also act as hyperlinks. If not otheiwise specied,
the giaphical notationused complies to the latest veisions of Umi [OMG:od] and oci [OMG:oc]
available at the date of publication (v.:.,).
:o i1vouUc1io
Chapter i
Background
i. Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p
i.i Key Abstractions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . io
i. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i8
i. Application Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i., Relevant Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i.o Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
Te cuiient demand foi industiialization of sofwaie development is having a piofound im-
pact in the giowth of sofwaie complexity and time-to-maiket. Still, most eoit in the devel-
opment of sofwaie is iepeatedly applied to the same tasks. Despite all the eoit in ieseaich
foi moie eective reuse techniques and piactices, which although iemain a piomising appioach
to the ecient development of high quality sofwaie, reuse has not yet fullled its tiue poten-
tial [HCo:, Szyo:, Gouo8]. As in othei aieas of scientic ieseaich, the ieaction has been to hide
the inheient complexities of technological conceins by cieating incieasingly highei levels (and
layeis) of abstiactions with the goal of helping ieasoning, albeit ofen at the cost of widening the
alieady existing gap between specication and implementation aitifacts [FRo,].
To make these abstiactions useful beyond documentation, analytical and ieasoning
puiposes [AEQ, KOSo,], highei-level models must be made executable, by systematic
tiansfoimation (oi inteipietation) of pioblem-level abstiactions into sofwaie implementa-
tions [RFBLOo:, Vlo,]. Te piimaiy focus of model-diiven engineeiing (mui) is to nd ways
of automatically animating such models, piomoting them fiom auxiliaiy, document-level dia-
giams, to ist-class sofwaie aitifacts able to diive complex systems at multiple levels of abstiac-
tion and peispectives [FRo,].
:8 n:cxcvoUu
A
d
a
p
t
a
b
i
l
i
t
y
V
a
r
i
a
b
i
l
i
t
y
A
d
a
p
t
i
v
e
O
b
j
e
c
t
-
M
o
d
e
l
S
o
f
t
w
a
r
e
D
o
m
a
i
n
R
e
a
l
i
t
y
I
n
c
o
m
p
l
e
t
e
n
e
s
s
S
e
l
f
-
A
d
a
p
t
i
v
e
A
g
i
l
e
P
r
o
c
e
s
s
e
s
C
o
m
p
o
n
e
n
t
s
S
o
f
t
w
a
r
e
P
r
o
d
u
c
t
L
i
n
e
s
M
e
t
a
m
o
d
e
l
i
n
g
M
D
A
M
D
E
D
o
m
a
i
n
S
p
e
c
i
c
L
a
n
g
u
a
g
e
x
U
M
L
M
e
t
a
p
r
o
g
r
a
m
m
i
n
g
R
e
e
c
t
i
o
n
F
r
a
m
e
w
o
r
k
I
n
f
r
a
s
t
r
u
c
t
u
r
e
P
a
t
t
e
r
n
c
o
p
e
s
-
w
i
t
h
s
u
p
p
o
r
t
s
s
u
p
p
o
r
t
s
p
r
o
v
i
d
e
s
c
o
n
g
p
o
i
n
t
s
c
o
p
e
s
i
s
-
e
x
p
r
e
s
s
i
v
e
-
i
n
a
b
s
t
r
a
c
t
s
i
m
p
l
e
m
e
n
t
s
i
s
-
i
n
h
e
r
e
n
t
r
e
q
u
i
r
e
s
i
s
-
p
r
o
p
e
r
t
y
-
o
f
i
s
-
a
c
o
n
t
a
i
n
s
i
s
i
s
i
s
r
e
q
u
i
r
e
s
i
s
-
a
-
p
r
o
p
e
r
t
y
-
o
f
h
a
s
i
s
p
r
o
v
i
d
e
s
h
a
v
e
C
h
a
n
g
e
e
m
b
r
a
c
e
l
e
a
d
s
-
t
o
m
a
y
-
r
e
s
u
l
t
-
f
r
o
m
r
e
l
a
t
e
s
-
t
o
W
i
k
i
e
m
b
r
a
c
e
e
m
b
r
a
c
e
m
a
y
-
b
e
m
a
y
-
u
s
e
m
a
y
-
p
r
o
v
i
d
e
G
e
n
e
r
a
t
i
v
e
P
r
o
g
r
a
m
m
i
n
g
i
s
c
a
n
-
u
s
e
m
a
y
-
p
r
o
v
i
d
e
Figure i.: Concept map iepiesenting the ielationship between seveial aieas, concepts and techniques pie-
sented in this chaptei.
iUu:mi1:is :
i. vcNunmvN1n:s
One way to design sofwaie capable to cope with incompleteness and change is to encode the sys-
tems concepts into highei-level iepiesentations, which could then be systematically synthesized
(by inteipietation oi tiansfoimation) into executable aitifacts, thus ieducing the oveiall eoit
(and complexity) of changing it. An oveiview of the seveial concepts that will be appioached
in this section is shown in Figuie :.: (p. :8). In summaiy, variability and adaptability aie two
key piinciples, usually ielated to self-adaptive sofwaie and sofware product lines. Tese piinci-
ples aie highly ielated to the inheient incompleteness of some sofwaie domains. Vikis and Agile
piocesses, foi examples, aie known to embrace change and thus coping with incompleteness.
On the technology side, one can nd (i) metaprogramming, which is usually ielated to genera-
tive programming and reection, but whose aitifacts aie close to piogiamming languages, and
(ii) metamodeling, usually ielated to Model Driven Engineering, Model Driven Architectures and
Executable UML, whose aitifacts aie moie close to the domain. Both, but especially the lattei,
iequiie the appiopiiate infrastructure to be used. Frameworks piovide such infiastiuctuies by as-
sembling components and patterns. A veiy close concept is the domain specic languages, which
is an abstiaction especially tailoied to be highly expiessive in a paiticulai domain.
i.. Variability and Commonality
Sofwaie variability iepiesents the need of a sofwaie systemoi aitifact to be changed, customized
oi congured foi use in dieient contexts [JVBSo:]. High variability means that the sofwaie
may be used in a bioadei iange of contexts, i.e., the sofwaie is moie ieusable. Te degiee of
vaiiability of a paiticulai systemis given by its Variation Points, oi ioughly the paits that suppoit
(ie)conguiation and consequently tailoring of the pioduct foi dieient contexts oi foi dieient
puiposes. On the othei hand, the identication of what is subject to change is intimately ielated
to that of what does not change, i.e., commonality. Vaiiability and commonality aie base concepts
in Sofware Product Lines, which will be coveied in :.,.: (p. :8).
i..i Adaptability, Adaptivity and Self-Adaptation
While vaiiability is given by context, i.e. it is the taiget applicability of a sofwaie system, the
piopeity of such systems to be eciently ieconguied due to changed ciicumstances is called
adaptability. Im othei woids, a piece of sofwaie may be ieconguied by developeis, to be de-
ployed and used in dieient contexts (e.g., by iecompiling with an additional component oi
thiough a component-based aichitectuie), and this need is called vaiiability as discussed in
:.:.:. Adaptability, on the othei hand, is the piopeity that allow sofwaie to change its behavioi
by end-useis with limited, oi non-existent, piogiamming skills.
:o n:cxcvoUu
Te liteiatuie also mentions adaptivity, which is a bioadei piopeity wheie a computei system
is able to adapt itself to changes in inteinal, usei-ielated, oi enviionmental chaiacteiistics. Te
dieience to adaptability' is that it may be moie pio-active in the suggestion oi execution
of a paiticulai change, hence not stiictly dependent on human inteivention. A moie specic
case of adaptivity is self-adaptation, when systems aie empoweied with the ability to adjust their
own behavioi in iesponse to theii peiceptions of self, oi the enviionment, without fuithei human
inteivention [CLG
+
o].
All these piopeities, oi capabilities, usually iely on a ceitain degiee of introspection and in-
tercession two aspects of reection which will be fuithei discussed in :.:.,. Te woik by
Andiesen et al. [AGo,] identies some enabling ciiteiia foi adaptability in enteipiise systems.
Fuithei woik by Meso et al. [MJoo] piovides an insight into how agile sofwaie development
piactices can be used to impiove adaptability.
i.. Reection
Reection is the piopeity of a system that allows to obseive and altei its own stiuctuie oi behav-
ioi duiing its own execution. Tis is noimally achieved thiough the usage and manipulation of
(meta-)data iepiesenting the state of the piogiam/system. Teie aie two aspects of such manip-
ulation: (i) introspection, i.e., to obseive and ieason about its own state, and (ii) intercession, i.e.,
to modify its own execution state (stiuctuie) oi altei its own inteipietation oi meaning (seman-
tics) [Caz8]. A simple example using both intiospection (to nd a class by name) and intei-
cession (by cieating a new instance of a class) can be obseived in Souice :.:. Tese capabilities
makes ieection a key piopeity foi metapiogiamming, as fuithei exposed in :.:.: (p. ::).
1 Foo . new. he l l o # wi thout r e f l e c t i o n
2 Obj ect . const_get ( : Foo) . send ( : new) . send ( : he l l o ) # wi th r e f l e c t i o n
Source i.: Two ways of invoking a method fiom a newly cieated instance in Ruby.
i.i xvv nns1nnc1:oNs
Abstiactionis a veiy bioadconcept, whichdenitiondepends onthe conciete aiea of application.
Quoting seveial aiticles fiom [Wik:oa]:
Conceptually, it is the piocess oi iesult of geneialization by ieducing the infoimation
content of a concept oi an obseivable phenomenon, typically to ietain only infoimation
which is ielevant foi a paiticulai puipose.
' Tis dieience is not always evident, due to a ielaxed usage of both teims.
xiv :ns1v:c1ios ::
In Mathematics, it is the piocess of extiacting the undeilying essence of a mathematical
concept, iemoving any dependence on ieal woild objects with which it might oiiginally
have been connected, and geneializing it so that it has widei applications oi matching
among othei abstiact desciiptions of equivalent phenomena.
In Computer Science, it is the mechanism and piactice of ieducing and factoiing out
details so that one can focus on a few concepts at a time.
In Sonware Engineering, it is a piinciple that aims to ieduce duplication of infoimation
in a piogiam (usually with emphasis on code duplication) whenevei piactical by making
use of abstiactions piovided by the piogiamming language.
All these denitions shaie one factoi in common that abstraction involves ielinquishing
some piopeity, such as detail, to gain oi inciease anothei piopeity, like simplicity. Foi example,
a common known use of the woid abstraction is to classify the level of a piogiamming language:
Assembly is ofen iegaided as low-level because it exposes the undeilying mechanisms of the
machine with an high degiee of delity; Haskell, on the othei hand, is a high-level language,
stiuggling to hide as much as possible the undeilying details of its execution. Te lattei tiades
execution performance in favoi of cross-platform and domain expressiveness, among otheis. And
yet, iaising the level of abstiaction seems to be the futuie of piogiamming languages, as exposed
by C-s lead designei Andeis Hejlsbeig [BWo]:
the ongoing trend in language evolution has always been this constant increase of abstraction
level. If you go all the way back to plugboards and machine code and then symbolic assemblers
and then C and then C++ and now managed execution environments and so forth, each step
we moved a level of abstraction up. Te key challenge always is to look for the next level of
abstraction.
Howevei, abstiactions shouldhaidly be consideied win-winsolutions. Joel Spolsky obseives a ie-
cuiient phenomena in technological abstiactions called Leaky Abstractions, which occuis when
one technological abstiaction tiies to completely hide the concepts of anothei, lowei-level tech-
nology, and sometimes the undeilying concepts leak through those supposed invisible layeis,
iendeiing themvisible [Spoo:]. Foi example, an high-level language may tiy to hide the fact that
the piogiam is being executed at all by a von-neumann machine. But, although two piogiams
may be functionally equivalent, memoiy consumption and piocessoi cycles may eventually diaw
a cleai and piagmatic sepaiation between them. Te piogiammei may thus need to leain about
the middle and lowei-level components (i.e., piocessoi, memoiy, compilei, etc.) foi the pui-
pose of designing a program that executes in a reasonable time, thus bieaking the abstiaction
layei. Spolsky goes as fai as conjectuiing that all non-trivial abstractions, to some degree, are
Also known as the dont repeat yourself piinciple, oi eXtieme Piogiammings once and only once.
:: n:cxcvoUu
leaky. Hence, good abstiactions aie specically designed to expiess the exactly intended details
in a specic context, while ielinquishing what is consideied unimpoitant, quoting [ASo]:
Ve must constantly turn to new languages in order to express our ideas more eectively. Estab-
lishing new languages is a powerful strategy for controlling complexity in engineering design,
we can ofen enhance our ability to deal with a complex problem by adopting a new language
that enables us to describe (and hence to think about) the problem in a dierent way, using
primitives, means of combination, and means of abstraction that are particularly well suited to
the problem at hand.
Despite ones tendency to inteipiet new languages as piogiamming languages, that is not nec-
essaiy the case. In fact, a pattein language enables us to describe (and hence to think about) the
problem in a dierent way, using primitives, means of combination, and means of abstraction that
are particularly well suited to the problem at hand :., (p. ).
i.i. Metaprogramming
Metapiogiamming` consists on wiiting piogiams that geneiate oi manipulate eithei othei pio-
giams, oi themselves, by tieating code as data. Quoting [CI8]:
A metaprogramming system is a programming facility (subprogramming system or language)
whose basic data objects include the programs and program fragments of some particular pro-
gramming language, known as the target language of the system. Such systems are designed to
facilitate the writing of metaprograms, that is, programs about programs. Metaprograms take
as input programs and fragments in the target language, perform various operations on them,
and possibly, generate modied target-language programs as output.
Histoiically, metapiogiamming systems weie divided into two sepaiate languages: (i) the meta-
language, in which the meta-piogiamis wiitten, and (ii) the object language which the metapio-
giampioduces oi manipulates. Nowadays, most piogiamming languages use the same language
foi the two functions [Caz8], eithei (i) by being homoiconic such as iisv, (ii) being dynamic
such as Ruby and Python, oi (iii) by exposing the inteinals of the iuntime engine thiough :vis,
such as Java and Miciosof .NET.
One of the most common applications of metapiogiamming is in the tianslation of high-
level desciiptions into low-level implementations by means of application generators, as fuithei
discussed in :.:.: (p. :,). Such techniques allows developeis to focus on specications based
on tested standaids iathei than in implementation details, making tasks like systemmaintenance
and evolution moie easy and aoidable [Bas8,, Cle88]. Claims about the economic benets in
teims of development and adaptability have been studied and published foi moie than twenty
` Oi meta-programming; the usage of the hyphen afei the piex meta vaiies among authois. Te same applies foi
meta-modeling, meta-program, meta-data
xiv :ns1v:c1ios :,
yeais [Lev8o]. Howevei, the focus of these techniques is mostly diiected to the code level iathei
than high-level domain concepts.
Asimple example of using metapiogiamming to implement a factoiial function whose value
is pie-calculated at compile-time can be found in Souice :.:. Tis example makes usage of C++
techniques such as template metaprogramming and template specialization.
1 templ ate <i nt N>
2 s t r uc t Fac t or i al { enum { val ue = N Fac t or i al <N - 1 >: : val ue }; };
3
4 templ ate <>
5 s t r uc t Fact or i al <0> { enum { val ue = 1 }; };
6
7 voi d f oo ( ) {
8 i nt x = Fact or i al <4>:: val ue ; // 24
9 i nt y = Fact or i al <0>:: val ue ; // 1
10 }
Source i.i: Calculating a factoiial function at compile-time by using C++ templates.
An amusing and somewhat mind-twisting example is that of a piogiam which pioduces a
copy of its own souice code as its only output; these metaprograms aie known as quines, and a
quine wiitten by John McCaithy in iisv can be found in Souice :.,.
1 ( ( lambda ( x)
2 ( l i s t x ( l i s t ( quote quote ) x) ) )
3 ( quote
4 ( lambda ( x)
5 ( l i s t x ( l i s t ( quote quote ) x) ) ) ) )
Source i.: An example of a LISP piogiam which pioduces a copy of its own souice code.
i.i.i Generative Programming
One common appioach to addiess vaiiability and adaptability is the use of Geneiative Pio-
giamming (cv) methods, which tiansfoim a desciiption of a system (model) based in piimi-
tive stiuctuies [RKS8], into eithei executable code oi code skeleton. Tis code can then be
fuithei modied and/oi iened and linked to othei components [Czao]. Geneiative Piogiam-
ming deals with a wide iange of possibilities including those fiom Aspect Oiiented Piogiam-
ming [KHo:, DYBJo8], :.:. (p. :,), and Intentional Piogiamming [CEoo].
A teim populaiized by Douglas Hofstadtei in his book couii, iscuiv, n:cu: : i1iv:i coiui
nv:iu [Hof,], named afei philosophei Willaid Van Oiman Quine due to his paiadox-pioducing expiession:
Yields falsehood when preceded by its quotation yields falsehood when preceded by its quotation.
: n:cxcvoUu
Because geneiative appioaches focus on the automatic geneiation of systems fiomhigh-level
(oi, at least, highei-level) desciiptions, it is aiguable whethei those act like a meta-model of the
geneiated system. Still, the iesulting functionality is not diiectly pioduced by piogiammeis but
specied using domain-ielated aitifacts. In summaiy, cv woiks as an o-line code-pioducei and
not as a iun-time adaptive system [YBJo:a].
Tis technique typically assumes that (i) changes aie always intioduced by developeis
(change agents), (ii) within the development enviionment, and (iii) that a full tiansfoimation
(and most likely, compilation) cycle is aoidable (i.e., no iun-time ieconguiation). When these
piemises fail to hold, geneiative appioaches aie eithei unsuitable, oi iequiies additional infias-
tiuctuies such as incremental compilation [RFBLOo:].
Peihaps one of the biggest diawbacks in cv is on iound-tiip engineeiing (v1i): the synchio-
nization among multiple aitifacts that iepiesent the same infoimation, e.g. a model and the
geneiated code. When the infoimation piesent in multiple aitifacts is open to change, then in-
consistencies may occui if those aitifacts aie not consistently updated to ieect any intioduced
change, due to theii causal connections. A common example is in maintaining a piece of code
and its Umi iepiesentation synchionized.
i.i. Metamodeling
Metamodeling can be dened as the analysis, constiuction and development of the fiames, iules,
constiaints, models and theoiies applicable and useful foi modeling a piedened class of piob-
lems [SVoo]; in othei woids, it is the piactice of constiucting models that specify othei mod-
els. Metamodelling is closely ielated to, and to some extent oveilapping, ontology analysis and
conceptual modeling, since both aie ofen used to desciibe and analyze ielations between con-
cepts [SAJ
+
o:].
A model is said to confoim to its metamodel in the way that a paiticulai computei pio-
giam confoims to the giammai of the piogiamming language in which it is wiitten. Quot-
ing [GPHSo8]:
In epistemology and other branches of philosophy, the prex meta- is ofen used to mean
about its own category, in [metamodeling,] meta- means that the model that we are build-
ing represents other models i.e. a metamodel is a model of models. Tis relationship is ofen
described as paralleling the TypeInstance relationship. In other words, the metamodel (Type)
and each of the models (Instances) are of dierent stu and are described using dierent
languages (natural or sofware engineering languages). Such type models therefore use classi-
cation abstraction which leads to a metamodelling hierarchy.
Considei a common cv system that tiansfoims Umi into code; in total, theies thiee potential issues to manage,
viz. (i) forward engineering, wheie the model changes so the code needs to be ie-geneiated, (ii) reverse engineering,
wheie the code was changed so the model needs to be ie-tted, and (iii) round-trip engineering, wheie both the
model and the code has been changed, so they need to be ieconciled.
xiv :ns1v:c1ios :,
Common uses foi metamodels include (i) schemas foi semantic data that needs to be exchanged
oi stoied, (ii) languages that suppoits a paiticulai method oi piocess, (iii) languages that expiess
additional semantics of existing infoimation [Wik:oc]. Te usage of metamodeling techniques
duiing iuntime piovides an answei to high-variability systems, wheie the laige semantic mis-
match between specication and implementation aitifacts in tiaditional systems can be ieduced
by the use of models, metamodels, and metadata in geneial [RFBLOo:].
i.i. Aspect-Oriented Programming
Aspect-Oiiented Piogiamming (:ov) is a piogiamming paiadigm that isolates secondaiy oi
auxiliaiy behaviois fiom the implementation of the main business logic. It has been pioposed
as a viable implementation of modulai ciosscutting conceins. Since ciosscutting conceins can-
not be piopeily modulaiized within object-oiiented piogiamming, they aie expiessed as aspects
and aie composed, oi woven, with tiaditionally encapsulated functionality iefeiied to as com-
ponents [KHo:, KMo,]. Tis paiadigm has been gaining some momentum paiticulaily because
even conceptually simple ciosscutting conceins such as tiacing duiing debugging and synchio-
nization, lead to tangling, in which code statements addiessing the ciosscutting concein become
inteilaced with those addiessing othei conceins within the application [LCo,].
Many :ov implementations, such as those ielated to Python, woik by automatically injecting
newcode into existing classes (a piocess which is commonly called decoiating a class), eectively
adding new functionalities that piomote extensive code ieuse [MSo,]. An example of such can
be found in Souice :., using the Aspyct libiaiy [ddB:o].
1 c l a s s MyAspect ( Aspect ) :
2 def at Cal l ( s e l f , cd ) :
3 pr i nt ( at Cal l occur s now )
4
5 @MyAspect ( )
6 def t e s t ( ) :
7 pr i nt ( Hel l o World ! )
Source i.: An example using Aspect Oiiented Piogiamming in Python foi tiacing puiposes.
Despite the giowing populaiity of :ov, much of its success seems to be based on the con-
ception that it impioves both modulaiity and the stiuctuie of code, while in fact, it has been
obseived to woik against the piimaiy puiposes of the two, namely independent development
and undeistandability of piogiams, up to the point of iendeiing it as almost paiadoxical [Steoo].
:o n:cxcvoUu
i.i., Domain Specic Ianguages
A domain-specic language (usi) is a piogiamming oi specication language specically de-
signed to suit a paiticulai pioblem domain, iepiesentation technique, and/oi solution tech-
nique [Paio,]. Tey can be eithei (i) visual diagiamming languages, such as Umi, (ii) piogia-
matic abstiactions, such as imi, oi (iii) textual languages, such as sqi.
Te benets of cieating a usi (along with the necessaiy infiastiuctuie to suppoit its intei-
pietation oi execution) may ieveal consideiable whenevei the language allows a moie cleai ex-
piession of a paiticulai type of pioblems oi solutions than pie-existing languages would, and the
type of piobleminquestionieappeais suciently ofen(i.e., iecuiient, eithei ina specic pioject,
like extensive usage of mathematical foimulae, oi global-wise, such as database queiying). But
despite its benets, usi development is haid, iequiiing both domain knowledge and language
development expeitise. Hence, the decision to develop a usi is ofen postponed indenitely, if
consideied at all, and most usis nevei get beyond the application libiaiy stage [MHSo,].
Recently, the teim usi has also been used to coin a paiticulai type of syntactic constiuction
within a geneial puipose language which tends to moie natuially iesemble a paiticulai pioblem
domain, but without actually extending oi cieating a new giammai. Te Ruby community, foi
example, has been enthusiastic in applying this teim to such syntactic sugai. Tis has divided
usis into two dieient categoiies:
External, aie built moie likely a geneiic-puipose language. Tey have its own customsyn-
tax and aie developed with the suppoit of tools such as :1iv [PQ,] oi v:cc [Joh,8],
which take a foimalized giammai (e.g., dened in a meta-syntax such as ni), and genei-
ate paiseis in a suppoited taiget language, such as C. Moie iecent systems, like JetBiains
mvs [Jet:o], piovide MetaIDEs that allows one to design new languages and extend ex-
isting ones along with modein instiumental tools such as an editoi, code completion,
nd usages, debuggei, etc.
Internal, also known as embedded usi, is a technique wheie one uses a host language by
stiictly complying with its giammai, but in a way that it feels it is othei language. As said,
this specic appioach has been iecently populaiized by the Ruby community, although it
is possible to nd eailiei examples in iisv and Smalltalk [Scho,].
Domain-specic languages shaie common design goals that contiast with those of geneial-
puipose languages, in the sense they aie (i) less compiehensive, (ii) moie expiessive in theii do-
main, and (iii) exhibit minimum iedundancy. Language Oiiented Piogiamming [Wai] con-
sideis the cieation of special-puipose languages foi expiessing pioblems as a standaid method-
ology of the pioblem solving piocess.
xiv :ns1v:c1ios :,
i.i.o Meta-Architectures
We have alieady seen seveial techniques used to addiess systems with high-vaiiability needs.
Teie is, nonetheless, dieiences between them. Foi example, some do not paise oi inteipiet
the system denition (meta-data) while it is iunning: Geneiative Piogiamming and Metamod-
eling iely on code geneiation done at compile time. Reection is moie of a piopeity than a
technique by itself, and the level at which it is typically available (i.e., piogiamming language) is
inconvenient to deal with domain-level changes. Domain Specic Languages aie piogiamming
(oi specication) languages cieated foi a specic puipose. Tey aie not geneially tailoied to deal
with change (though they could), and they do iequiie a specic infiastiuctuie in oidei to be
executed.
Meta-aichitectuies aie one of those Humpty-Dumpty woids. Yodei et al. [YBJo:b] dened
it as aichitectuies that can dynamically adapt at iuntime to new usei iequiiement, also known
as ieective aichitectuies. Feiieiia et al. [FAFo] dened it as an aichitectuie of aichitectuies,
i.e., an abstiaction ovei a class of systems which usually iely on ieective mechanisms. Tis
seemingly disagieement is due to the meta piex, which can be undeistood as being applied
to the woid aichitectuie (i.e., an aichitectuie of aichitectuies), oi as a subset categoiization (i.e.,
those aichitectuies that iely on meta mechanisms).
Foi the sake of simplicity, we will always iefei to the lattei meaning hencefoith. Tus, meta-
aichitectuies aie aichitectuies that stiongly iely on ieective piopeities, and usually have the
ability to dynamically adapt to new usei iequiiements duiing iuntime (thiough inteicession).
Both puie object-oiiented enviionments, and MOF-based systems aie examples of such aichi-
tectuies, as they make use of meta-data to cieate dieient levels that sequentially comply to each
othei. But, in these cases, the line that sepaiates what is data and is a systems denition i.e.,
loosely called its model is bluiied, so we need to establish fuithei vocabulaiy conventions.
Whenevei we talk about data (oi instances) we aie diafing a paiallel with M
0
baie infoi-
mation that doesnt piovide stiuctuie. By model we aie iefeiiing to M
1
its stiuctuie gives
meaning to data. By meta-model we aie iefeiiing to M
2
a model to dene models. Te top-
most level doesnt have a name, though; in MOF is called meta-meta-model, due to it being the
thiid model layei. Tis building up of levels (oi layeis), wheie each is diiectly accountable foi
pioviding stiuctuie and meaning to the layei below, iesembles a towei, and so it is also com-
monly called Reective Tower, as depicted in Figuie :.: (p. ,:).
Nonetheless, it should be noted that the piopeity of being reective may actually be iegaided
as the key piinciple of meta-aichitectuies, since systems that adapt theii behavioi do not neces-
saiily iely of meta mechanisms.
Fiom the Lewis Caiiolls uow 1ui v:nni1 uoii, wheie Humpty-Dumpty says to Alice: Vhen I use a word, it
means just what I choose it to mean, neither more nor less.
Fiom Oxfoids Dictionaiy (of a creative work) referring to itself or to the conventions of its genre, self-referential.
:8 n:cxcvoUu
i. nvvnoncnvs
Seveial appioaches and techniques exist to deal with systems with high-vaiiability needs. Te
following sections piovides an oveiview of those most commonly found.
i.. Sonware Product Iines
A sofwaie pioduct line (svi) is a set of sofwaie systems which shaie a common, managed set
of featuies that satisfy the specic needs of a paiticulai maiket segment oi mission and that aie
developed fiom a common set of coie assets in a piesciibed way [CNo:]. Sofwaie pioduct line
development, encompasses sofwaie engineeiing methods, tools and techniques foi suppoiting
such appioach. A chaiacteiistic that distinguishes svi fiom pievious eoits is piedictive veisus
oppoitunistic sofwaie ieuse. Rathei than put geneial sofwaie components into a libiaiy in the
hope that oppoitunities foi ieuse will aiise, sofwaie pioduct lines only call foi sofwaie aitifacts
to be cieated when ieuse is piedicted in one oi moie pioducts in a well dened pioduct line.
i..i Naked Objects
Naked Objects takes the automatic geneiation of giaphical usei inteifaces foi domain models
to the extieme. Tis sofwaie aichitectuial pattein, ist desciibed in Richaid Pawsons Ph.D.
thesis [Pawo] which woik includes a thoiough investigation on piioi known uses and vaiiants
of this pattein, is dened by thiee piinciples:
:. All business logic should be encapsulated onto the domain objects, which diiectly ieect
the piinciple of encapsulation common to object-oiiented design.
:. Te usei inteiface should be a diiect iepiesentation of the domain objects, wheie all usei
actions aie essentially cieation, ietiieval and message send (oi method invocation) of do-
main objects. It has been aigued that this piinciple is a paiticulai inteipietation of an
object-oiiented usei-inteiface (ooUi).
,. Te usei inteiface should be completely geneiated solely fiomthe denition of the domain
objects, by using seveial dieient technologies (e.g., souice code geneiation oi ieection).
i.. Domain-Driven Design
Domain-diiven design (uuu) was coined by Eiic Evans in his books of the same title [Evao,]. It is
anappioach to developing sofwaie foi complex needs by deeply connecting the implementation
Pawsons thesis also contains a contioveisial foiewoid by Tiygve Reenskaug, who ist foimulated the model-view-
contiollei (mvc) pattein, suggesting that Naked Objects is closei to the oiiginal mvc intent than many subsequent
inteipietations and implementations.
In the sense that it is neithei a technology noi a methodology.
:vvvo:cuis :
to an evolving model of the coie business concepts. uuu encompasses a set of piactices and
teiminology foi making design decisions that focus and acceleiate sofwaie piojects dealing with
complicated domains, based on the following piemises:
:. Placing the piojects piimaiy focus on the coie domain and domain logic;
:. Basing complex designs on a model;
,. Initiating a cieative collaboiation between technical and domain expeits to iteiatively cut
evei closei to the conceptual heait of the pioblem.
i.. Model-Driven Engineering
Te teim Model-Diiven Engineeiing (mui) has ioots that go back as :oo: [MMo,] as an answei
to the giowing complexity of system aichitectuies. Tis giowing complexity and the lack of an
integiated view foiced many developeis to implement suboptimal solutions that unnecessaiily
duplicate code, violate key aichitectuial piinciples, and complicate system evolution and quality
assuiance [Schoo].
To addiess these issues, Model-Diiven engineeiing combines domain-specic modeling lan-
guages (usmis) with tiansfoimation engines and geneiatois in oidei to geneiate vaiious types
of aitifacts, such as souice code oi alteinative model denitions. Te usage of usmis ensuies
that the domain model is peifectly captuied in teims of syntax and semantics. Tis guaiantees a
attei leaining cuive as the concepts piesent in the language aie alieady known by the domain
expeits. Tis also helps a bioadei iange of expeits, such as system engineeis and expeiienced
sofwaie aichitects, ensuie that sofwaie systems meet usei needs.
Object-oiiented based mui aie typically metamodeling techniques that stiives to close the
gap between specication aitifacts which aie based upon high-level models, and conciete im-
plementations. A conseivative statement claims that mui tiies to ieduce the eoit of shoitening
(not completely closing) that gap by geneiating code, pioducing aitifacts oi otheiwise inteipiet-
ing models such that they become executable [FRo,]. Pioponents of mui claim seveial advan-
tages ovei tiaditional appioaches [RFBLOo:]:
:. Shorter time-to-market. Since useis model the domain instead of implementing it, focus-
ing on analysis instead of implementation details;
:. Increased reuse. Because the innei woikings aie hidden fiom the usei, avoiding to deal
with the intiicate details of fiamewoiks oi system components;
,. Fewer bugs. Because once one is detected and coiiected, it immediately aects all the
system leading to incieased coheience;
,o n:cxcvoUu
. Easier-to-understand systems and up-to-date documentation. Since the design is the
implementation, not only they nevei fall out of sync, but they aie both the medium and
outcome of design.
One can aigue if these advantages aie exclusive of mui oi just a consequence of iaising the
level of abstiaction :.:., (p. :o). Downsides in typical geneiative mui appioaches include the
delay between model change and model instance execution due to code geneiation, debugging
diculties, compilation, system iestait, installation and conguiation of the new system, which
cantake a substantial time and must take place withinthe development enviionment [RFBLOo:].
Once again, it doesnt seem a paiticulai downside of mui, but a geneial piopeity of noimal
deployment and evolution of typical systems.
Fuithei issues ielated to cuiient mui adoption will be addiessed in Chaptei (p. ). It
seems woithwhile to note that the piex Model-driven seems to be cuiiently seiving as a kind of
umbiella denition foi seveial techniques.
i.., Model-Driven Architecture
Model-diiven aichitectuie (mu:) in an appioach to mui pioposed by the omc, foi the develop-
ment of sofwaie systems [MMo,, OMG:ob]. It piovides a set of guidelines to the conception
and use of model-based specications and may be iegaided as a type of domain engineeiing. It
bases itself onthe Meta Object Facility (moi) [OMG:oa], which mainpuipose is to dene a stiict,
closed metamodeling aichitectuie foi moi-based systems and Umi itself. It piovides foui mod-
eling levels (M
3
, M
2
, M
1
and M
0
), each confoiming to the uppei one (M
3
is in confoimance
to itself).
Like most of the mui piactices, mu: thiives within a complex ecosystem with specialized
tools foi peifoiming specic actions. Moieovei, mu: is typically oiiented foi geneiative ap-
pioaches, using systematic oine tiansfoimation of high-level models into executable aitifacts.
Foi example, tiying to answei mu:s goal of coveiing the entiie gap between specication and
implementation, xUmi was developed [MBo:]. It is a Umi piole which allows the giaphical
iepiesentation of a system, and takes an appioach in which platfoim specic implementations
aie cieated automatically fiom platfoim-independent models, with the use of model compileis.
While some complex paits of mu: allow iuntime adaptivity, developeis seldom acquiie
enough knowledge and piociency of the oveiall technologies to make them cost (and time) ef-
fective in medium-sized applications. Runtime adaptivity may be appioached in dieient ways,
including the use of ieection, and the inteipietation of models at iuntime [RFBLOo:], coveiing
the concept of Adaptive Object-Model see Chaptei , (p. ,,).
:vviic:1io iv:miwovxs ,:
M2
M1
M0
Class Attribute
instanceOf instanceOf
M3 Class
Instance
instanceOf instanceOf instanceOf
classier
+title: string
Video
title = "Matrix"
:aVideo snapshot
instanceOf
Matrix
instanceOf
Figure i.i: Te foui layeis of abstiaction in UML/MOF.
i. nvv::cn1:oN vnnmvwonxs
Object-oiiented fiamewoiks aie both ieusable designs and implementations, that oichestiate
the collaboiation between coie entities of a system [RJo]. While they establish pait of the sys-
tems behavioi, they aie delibeiately open to specialization by pioviding hooks and specializa-
tion points. A fiamewoik usually makes use of the Hollywood Principle', which is known to
piomote high cohesion and low coupling in object-oiiented designs. Te fiamewoik dictates the
aichitectuie of the undeilying system, dening its oveiall stiuctuie, key iesponsibilities of each
component (which togethei foima Comvoi1 Linv:vv), and the main Tuvi:u oi Co1voi.
It captuies design decisions common to its application domain, thus emphasizing design ieuse
ovei code ieuse. Moieovei, it is well known that matuie fiamewoiks can exhibit a ieduction of
up to oof souice code, when compaied to sofwaie wiitten with the suppoit of a conventional
function libiaiy [WGM8, FSJa, FJoo, FSJb].
Some authois though aigue that the development eoit iequiied to pioduce a fiamewoik (as
thus its cost) is extiaoidinaiily highei than the costs of developing a specic application [FPRoo].
And when similai applications alieady exist, they have to be studied caiefully to come up with
an appiopiiate fiamewoik foi that paiticulai domain. Adaptations of the iesulting fiamewoik
lead to an iteiative iedesign. So fiamewoiks iepiesent a long-teim investment that pays o only
if similai applications aie developed again and again in a given domain.
' A clich iesponse given to amateuis auditioning in Hollywood: Dont call us, well call you.
,: n:cxcvoUu
i.. Building Frameworks
Despite the consideiable numbei of successful fiamewoiks developed duiing the last decades,
designing a high-quality fiamewoik is a dicult task. One of the most common obseivations
about successful fiamewoik development is that it iequiies iteiation: Good fiamewoiks aie
usually the iesult of many design iteiations and a lot of haid woik [WBJo].
Te piecise need foi iteiation in fiamewoik development (though a common piactice nowa-
days foi the development of most sofwaie aitifacts) is mainly due to thiee ieasons. Te ist
one is that nding the coiiect abstiactions in immatuie domains is veiy haid. Tis diculty
ofen iesults in mistakes being discoveied only when the fiamewoik is used, which then leads
to ienements and iteiation. Anothei ieason foi iteiating is that the exibility piovided by a
fiamewoik is dicult to ne-tune a piioii, and its evaluation usually iequiies to expeiiment it
in conciete situations. A thiid ieason is that fiamewoiks aie high-level abstiactions, and thus
theii geneiality and ieusability is highly dependent on the oiiginal examples used duiing the
abstiaction piocess.
Despite the impoitance of iteiation in fiamewoik ienement, it would be benecial to have
piocesses able to ieduce the numbei of design iteiations and the eoit spent on fiamewoik ie-
nement. Te lack of matuie piocesses foi developing fiamewoiks is an issue. While fiamewoik
development piocesses get moie and moie matuie, fiamewoik development is consideied (by
some) as an ait, iequiiing both expeiience and expeiimentation [JF88].
Seveial methods have been pioposed in the liteiatuie to suppoit fiamewoik development in
oidei to ieduce the ienement eoit and make it moie piedictable. Some examples of meth-
ods include (i) a pattein language foi evolving fiamewoiks [RJo], (ii) systematic fiamewoik
design by geneialization [Sch,], (iii) hot-spot-diiven development [Pie], (iv) the catalysis
appioach [DW], (v) iole-modeling appioach foi fiamewoik design [RG8], and (vi) the ap-
pioach foi deiiving fiamewoiks fiom domain knowledge [ATMBoo].
All these appioaches dene similai activities foi developing fiamewoiks but diei on the em-
phasis put on some activities and aitifacts used as staiting points. Foi example, [RJo] suggests
staiting fiom conciete applications and abstiact the fiamewoik using iteiative ienements, thus
emphasizing a bottom-up appioach; [ATMBoo], on the othei hand, suggests staiting not fiom
conciete applications, but fiom domain knowledge, thus emphasizing a top-down appioach.
Robeits and Johnson pioposes a pattein language to evolve a fiamewoik [RJo]. Te method
assumes that piimaiy abstiactions aie veiy haid to nd, and theiefoie consideis that seveial
development eoits aie iequiied to achieve a successful fiamewoik. Te method suggests to
stait fiom conciete applications and iteiatively abstiact and iene the fiamewoik fiom those
applications. Te patteins can be found in Figuie :., (p. ,,).
viiiv:1 1oois ,,
Three Examples
White-Box Framework
Component Library
Hot Spots
Pluggable Objects
Fine-Grained Objects
Visual Builder
Language Tools
Black-Box Framework
time
Figure i.: Patteins foi Evolving Fiamewoiks [RJo].
i..i Documenting Frameworks
Aguiai pioposed a minimalist appioach to fiamewoik documentation, which coveied the ovei-
all documentation piocess, fiom the cieation and integiation of contents till the publishing and
piesentation, by focusing on minimizing the obtiusiveness to the leainei of tiaining mateiial,
oeiing the minimal amount of infoimation that the leainei needs to get the task done. It en-
compasses (i) a documentation model to oiganize the contents iequiied to pioduce a minimal-
ist fiamewoik manual along a viitual layeied documentation space, (ii) a piocess which denes
ioles, techniques and activities involved in the pioduction of minimalist fiamewoik manuals,
and (iii) a specic set of tools, convenient to be adopted in a wide iange of sofwaie development
enviionments [Aguo,].
In teims of notation, the Umi piole foi fiamewoik aichitectuies piovides an eniiched Umi
subset, with some Umi-compliant extensions, to allow the annotation of such aitifacts. Tis
piole is called Umi-i and is taigeted to fiamewoik technology [FPRoo].
i., nv:vvnN1 1oo:s
Fiomfull piogiamming languages, to appioaches and fiamewoiks, seveial tools to suppoit them
alieady exist, which aie somewhat capable to addiess incomplete by design systems. Te list that
follows is not meant to be exhaustive, but iathei representative of existing technology, eithei due
to ielevant paiticulaiities oi just by sheei populaiity in this context.
, n:cxcvoUu
i.,. Wikis
Eailiei in :,, Cunninghamwiote a set of sciipts that allowed collaboiative editing of webpages
inside the veiy same biowsei used to view them [Cun,]. He named this system VikiVikiVeb,
due to the analogy between the meaning of the woid wiki quick and the undeilying phi-
losophy of its cieation: a quick-web. Since then, wikis'' have giadually become a populai tool on
seveial domains, including that of sofwaie development, e.g., to assist the cieation of lightweight
sofwaie documentation [Aguo,]. Tey ease collaboiation, piovide geneialized availability of in-
foimation, and allowthe combination of dieient types of content, e.g., text, images, models, and
code, in a common substiate [ADo,].
One may similaily iegaid modein development and usage of sofwaie systems as incieasingly
collaborative. Te undeilying design and the knowledge that lead to it (e.g., iequiiements, use-
cases, models) is mostly devised and shaied between both developeis and stakeholdeis. Data is
collaboiatively viewed and edited among useis. But usually these ciicles developeis and useis
seem to be iegaided as disjoint, wheie the emeigent knowledge fiom this collaboiation begin
and end towaids the synthesis of the aitifacts themselves, despite the fact they have and aie
built inciementally.
Reecting on the oveiall success of wikis, it seems to be ielated to a set of design piinciples
diafed by Cunningham [Cuno,]. Specically, wikis shaie a common set of piopeities, viz.: (i)
open, (ii) inciemental, (iii) oiganic, (iv) univeisal, (v) oveit, (vi) toleiant, (vii) obseivable, and
(viii) conveigent. Te undeilying iational behind these piinciples exhibit a constiuctionist atti-
tude towaids change and incompleteness instead of iegaiding the incompleteness of infoima-
tion as a defect, they embiace it as the means thiough which the system evolves, in a continuous
fulllment of its function. Atiansposition of this cential notion to collaborative epistemology can
be found in Suiowieckis Te Wisdomof Ciowds [Suio,], and once the fundamental iational is
set, the same undeilying piinciples can be applied to othei computational systems as well. Tis
attitude towaids incompleteness will be fuithei exploied in o.:.: (p. o).
i.,.i Smalltalk
Smalltalk is a puie' object-oiiented, dynamically typed, ieective piogiamming language, de-
signed and cieated foi constiuctionist leaining, led by Alan Kay and Dan Ingalls at the Xeiox
Palo Alto Reseaich Centei (v:vc) [Kay,].
'' Afei the cieation of the VikiVikiVeb, seveial new sites and systems oi engines emeiged based on the same
undeilying piinciples, and aie geneially called wikis. Among them is the well-known Vikipedia [Wik:od], based
on the MediaViki [Medo,] engine.
' Puie object-oiiented languages diei fiom hybrids, like Java and C++, in the sense theie is no fundamental
dieience betweenobjects and piimitive types. Unlike Smalltalk, piimitive types inJava weie eithei stoied diiectly
in elds (foi objects) oi on the stack (foi methods) iathei than on the heap, piioi to v.,.o. Moie iecently, piimitive
types aie automatically boxed a technique that allows piimitives to be tieated as instances of theii wiappei class.
viiiv:1 1oois ,,
One key piopeity to Smalltalk is being both stiuctuially and computationally ieective, up
to the point that both the compilei and viitual machine (vm) aie accessible to the applica-
tion [GR8,]. Foi example, whenevei the usei entei textual souice code, this is typically com-
piled into method objects that aie instances of CompiledMethod, and subsequently added to
the taiget class method dictionaiy. New class hieiaichies aie cieated by sending a message to
the paient class. Even the Integiated Development Enviionment (iui) is iunning fiom within
the Smalltalk vm, making extensive usage of introspection to nd implemented methods, classes,
elds, etc. and assist the usei with code-completion and unit-testing, among otheis. Unlike Java oi
C-, piogiammeis usually dont oiganize theii code in textual les and pioceed with a full com-
pilation. Instead, they inciementally modify and extend the system duiing iun-time, stoiing the
entiie vm state in an image le [NDPo].
1 doesNotUnderstand : aMessage
2 ^t ar ge t
3 perf orm : aMessage s e l e c t o r
4 withArguments : aMessage arguments
Source i.,: Example of an implementation of the Pioxy pattein in Smalltalk.
Anothei ielevant piopeity of Smalltalk w.i.t. incompleteness is the way methods aie (not) in-
voked iathei a message is sent to the taiget object. If the taiget object doesnt implement the
expected method, the full message is ieied as an aigument, and sent as a doesNotUnderstand:
message. In a Smalltalk iui, the default implementation is to open an eiioi window, wheie
the usei could inspect and redene the oending code, and simply continue fiom that point
onwaid [NDPo]. Alteinatively, one can cieate an object iedening the doesNotUnderstand:
default behavioi, eectively implementing the Pvoxv pattein [GHJV], as seen in Souice :.,.
i.,. Ruby on Rails
Ruby on Rails (vov) is a full-stack web fiamewoik, initially developed by David Hansson in :oo,,
based on the mvc pattein. Accoiding to Hansson, vovs goal is for programmers happiness and
sustainable productivity [letting] you write beautiful code by favoring convention over congura-
tion [Han]. vov takes a lot of its piopeities fiom Rubys metapiogiamming capabilities, exem-
plied in Souice :.o (p. ,o), heavily inspiied in LISPand Smalltalk [THB
+
oo]. Despite that, vovs
cuiient veision takes an appioach much closei to geneiative piogiamming than inteicession
see :.:., (p. :o) and :.:.: (p. :,).
Regaiding code geneiation, the vov fiamewoik includes a seiies of mechanisms foi system
aitifacts geneiation, viz. models, contiolleis and views. It does so by analyzing the undeilying
ielational database model and deiiving the object-oiiented specications fiom available meta-
infoimation (e.g., columns type, name, foieign keys, etc.). Instead of geneiating a static model
,o n:cxcvoUu
1 c l a s s Greeti ng
2 def i n i t i a l i z e ( t ext )
3 @text = t ext
4 end
5 def welcome
6 @text
7 end
8 end
9
10 my_object = Greeti ng . new( Hel l o )
11 my_object . c l a s s # Greeti ng
12 my_object . c l a s s . i nstance_methods ( f a l s e ) # [ : welcome ]
13 my_object . i ns t anc e _var i abl e s # [ : @text ]
Source i.o: Example of an implementation of the Pioxy pattein in Ruby.
denition, vov deduces the necessaiy infoimation whenevei the systemis loaded, and geneiates
an adequate code skeleton foi basic cvUu opeiations in views'`, gieatly acceleiating the devel-
opment piocess by pioviding the developeis with a basic bluepiint of a fully functional system
that can be subsequently iened and tailoied foi specic needs [THB
+
oo].
i.o coNc:cs:oN
Tis chaptei has mainly focused on ielated woik to this disseitation, summaiizing the state-of-
the-ait in the backgiound themes. One way to design sofwaie capable to cope with incomplete-
ness and change is to encode the systems concepts into highei-level iepiesentations, which could
then be systematically synthesized into executable aitifacts. To coiiectly captuie and expiess
these high-level iepiesentations, one must coiiectly identify the commonalities and vaiiability
of the system, and suppoit the coiiect degiee of adaptivity and/oi adaptability. Techniques such
as metapiogiamming, metamodelling, geneiative piogiamming, and domain specic languages,
among otheis, weie desciibed and theii potential inteiest in this disseitation analyzed. Existing
tools and infiastiuctuies, such as wikis and dynamic languages, also seived as examples foi the
study of the aichitectuie and design of these kind of systems. Te next chaptei will now focus
specically on the state-of-the-ait of Adaptive Object-Models.
'` A piocess known as scaolding.
Chapter
State of the Art in Adaptive Object-Models
. Te AOM Architectural Pattern . . . . . . . . . . . . . . . . . . . . . . . . ;
.i Formalized Patterns for AOM . . . . . . . . . . . . . . . . . . . . . . . . .
. Dierences from other Approaches . . . . . . . . . . . . . . . . . . . . . . ;
. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
In seaich foi exibility and iun-time adaptability, many developeis had systematically applied
code and design ieuse of paiticulai domains, eectively constiucting highei-level iepiesenta-
tions (oi abstiactions). Foi example, some implementations have theii data stiuctuie and do-
mainiules extiacted fiomthe code and stoied exteinally as modiable paiameteis of well-known
stiuctuies, oi statements of a usi. Tis stiategy giadually tiansfoims some components of the
undeilying system into an inteipietei oi viitual machine whose iun-time behavioi is dened by
the paiticulai instantiation of the dened model. Changing this model desciiption iesults on
the system following a dieient business domain model. Whenevei we apply these techniques
to object-oiiented design and piinciples, we usually conveige to an aichitectuial style known as
the Adaptive Object-Model (:om) [YBJo:b].
. 1nv nom nncn:1vc1cnn: vn11vnN
An Adaptive Object-Model may be dened as (i) a class of systems aichitectuies, i.e., an ai-
chitectuial style, (ii) based on metamodeling and object-oiiented design, (iii) ofen ielying in
Domain Specic Languages (usi), (iv) typically having the piopeity of being ieective, and (v)
specially tailoied to expose its domain model to the end-usei. Because it is an abstiaction ovei
a set of systems and techniques, iesulting into a common abstiact aichitectuie, it is called an
aichitectuial pattein.
,8 s1:1i oi 1ui :v1 i :u:v1ivi on,ic1-mouiis
Some liteiatuie also classies the :om as a meta-aichitectuie, due to its coie usage of meta-
piogiamming and metamodeling [YBJo:b]. In fact, the evolution of the coie aspects of a :om
(and its associated vocabulaiy) can be obseived by the bioad nomenclatuie used in the liteiatuie
in the past, e.g., Type Instance [GHV,], User Dened Product Architecture [JO8], Active Object-
Models [YFRT8] and Dynamic Object Models [RD8]. As theoiies and technology ciystallize,
the nomenclatuie begins to solidify, but it is an empiiical obseivation of the cuiient liteiatuie
that that phase has not yet been achieved.
.. Why is it a Pattern:
When building systems, theie aie iecuiient pioblems that have pioven, iecuiient solutions, and
as such aie known as patterns [AIS,,]. Tese patteins aie piesented as a thiee-pait iule, that
expiesses a ielation between a ceitain context, a pioblem, and a solution. A sofwaie design
pattein addiesses specic design pioblems specied in teims of inteiactions between elements
of object-oiiented design, such as classes, ielations and objects [GHJV]. Tey aient meant to
be applied as-is; iathei, they piovide a geneiic template to be instantiated in a conciete situation,
as discussed in :., (p. ).
Te concept of Adaptive Object-Model is inheiently coupled with that of an aichitectuial
pattein [BMR
+
o], as it is an eective, documented, and piesciiptive solution to the follow-
ing iecuiient pioblem: how to allow the end-user to modify the domain model of the system
while it is running? It should theiefoie be noted that most :om emeige fiom a bottom-up pio-
cess [YBJo:b], iesulting in systems that will likely use a subset of its concepts and piopeities, only
when and wheie they aie needed. Tis is in absolute contiast with top-down eoits of specic
meta-modeling techniques (e.g., Model-Diiven Aichitectuie) wheie the whole infiastiuctuie is
specically designed to be as geneiic as possible (if possible, to completely abstiact the undeily-
ing level).
..i Towards a Pattern Ianguage
Te giowing collection of :om-ielated patteins [WYWBo, FCWo8, WYWBo,] which is foim-
ing a domain pattein language [WYWBJo,], is cuiiently divided into six categoiies, viz. (a)
Coie, which denes the basis of a system, (b) Cieational, used foi cieating iuntime instances,
(c) Behavioial, (d) GUI, foi pioviding human-machine inteiaction, (e) Piocess, to assist the cie-
ation of a :om, and (f) Instiumental, which helps the instiumentation. Te ist diaf of this
pattein language was done by Welicki et al. [WYWBJo,], and is summaiized in Figuie ,.: (p. ,)
and Table ,.: (p. o).
1ui :om :vcui1ic1Uv:i v:11iv ,
T
y
p
e
S
q
u
a
r
e
D
y
n
a
m
i
c
H
o
o
k
s
S
t
r
a
t
e
g
y
T
y
p
e
C
u
b
e
R
u
l
e
O
b
j
e
c
t
R
u
l
e
E
n
g
i
n
e
I
n
t
e
r
p
r
e
t
e
r
B
u
i
l
d
e
r
E
d
i
t
o
r
/
V
i
s
u
a
l
L
a
n
g
u
a
g
e
A
O
M
B
u
i
l
d
e
r
D
e
p
e
n
d
e
n
c
y
I
n
j
e
c
t
i
o
n
D
y
n
a
m
i
c
F
a
c
t
o
r
y
T
y
p
e
O
b
j
e
c
t
P
r
o
p
e
r
t
i
e
s
A
c
c
o
u
n
t
a
b
i
l
i
t
y
N
u
l
l
O
b
j
e
c
t
V
a
l
u
e
O
b
j
e
c
t
S
m
a
r
t
V
a
r
i
a
b
l
e
s
E
n
t
i
t
y
V
i
e
w
P
r
o
p
e
r
t
y
R
e
n
d
e
r
e
r
D
y
n
a
m
i
c
V
i
e
w
s
G
U
I
W
o
r
k
o
w
m
a
n
a
g
e
s
m
a
y
-
u
s
e
m
a
y
-
u
s
e
c
o
o
r
d
i
n
a
t
e
s
u
s
e
s
u
s
e
s
u
s
e
s
s
u
p
p
o
r
t
s
s
u
p
p
o
r
t
s
r
e
n
d
e
r
s
m
a
n
a
g
e
s
p
r
o
c
e
s
s
e
x
t
e
n
d
s
m
a
n
a
g
e
s
e
x
t
e
n
d
s
e
x
t
e
n
d
s
d
e
s
c
r
i
b
e
s
e
x
t
e
n
d
s
u
s
e
s
u
s
e
s
s
u
p
p
o
r
t
s
u
s
e
s
u
s
e
s
c
o
n
t
r
o
l
s
e
x
t
e
n
d
s
C
a
c
h
i
n
g
C
o
n
t
e
x
t
O
b
j
e
c
t
B
e
h
a
v
i
o
r
a
l
G
U
I
C
o
r
e
C
r
e
a
t
i
o
n
a
l
I
n
s
t
r
u
m
e
n
t
a
l
V
e
r
s
i
o
n
i
n
g
H
i
s
t
o
r
y
h
e
l
p
s
B
o
o
t
s
t
r
a
p
p
i
n
g
Figure .: Pattein map of design patteins and concepts ielated to Adaptive Object-Models. Adapted fiom
[WYWBJo,].
o s1:1i oi 1ui :v1 i :u:v1ivi on,ic1-mouiis
C:1icovv P:11ivs
Coie Tvvi SqU:vi, Tvvi On,ic1, Pvoviv1iis, AccoU1:niii1v, V:iUi On,ic1,
NUii On,ic1, and Sm:v1 V:vi:niis
Cieational BUiiuiv, AOM BUiiuiv, Dv:mic F:c1ovv, Boo1s1v:vvic, Diviuicv
I,ic1io, and Eui1ov / VisU:i L:cU:ci
Behavioial Dv:mic Hooxs, S1v:1icv, RUii On,ic1, RUii Ecii, Tvvi CUni, and
I1ivvvi1iv
GUI Pvoviv1v Riuiviv, E1i1v Viiw, Dv:mic Viiw, and GUI Wovxiiow
Piocess Dom:i Sviciiic Ans1v:c1io, Simvii Svs1im, Tuvii Ex:mviis, Wui1i
Box Fv:miwovx, Bi:cx Box Fv:miwovx, Comvoi1 Linv:vv, Ho1
Svo1s, PiUcc:nii On,ic1s, Fii-Gv:iiu On,ic1s, VisU:i BUiiuiv, and
L:cU:ci Toois
Instiumental Co1ix1 On,ic1, Vivsioic, His1ovv, and C:cuic
Table .: A pattein catalog foi Adaptive Object Models, adapted fiom [WYWBJo,].
Core AOM Patterns
Te following patteins dene the stiuctuial and behavioial basis of any :om system:
Type Object. As desciibed by Johnson et al. [JW,] and Yodei et al. [YBJo:b], a Tvvi-
On,ic1 decouples instances fiom theii classes so that those classes can be implemented
as instances of a class. TvviOn,ic1 allows new classes to be cieated dynamically at iun-
time, lets a system piovide its own type-checking iules, and can lead to simplei, smallei
systems.
Property. Te Pvoviv1v pattein gives a dieient solution to class attiibutes. Instead of be-
ing diiectly cieated as seveial class vaiiables, attiibutes aie kept in a collection, and stoied
as a single class vaiiable. Tis makes it possible foi dieient instances, of the same class,
to have dieient attiibutes [Fowo].
Type Square. Te combined application of the TvviOn,ic1 and Pvoviv1v patteins iesult
in the TvviSqU:vi pattein [Fowo]. Its name comes fiom the iesulting layout when iep-
iesented in class diagiam, with the classes Entity, EntityType, Attribute and Attribute-
Type.
Accountability. Is used to iepiesent dieient ielations between paities using an Ac-
coU1:niii1vTvvi to distinguish between dieient kinds of ielation [Fowo, Aisoo].
Composite. Tis pattein consists of a way of iepiesenting pait-hole hieiaichies with the
Rule and CompositeRule classes [JW,].
iovm:iiziu v:11ivs iov :om :
Strategy. Stiategies aie a way to encapsulate behavioi, so that it is independent of the
client that uses it. Rules aie Stiategies, as they dene behavioi that can be attached to a
given EntityType [JW,].
Rule Object. Tis pattein iesults fiom the application of the Comvosi1i and S1v:1icv
patteins, foi the iepiesentation of business iules by combining simplei elementaiy con-
stiaints [WYWBJo,].
Interpreter. An :om consists of a iuntime inteipietation of a model. Te I1ivvvi1iv
pattein is used to extiact meaning fiom a pieviously dened usei iepiesentation of the
model [JW,].
Builder. Amodel used to feed a :om-based systemis inteipieted fiomits usei iepiesenta-
tion and a iuntime iepiesentation of it is cieated. Te BUiiuiv pattein is used to sepaiate
a models inteipietation fiom its iuntime iepiesentation constiuction [JW,].
Patterns of Graphical User Interface
Te patteins in [WYWBo,] focus specically on Usei Inteiface (Ui) geneiation issues when deal-
ing with :om. In tiaditional systems, data piesented in usei inteifaces is usually obtained fiom
business domain objects, which aie thus mapped to Ui elements in some way. In a :om business
objects exist undei an additional level of indiiection, which has to be consideied. In fact, it can
be taken into oui advantage, as the existing meta-infoimation, used to achieve adaptivity, can be
used foi the same puipose iegaiding usei inteifaces. Usei inteifaces can this way be adaptive to
the domain model in use.
Property Renderer. Desciibes the handling of usei-inteiface iendeiing foi dieient types
of piopeities.
Entity View. Explains how to deal with the iendeiing of EntityTypes, and how Pvoviv-
1vRiuivivs can be cooidinated foi that puipose.
Dynamic View. Appioaches the iendeiing of a set of entities consideiing layout issues and
the possibility of cooidinating E1i1vViiws and Pvoviv1vRiuivivs in that iegaid.
.i vonmn::zvu vn11vnNs von nom
Te basic aichitectuie of a :ommay be divided into thiee paits oi levels that ioughly coiiespond
to the levels piesented by moi: M
0
is the opeiational level, wheie system data is stoied, M
1
is
the knowledge level wheie infoimation that denes the system(i.e., the model) is stoied, and M
2
is the design of oui suppoiting infiastiuctuie. M
0
and M
1
aie vaiiants of oui system. M
2
is an
: s1:1i oi 1ui :v1 i :u:v1ivi on,ic1-mouiis
invaiiant, i.e., the meta-model should it need to change, we would have to tiansfoimM
0
and
M
1
to be compliant with the new denition. See Figuie :.: (p. ,:) and Figuie ,.:.
M2
M1
M0
John Doe
Person
Entity EntityType
instanceOf
instanceOf
instanceOf
0..*
Figure .i: Te meta layeis of an :om, when compaied to moi.
We may say that the key to good sofwaie design is two-fold: (a) iecognize what changes,
and (b) iecognize what doesnt change; it is the seaich foi patterns and invariants. Te following
patteins tiy to anticipate what will be the taiget of continuous change, and encapsulate it ac-
coidingly. Te ist patteins, viz. TvviOn,ic1, Pvoviv1v, TvviSqU:vi, and AccoU1:niii1v
captuie the stiuctuial coie of an AOM.
Additional, some stiuctuial iules such as (i) legal subtypes, (ii) legal types of ielationships
between entities, (iii) caidinality of ielationships and, and (iv) mandatoiy piopeities, can be
captuied thiough simple extensions of these patteins, as will be discussed in Chaptei , (p. o:)
and Chaptei o (p. ,). Moie complex iules will iequiie the usage of othei patteins, viz. Com-
vosi1i, RUiiOn,ic1, S1v:1icv and I1ivvvi1iv.
.i. Type-Object Pattern
In the context of object-oiiented piogiamming and analysis, the type of eveiy object is dened
as a class, and its instance as an object which confoims to its class. Atypical implementation of a
sofwaie systemwould haidcode into the piogiamstiuctuie, i.e., its souice-code, eveiy modeled
entity, such as the concept of a patient. Whenevei the systemneeds to be changed, e.g., to suppoit
a new entity, the souice-code has to be modied.
Howevei, if one anticipate this change, objects can be geneialized and theii vaiiation de-
sciibed as paiameteis, just like one can make a function that sums any two given numbeis ie-
gaidless of theii actual value. Te TvviOn,ic1 pattein, depicted in Figuie ,., (p. ,), identies
that solution, which involves splitting the class in two: a type named Entity Type, and its in-
stances, named Entity [JW,].
iovm:iiziu v:11ivs iov :om ,
Identier {unique}
Entity
Identier {unique}
Name: string
Abtract: bool
Entity Type
Identier = 001
Name = "Patient"
Abstract = False
Patient
Identier = 001
John Doe
instanceOf
instanceOf
model-level
data-level
parent
0..1
0..*
Figure .: A class diagiam of the Tvvi-On,ic1 pattein.
Using this pattein, patients now become instances of Entity Types they become meta-
data. Te actual system data, such as the patient john Doe, is now iepiesented as instances of
Entity. Because both data and meta-data aie dened and stoied independently of the piogiam
stiuctuie, they aie allowed to change duiing iun-time.
Teie aie some vaiiations to this solution; foi example, an optional ielation between Entity-
Types can suppoit the notion of inheiitance, which will incidentally be a solution to the pioblem
of open-inheiitance, as ist discussed in Chaptei : (p. :). Piovided sucient mechanisms ex-
ists to allow the end-usei customization of the model, new specializations can be added without
modifying the souice-code.
.i.i Property Pattern
We face a veiy similai pioblemto the TvviOn,ic1, when dealing with the attiibutes of an object,
such as the name and age of a patient. Once again, these aie usually classied as elds of a class,
and its values stoied in the object. Te anticipation of change leads to the Pvoviv1v pattein; a
similai bi-section between the denition of a piopeity and its coiiesponding value is depicted
in Figuie ,..
Identier {unique}
Value
Property
Identier {unique}
Name: string
Property Type
Identier = 001
Name = 'Age'
: Property Type
Identier = 001
Value = 23
: Property
instanceOf
instanceOf
model-level
data-level
Figure .: A class diagiam of the Pvoviv1v pattein.
Using this pattein, the seveial attiibutes of the domains entities become instances of Prop-
erty Types, and theii paiticulai values instances of Property. Again, this technique solves the
s1:1i oi 1ui :v1 i :u:v1ivi on,ic1-mouiis
pioblem of adding (oi iemoving) moie infoimation to existing entities beyond those oiiginally
designed, without touching the souice-code.
.i. Type-Square Pattern
Te two pievious patteins, TvviOn,ic1 and Pvoviv1v, aie usually used in conjunction, iesult-
ing in what is known as the Tvvi-SqU:vi pattein the veiy stiuctuial coie of a :om, and de-
picted in Figuie ,.,. It is impoitant to note that the diagiam has instance elements iepiesenting
both the systems data and model, while the classes iepiesent the static, abstiact infiastiuctuie.
Property
Property Type
Entity
Entity Type
Age
23
Patient
John Doe
Figure .,: A class and objects diagiam of the Tvvi-SqU:vi pattein. Te outei foui elements aie classes
iepiesenting the systems infiastiuctuie. Te innei foui elements aie objects iepiesenting an
example instantiation of a paiticulai domain.
.i. Accountability Pattern
Attiibutes aie piopeities that iefei to piimitive data types like numbeis oi stiings. Othei possible
type of piopeities aie associations between two (oi moie) entities. Foi example, if Sue is the
mothei of John, then Sue e John aie ielated thiough the paienthood ielationship. Teie aie
seveial ways to iepiesent a ielationship using the Pvoviv1v pattein. One way is to inheiit fiom
property and make the sepaiation fiom attiibutes and ielations. Anothei way is to duplicate the
Pvoviv1v pattein, using it once foi attiibutes and once foi associations. Finally, the distinction
can be made by inspection of the value type: piimitive data types will iepiesent attiibutes, and
model types would iepiesent ielations [Yodo:].
Te most common pattein in the context of :omis the duplication of the Pvoviv1v pattein,
by modifying it to become the AccoU1:niii1v pattein [Fowo, Aisoo]. Tis pattein is usually
implemented as two classes, the AccountabilityType, which iepiesents the type of the ielation
(e.g. paienthood) and is pait of the EntityType, and the Accountability, which holds the
values pointing to the Entities that paiticipate in the ielation. Figuie Figuie ,.o (p. ,) depicts
the application of this pattein to :om, although theie aie slight vaiiations, including the P:v1v
pattein [Fow,].
iovm:iiziu v:11ivs iov :om ,
Target
Accountability
Name: string
AccountabilityType
Identier = 001
Sue :Entity
Identier = 001
John :Entity
instanceOf
instanceOf
model-level data-level
Name = 'Parenthood'
:AccountabilityType
Role = 'Child'
:Accountability
Role = 'Mother'
:Accountability
instanceOf
Figure .o: A class and objects diagiam of the AccoU1:niii1v pattein, foiming the stiuctuie of the ie-
lationship between two entities.
.i., Composite Pattern
Evaluate()
Leaf
Evaluate()
Rule
Type = '&'
andOperator
Type = '<'
lessThanOperator
instanceOf
model-level data-level
Evaluate()
Composite Rule
Name = Bound
Property :Leaf
Name = 'Age'
Property :Leaf
Value = '30'
Constant :Leaf
instanceOf
Figure .;: Aclass and objects diagiamof the Comvosi1i pattein, foiming the stiuctuie of the pait-whole
hieiaichy of a :s1 foi the expiession Age 30 ^Bound.
Considei the following iule: the value of a specic piopeity (i) of an object must be gieatei
than o and less than :o (0 i 10). We may expiess this iule as a conjunction of two simplei
iules, namely that (0 i ^i 10). Usually, this type of expiessions aie paised into an Abstiact
Syntax Tiee (:s1), with opeiatois as nodes, and eective values as leafs. Although each node
may be iecuisively evaluated, the piecise semantics given to this evaluation belongs to the node
itself. Fiom the client point-of-view (i.e., the usei of the expiession), mostly it wants to tieat
individual objects and compositions of objects unifoimly. Composite can thus be used to this
piopose, as seen in Figuie ,.,, explicitly ignoiing the dieiences between compositions of objects
and individual objects [GHJV]. Tis pattein is used to suppoit the I1ivvvi1iv pattein as
seen in ,.:., (p. o).
o s1:1i oi 1ui :v1 i :u:v1ivi on,ic1-mouiis
.i.o Strategy and Rule Object Patterns
Considei the following iule: the value of a specic piopeity is mandatoiy. Teie aie two com-
monways tosuppoit this iule ina :om, namely (i) toadda booleaneldto the Pvoviv1v pattein,
specifying if that paiticulai piopeity is mandatoiy, and (ii) to dene a family of algoiithms and
encapsulate each one as a iule (e.g., MandatoryProperty), and call them whenevei an Entity is
validated. Because iules aie encapsulated into objects, it makes them inteichangeable. Te lattei
foim the basis of the S1v:1icv [GHJV] a RUii On,ic1 [Aisoo] when applying to :om, and
an example can be seen in Figuie ,.8.
Validate()
Mandatory
Validate()
Rule
1 Validate()
PatternMatch
Validate()
EntityType
Name: string
PropertyType
0..*
Figure .8: Aclass diagiamof the S1v:1icv and RUii On,ic1 patteins, foiming the stiuctuie of the family
of algoiithms foi enfoicing iules. Te dashed line iepiesents an invocation call.
.i.; Interpreter Pattern
As seen in ,.:., (p. ,), the iule the value of a specic piopeity of an object (i) must be gieatei
than o and less than :o (0 i 10), may be specied using an expiession dened as a simple
language, which will then use (oi be tiansfoimed into) RUii On,ic1s as desciibed in ,.:.o.
Foi that, a iepiesentation of the giammais language along with the inteipietei that uses the iep-
iesentation to inteipiet sentences in that same language, can be stiuctuied as a Comvosi1i of
objects, iesulting in the I1ivvvi1iv pattein [GHJV]. See both Figuie ,., (p. ,) and Fig-
uie ,.
Interpret(Context)
Leaf
Interpret(Context)
AbstractExpression
Interpret(Context)
Composite Rule
ExecuteRules()
EntityType
Context
Figure .p: A class diagiam of the I1ivvvi1iv pattein, foiming the stiuctuie of an expiession language.
uiiiivicis ivom o1uiv :vvvo:cuis ,
.i.8 Composing the Patterns
Te usual aichitectuie of an Adaptive Object-Model is usually the pioduct of applying one oi
moie of the pieviously mentioned patteins in conjunction with othei object-oiiented design
patteins, such as the F:c1ovv Mi1uou and BUiiuiv [GHJV, Yodo:]. One such typical ai-
chitectuie can be seen in Figuie ,.:o.
Nonetheless, mixing up patteins do not piovide any conciete implementation of an :om, and
neithei it points to what a fiamewoik foi :om would look like (in teims of its foim). Yodei et
al. pointed to the fact that every Adaptive Object-Model is a framework of a sort but there is
currently no generic framework for building them [Yodo:]. In Chaptei o (p. ,), the aichitectuie
and design of such fiamewoik will be pioposed, and an implementation will be detailed.
CompositeRule
Accountability
Entity
Attribute
Accountability
Type
EntityType
AttributeType
Rule
Constraint
TableLookup BinaryOperation
*
*
Operational Level Knowledge Level
Behavioral Level
Figure .o: AOM coie aichitectuie and design, adapted fiom [YBJo:b].
. u:vvvnvNcvs vnom o1nvn nvvnoncnvs
Te concepts of end-user programming and conned variability the capability of allowing the
systems useis to intioduce changes and thus contiol eithei pait of, oi the entiie, systems behavioi
aie signicant consequences of the :om aichitectuie which aie not easily ieconcilable with
othei techniques such as Generative Programming.
In pievious sections, both Generative Programming :.:.: (p. :,) and Metamodel-
ing :.:., (p. :) techniques weie mentioned and biiey desciibed as ways to addiess systems
with high-vaiiability needs. In this context, we may nowbegin to answei in what ways they diei
fiom Adaptive Object-Models.
8 s1:1i oi 1ui :v1 i :u:v1ivi on,ic1-mouiis
Peihaps the most impoitant dieience is when i.e., at what time they paise oi intei-
piet the system denition. Both Geneiative Piogiamming and Metamodeling typically iely on
code geneiated at compile time. On the othei hand, the :om inteipiet the undeilying system
denition duiing iuntime. Tis dieience allows a :om to adapt to new, oi changed, usei ie-
quiiements without having to tuin down the system because of iecompilation [YBJo:a]. Tis
dieience may also distinguish the :om aichitectuial style fiom typical c:si tools. It also leads
to what is heie dened as conned vaiiability, oi the ability of allowing the end-user, typically
referred as change agent, to introduce controlled changes in specic points of the application. Sys-
tems based on the :om aichitectuie elegantly suppoit this type of iequiiements since the ability
to inteipiet changes is built into the system.
Anothei, though denitely moie open to aigumentation, is that the design of Adaptive
Object-Models is done fiombottom-up [YBJo:b]. Tis bottom-up appioach caiiies the piomise
of being able to inciementally evolve a standaid iigid design towaids a moie exible one a step-
by-step fashion. As a iesult, the iesulting system tends to only use such concepts and techniques
wheie (and when) it is most needed, thus slowly tiansfoiming iigid code into adaptable compo-
nents. When compaied to the top-down appioach of othei metamodeling techniques wheie the
whole system is thought to be as geneiic as possible, this piopeity can ieduce the oveiall com-
plexity needed to achieve adaptability, and theiefoie inciease its adoption in typical development
cycles.
. coNc:cs:oN
Te Adaptive Object-Model meta-aichitectuial style can be dened as a class of systems aichi-
tectuies based on metamodeling, meta-piogiamming and object-oiiented design that, ielying
on seveial techniques, have the piopeity of being ieective and specially tailoied to allow the
end-usei to make changes to the domain model. Te theoiies and techniques behind the :om
style have been captuied as patteins, and iecently a pattein language staited to be diafed. In
that pioposal, almost thiity patteins weie identied and divided into six categoiies. So fai, less
than a dozen of them weie piopeily foimalized in the context of :om.
In this chaptei we have ieviewed the cuiient state-of-the-ait iegaiding adaptive object-
models, and some of the patteins that have alieady been foimalized. Te typical aichitectuie
of a :om is the iesult of applying seveial of these patteins in conjunction with othei object-
oiiented design piinciples. Yet, at least two issues iemain open, viz. (i) most of the patteins
iegaiding the :om iemain to be foimalized, and peihaps not all of them weie identied, (ii)
theie is cuiiently no geneiic fiamewoik foi building :om-based systems and (iii) no iigoious
empiiical study piesenting evidence of any specic benets of :omexists in the liteiatuie. Tese
issues will be addiessed in Chaptei , (p. o:) and Chaptei o (p. ,).
Chapter
Research Problem
. Epistemological Stance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,o
.i Fundamental Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,o
. Tesis Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,i
. Specic Research Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,,
., Validation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,8
.o Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,8
Te Adaptive Object-Model and its ecosystem is composed of aichitectuial and design patteins
that piovide domain adaptability to object-oiiented based systems. As patteins, they have been
iecuiiently obseived and systematically documented [Yodo:]. A pattein language has been
pioposed, identifying almost thiity patteins, divided into six dieient categoiies [WYWBJo,].
Howevei, less than a dozen have yet been foimalized, and theie is stiong evidence that not all
of them have been identied. Likewise, no geneiic fiamewoik' intended foi the constiuction
of :om-based systems have been found in the liteiatuie so fai [Yodo:]. Fuithei, no iigoious
empiiical study suppoiting claims about any kind of benets oi liabilities of :om exists in the
liteiatuie, despite the fact that it is a pattein. In this chaptei, we will iaise seveial ieseaich ques-
tions about the benets of mui in geneial, and :om in paiticulai, aigue what kind of validation
should be used to suppoit common claims, point to what should be the baseline foi puisuing em-
piiical studies, and undeiline the need to design contiolled expeiiments as iepeatable packages
foi independent validation.
' Tis may sound as a contiadiction, as fiamewoiks aie usually domain-specic. Teiefoie, a :om-fiamewoik
used to implement a complete :om-oiiented system would call foi a top-down appioach, which was pointed as a
disadvantage in the pievious chaptei. We will see ahead that such consideiation will shape the fiamewoik design.
,o visi:vcu vvoniim
. vv:s1vmo:oo:cn: s1nNcv
In oidei to undeistand the way sofwaie engineeis build and maintain complex and evolving
sofwaie systems, ieseaicheis need to focus beyond the tools and methodologies; they need to
delve into the social and theii suiiounding cognitive piocesses vis-a-vis individuals, teams, and
oiganizations. In this sense, ieseaich in sofwaie engineeiing is iegaided as inheiently coupled
with human activity, wheie the value of geneiated knowledge is diiectly linked to the methods
by which it was obtained.
Because the application of ieductionism to assess the piactice of sofwaie engineeiing, pai-
ticulaily in eld ieseaich, is veiy complex (if not unsuitable), the authoi claims that the piesented
ieseaich is to be aligned with a piagmatist view of tiuth, valuing acquiied piactical knowledge.
In othei woids, the authoi choose to use whatevei methods seemed moie appiopiiate to piove
oi at least impiove oui knowledge about the questions heie iaised. Foimally, a system-
atic scientic appioach based on this epistemological stance iequiies the use of mixed methods,
among which aie (a) (Quasi-)Expeiiments, used to piimaiily assess exploiatoiy oi veiy con-
ned questions, and aie suitable foi an academic enviionment and (b) industiial Case-Studies,
as both a conduit to haivest piactical iequiiements, as to piovide a tight feedback and ieal-woild
application ovei the conducted investigation.
.i vcNunmvN1n: cnn::vNovs
Te fundamental ieseaich questions diiectly inheiited fiom the cuiient ieseaich tiends and
challenges in the aiea of Model-Diiven Engineeiing (mui), can be found in a iecent ieseaich
ioadmap published by Fiance et al. [FRo,], which states the following thiee diiving issues:
:. What forms should runtime models take: Specically in the context of this disseitation,
what foim should incomplete by design sofwaie systems take: What type models do they
iequiie: What aie the foices that shape those models:
:. How can the delity of the models be maintained: Paiticulaily, how can the delity of
models be maintained duiing evolution: What models aie adequate to observe the system:
What models aie needed to modify the system:
,. What role shouldthe models play invalidationof the runtime behavior: What validation
piovides a domain model that is a ist-class aitifact of the sofwaie system: What if the
outcome of design is the same model the system is iunning:
Anothei suivey by Teppola et al. [TPTo] synthesizes seveial obstacles ielated to wide adop-
tion of mui:
iUu:mi1:i cu:iiicis ,:
:. Understanding and managing the interrelations among artifacts. Multiple aitifacts such
as models, code and documentation, as well as multiple types of the same aitifact (e.g.,
class, activity, state diagiams) aie ofen used to iepiesent dieient views oi dieient levels
of abstiaction. Subsets of these oveilap in the sense that they iepiesent the same concepts.
Ofen because they aie manually cieated and maintained without any kind of causal con-
nection, evolution iaises the pioblem of maintaining consistency.
:. Evolving, comparing and merging dierent versions of models. Te tools we cuiiently
have to visualize dieiences among code aitifacts aie suitable because they essentially deal
with text. Models do not necessaiy have a textual iepiesentation, and when they do, it may
not be the most appiopiiate to undeistand its evolution and to make decisions, paiticulaily
if these aie to be caiiied by the end-usei.
,. Model transformations and causal connections. Models aie ofen used to eithei (i) ieect
a paiticulai system, oi (ii) dictate the systems behavioi. Te ielationships between the
system and its model, oi between dieient models that iepiesent dieient views of the
same system, aie called causal connections. Maintaining theii consistency when aitifacts
evolve is a complex issue, ofen caiiied manually.
. Model-level debugging. If the model is being used to dictate a systems behavioi, enough
causal connections must be kept in oidei to undeistand and debug a iunning application
at the model-level.
,. Combination of graphical and forms-based syntaxes with text views. Developeis and
end-useis have dieient piefeiences conceining textual syntaxes and giaphical editois to
view and edit models. To this extent, a complete coiiespondence between each stiategy is
cuiiently not well suppoited.
o. Moving complexity rather than reducing it. Model-Diiven Engineeiing is not a silvei-
bullet [Bio8,] and as such its benets must be caiefully weighted in context to assess
whethei the appioach will actually ieduce complexity, oi simply move it elsewheie in the
development piocess.
,. Ievel of expertise required. It is not cleai if the inteiielationships among multiple aitifacts
(which may have dieient foimalisms), combined with the necessaiy (multiple) levels of
abstiaction to expiess a systems behavioi actually eases the task of any given stakeholdei
to undeistand the impact and caiiy out a paiticulai change, and to which extent cuiient
tiaining in computei science and sofwaie engineeiing couises is adequate.
,: visi:vcu vvoniim
.i. Viewpoints
Systems based on Adaptive Object-Models, have two distinct viewpoints fiom wheie its benets
can be measuied: (i) the developei viewpoint, who is actively tiying to build a system foi a
specic domain, and (ii) the end-usei, who, when piovided, will be evolving the system once
deliveied. Te existence of an end-usei as a change-agent, although always cited as a benet of
the use of :om, iepiesents a new amount of additional conceins. Any technique that may be
iegaided as a good way to impiove the application adaptability to a well-tiained developei, may
be ievealed as an encumbiance to the end-usei, and a paiticulai nuisance to the usei-inteiface
design.
Teiefoie, theie aie some questions iegaiding end-usei development should be eithei specif-
ically ieseaiched in the aiea of :om, oi boiiowed fiom othei elds of ieseaich, namely:
:. End-user perception of the model. Te way end-useis see theii systems is dieient fiom
the abstiaction the developei aie used to. Undeistanding the dieiences between these
two peispectives is essential to piovide mechanisms in the usei-inteiface that aie suitable,
and avoids an highei-level Bic B:ii oi MUu [FY,].
:. Visual metaphors. We shouldnt expect the common end-usei to actually type in a textual
usi to expiess some new iules they want to inseit in the system. Othei kinds of visual
metaphois should be consideied as a pioxy foi the undeilying iule engine. Amoie detailed
discussion can be found in [Nai,].
,. Evolving the model. A tentative, failed, evolution may be disastious iegaiding the mean-
ing of data. Mechanisms to iecovei fiommistakes, though alieady useful to the developei,
aie paiamount to the end-usei.
. 1nvs:s s1n1vmvN1
It is the authoi belief that most cuiient pioblems developeis face when developing sofwaie with
high-vaiiability and iuntime adaptability needs, could be eciently coped with the Adaptive
Object-Model aichitectuial style. Fuitheimoie, the authoi believes that wheie seveial othei
model-diiven appioaches have failed to be geneially accepted, peihaps mostly because of dif-
feiences piesented in ,., (p. ,), the :om, within its bottom-up appioach, may ieveal to have
the piopeities needed to successfully give answei to a set of aichitectuial pioblems.
Notwithstanding the issues piesented in Chaptei : (p. :), the authoi does not considei pait
of this study to piove wheie and why these kind of systems emeige, noi the specic ieasons
that may lead an aichitect to iecognize these kind of systems. Instead, the authoi assumes that:
(i) the systemwe aie woiking with exhibit an high degiee of vaiiability, (ii) its specications have
1uisis s1:1imi1 ,,
shown a high degiee of incompleteness, and (iii) it is desiiable to ieduce the eoit of coping
with changes made to the domain model.
Should one agiee with the afoiementioned piemises, the authois fundamental ieseaich ques-
tion may be stated as:
Vhat form should this type of systems take, and which kind of tools and infrastructures should
be available to support the development of such sofware systems?
Consequently, the main goal is to ieseaich this form, heie to be undeistood as the architecture
and design of such sofwaie systems, along with the specication and constiuction of the appio-
piiate tools and infiastiuctuie. Moie specically, the authoi claims the following hypothesis:
Vhen developers are provided with a reusable and extensible infrastructure to build systems
based upon the Adaptive Object-Model as the main architectural style, either in the form of a
pattern language, or through concrete sofware components, they will (i) signicantly increase
their eciency to construct and evolve systems with high-variability needs when compared to
traditional approaches, and (ii) will be able to empower end-users (as the domain experts) to
conduct their own (conned) evolution during run-time. Such an infrastructure would maxi-
mize architectural and design reuse, and leverage both developers and end-users capability to
eciently adapt to frequent domain changes.
Tis statement uses teims whose meaning may not be consensual, and theiefoie lead to ques-
tions that deseive fuithei discussion:
:. What should be understood by a pattern language:
Te concept of pattein language and its impoitance foi the development of high-quality
systems has alieady been discussed in Chaptei : (p. :) and Chaptei , (p. ,,). Te pat-
tein language heie mentioned is based on the theoiies pioposed by Chiistophei Alexan-
dei [Aleo], and latei adopted to sofwaie by Gamma et al. [GHJV] and Buschmann et
al. [BMR
+
o].
:. What should be understood by an infrastructure:
An infiastiuctuie is heie intended as a object-oiiented framework, in the sense of both
ieusable designs and implementations that oichestiate the collaboiation between coie en-
tities of a system [RJo], built upon the design and architectural patterns piesented in the
pattein language foi adaptive object-models.
,. Who benets from this infrastructure:
Te intended meaning of eort should be loosely inteipieted as monetaiy cost, available time and iesouices,
iequiied skills, iesulting complexity, etc.
, visi:vcu vvoniim
Teie aie thiee iesulting outcomes fiom this woik, wheie the taiget audience sometimes
oveilap. Regaiding the pattein language that will be piesented in Chaptei , (p. o:), the
taiget audience aie aichitects and fiamewoik developeis building oi tiying to undeistand
the innei woikings of meta-aichitectuies, among which may be (i) those whose inteiest is
in the design of object-oiiented piogiamming oi specication languages, and (ii) otheis
that aim to impiove theii systems adaptivity.
Conceining both the iefeience aichitectuie and fiamewoik implementation pioposed in
Chaptei o (p. ,), any team composed of fiamewoik developeis, application developeis,
andfiamewoik selectois, who might be developing a pioduct withhigh-adaptability needs,
may diiectly benet by eithei ieusing oi adapting the aitifacts heie piesented.
. How is reusability and extensibility measured:
A fiamewoiks reusability and extensibility is measuied by the given Hooxs and extension
of the Comvoi1 Linv:vv. Howevei, because any measuie is always ielative to a given
puipose`, theii existence will be piimaiily diiven by the iequiiements established in the
case studies desciibed in Chaptei , (p. ::,), thus foiming a feedback loop closely similai
to that of Action Reseaich [Lewo].
,. How is eciency to be measured:
Eciency is to be measuied by the quantity of work pioduced to achieve a desiied eect.
Foi measuiing eciency in laige timespan, such as in a use-case analysis, it will be con-
sideied both the velocity (i.e., the amount of woik pei peison pei unit of time), and the
amount of changes needed to achieve the necessaiy eect.
o. Which are the traditional approaches:
When iefeiiing to tiaditional appioaches, one is mentioning those that aie capable of de-
liveiing adaptable systems, i.e., those wheie the end-usei can intioduce changes. Tis way,
most Rapid Application Development (v:u) tools should not be consideied, and as such
it is to be chosen any paiticulai setup suitable to piovide such systems.
,. Who are the end-users:
Fiomthe point of viewof a fiamewoik, both application developers and domain experts aie
to be consideied end-useis. Teiefoie, end-useis aie dened as the gioup of peisons who
will ultimately opeiate the domain application built on top of this infiastiuctuie.
8. What is conned evolution:
Conned evolution iefeis to a situation wheie an adaptable system piovide the means to
iestiict the possible changes conducted by the end-usei in the undeilying domain model,
` Foi example, does it make sense to ask how many Hooxs should a good fiamewoik piovide:
sviciiic visi:vcu 1ovics ,,
despite the infiastiuctuie suppoiting the cieation of a new domain model fiom sciatch.
Teiefoie, the system is delibeiately limited to a ceitain (conned) scope which will be
open to end-usei inteivention.
. What is understood by frequent domain changes:
Fiequent domain changes aie to be viewed in peispective with the aiguments piesented
in :.: (p. :) and :., (p. ), wheie the application domain we aie dealing with is chaiac-
teiized by continuous change.
. svvc:v:c nvsvnncn 1ov:cs
Despite the diveisity of questions cuiiently iequiiing ieseaich eoit, this disseitation will focus
moie on those capable of suppoiting a mui appioach foi the constiuction of :om-based systems.
In paiticulai, the following conceins will be the main diive foi the ieseaich:
:. Patterns. While seveial (appioximately thiity) :om-ielated patteins have been identied,
most of them iemain unstudied, undocumented and scatteied, thus in need to be biought
compiehensively into the liteiatuie [WYWBJo,]. Moieovei, as the ieseaich deepens, moie
patteins and vaiiations may be identied.
:. Tools. Conceining tools to suppoit :om based systems, seveial questions aiise: (i) what
kind of suppoit these systems iequiie fiom iuntime infiastiuctuies: (ii) Is it feasible to
build a geneiic :om iuntime infiastiuctuie: [Yodo:] (iii) which tools aie needed to en-
able application developeis to build and maintain :om-based applications: Fiamewoiks,
as ieusable designs of sofwaie systems compiomising a set of inteiielated and extensible
components, have been shown to ieduce the cost of developing application by an oidei
of magnitude [RJo]. Hence, what form should a fiamewoik foi developing :om systems
take:
,. Applications. Te thesis statement assumes that systems which have highly-vaiiable do-
mains and iuntime adaptability needs aie good candidates foi using the Adaptive Object-
Model aichitectuial style. Tis asseition will be addiessed duiing the study of industiial
use-cases of systems that have used the theoietical iesults and implementation aitifacts of
this disseitation.
.. Specic Challenges
Although the ieseaich in Adaptive Object-Models may be iegaided as a subset of the ieseaich
in mui, we think the following questions, when caiefully assessed, would piagmatically con-
tiibute to the cuiient body of knowledge, paiticulaily when choosing to use (oi not) this pattein.
,o visi:vcu vvoniim
Tough the belief that :omaie able to eciently cope with seveial of the stated issues in sofwaie
development, and this belief has been substantiated both by ieseaich on the widei aiea of mui,
as well as thiough the studies by the patteins community, caiefully designed contiolled expei-
iments should piovide statistical evidence that an :om is not an anti-pattein (i.e., an obvious,
appaiently good solution, but with unfoieseen and eventually disastious consequences):
:. Fitness for purpose. When is an :omadequate to use: When should the use of an :ombe
consideied over-engineering. What metiics should we base oui judgment foi applicability:
:. Target audience. What type of developeis aie best suited foi :om: Aie cuiient developeis
lacking in specic foimation that hindeis the usage and constiuction of :om: What about
end-useis: Aie theie specic pioles that could point to a moie suitable audience:
,. Development speed indicator(s). What is the impact on the usage of :om duiing the
seveial phases of the piocess: Do developeis inciease theii ability to pioduce systems:
How long is theii start-up time:
. Extensibility indicator(s). How easy is to extend a :om-based system: Is it possible to
Hoox a paiticulai customization into the base aichitectuie:
,. Quality indicator(s). What is the impact on sofwaie quality metiics when using :om:
How does it aect peifoimance: How does it ensuie coiiectness: Is consistency a ma-
joi factoi: What about the usability of automatically-geneiated inteifaces: How can we
impiove them:
..i Tesis Decomposition
Fiom the oiiginal thesis statement, it follows the following hypothesis that aie believed to hold
when compaiing to tiaditional systems:
H: Te fiamewoik piovides a moie suitable infiastiuctuie foi developing incomplete by
design systems.
Hi: Developeis focus moie on domain objects than implementation aitifacts.
H: It is easiei to tianslate conceptual specications into nal aitifacts.
H: Te eoit of adding oi changing existing iequiiements is consideiably lowei than the
alteinatives.
H,: Piototyped applications could be immediately (oi with little changes) used in
pioduction-level enviionments.
sviciiic visi:vcu 1ovics ,,
Ho: Tis style of development is moie in line with the agile piinciples.
H;: Tis style of development could be used to develop face-to-face with the client.
.. Tesis Goals
Te piimaiy outcomes of this thesis encompasses the following aimed contiibutions to the body
of knowledge in sofwaie engineeiing:
:. Te formalization of a pattern language for systems whose domain model is subject to
continuous change during runtime. When do this type of systems occui: What aie the
advantages: What aie theii undeilying iequiiements: Howdo we cope with each of them:
What aie the benets and liabilities of each specic solution: Tis contiibution expands
an unied conceptual pattein language, which allows aichitects and designeis to iecognize
and adequately use some of the best piactices in sofwaie engineeiing that cope with this
type of systems. Fuithei details aie piesented in Chaptei , (p. o:).
:. Te specication of a reference architecture for adaptive object-model frameworks.
What kind of infiastiuctuies aie needed: What foim should they take: What type of ab-
stiactions should be made and suppoited: What aie the geneiic functionalities it should
piovide: What should be its default behavioi: How can it be extended: Tis contiibution
addiesses seveial issues conceining fiamewoik design foi Adaptive Object-Models, and
piesents a solution thiough the composition of aichitectuial and design elements. Moie
details can be found in Chaptei o (p. ,).
,. A reference implementation of such framework. Fiom theoiy to piactice, Chaptei o
(p. ,) also details a conciete implementation of a fiamewoik based on the pioposed iefei-
ence aichitectuie, codenamed Oghma. Te goal of attaining an industiial-level implemen-
tation of such fiamewoik, along with the ieseaich of specic design issues that aiise only
when puisuing such conciete implementations, allowed to fuithei puisue the ieseaich us-
ing the chosen validation methodologies.
. Evidence of the framework benets through industrial use-case applications. A fiame-
woik should emeige fiom ieiteiated design in ieal-woild scenaiios. As such, the imple-
mentation shown in Chaptei o (p. ,) is mainly the iesult of an inciemental engineeied
solution foi specic industiial applications. Tis contiibution piesents sofwaie systems
built ontop of that fiamewoik, theii context, theii iequiiements, theii paiticulai pioblems,
the way the fiamewoik was used to addiess them, the outcomes, and the lessons leained
in Chaptei , (p. ::,).
,. Evidence of the framework properties through controlled academic quasi-experiments.
Althoughthe industiial usage of the fiamewoik piovides piagmatic evidence of its benets,
,8 visi:vcu vvoniim
theie aie some thieats that aie inheient to that type of validation. Tese shoitcomings aie
addiessed in Chaptei 8 (p. :,:), by conducting a (quasi-)expeiiment within a contiolled
academic expeiimental enviionment, wheie the study of gioups of undeigiaduate students
inteiacting with the fiamewoik has shown the iesults to be consistent with those piesented
in Chaptei , (p. ::,).
., vn::un1:oN mv1nouo:oov
Inoidei to puisue a scientic validationof the afoiementionedthesis, it is necessaiy to adequately
dene the expeiimental piotocols which assess these claims in a iigoious and sound way. Tis
includes the piecise denition of the piocesses followed in industiial case studies (see Chaptei ,,
p. ::,), as well as in the quasi-expeiiments (see Chaptei 8, p. :,:) peifoimed in academic contexts.
Te design of expeiimental piotocols foi the industiial case studies attempt to covei the whole
expeiimental piocess, i.e, fiom the iequiiements denition foi each expeiiment, planning, data
collection and analysis, to the iesults packaging. Discussion on guidelines foi peifoiming and
iepoiting empiiical studies have been iecently going by the woiks of Shull et al. [SSSo,] and
Kitchenham et al. [KAKB
+
o8]. Te typical tasks and deliveiables of a common expeiimental
sofwaie engineeiing piocess can be found in [GAo,].
As such, in the authoi undeistanding, the best way of validating the thesis would be ielying
on empiiical studies and contiolled (quasi-)expeiiments to compaie with othei appioaches, as
dened in this disseitation. Due to the eoit iequiied, and the opeiational diculties of con-
ducting such expeiiments in the eld of sofwaie engineeiing, it was decided to use a case study
based appioach foi evaluating the applicability and eciency on the usage of :om and :om
fiamewoiks, and to conduct a small expeiiment foi discaiding validation thieats that should
peisist. Te ieseaich stiategy foi each of them is detailed in Chaptei , (p. ::,) and Chaptei 8
(p. :,:).
Te independent expeiimental validation of claims is not as common in Sofwaie Engineei-
ing as in othei, moie matuie sciences. Hence, the authoi stiesses the need to build ieusable
expeiimental packages that suppoit the expeiimental validation of each claim by independent
gioups. Teiefoie, the (quasi-)expeiiment detailed in Chaptei 8 (p. :,:) was designed as an ex-
perimental package, to be peifoimed in dieient locations, and lead by dieient ieseaicheis, in
oidei to enhance the ability to integiate the iesults obtained and allow fuithei meta-analysis on
them.
.o coNc:cs:oN
Teie aie fundamental ieseaich questions diiectly ielated to the cuiient ieseaich tiends and
challenges in the aiea of Model-Diiven Engineeiing, viz. (i) what foims should iuntime models
cociUsio ,
take, (ii) how can the delity of the models be maintained, and (iii) what iole should the mod-
els play in validation of the iuntime behavioi: Some piopeities of :om systems aie known to
be paiticulaily suited to solve systems with high-vaiiability needs the so called incomplete by
design systems. In what conceins the cuiient ieseaich on :om, thiee main goals/questions weie
identied: (i) the study of undocumented and scatteied patteins, and the identication of new
patteins foi the constiuction of a pattein language foi :om, (ii) the constiuction of a geneiic
fiamewoik foi building :om-based systems, and (iii) the study on the benets and liabilities of
using such technology. Aligned to a piagmatist view of tiuth, valuing acquiied piactical knowl-
edge, the authoi pioposes to answei the above goals/questions, and validate them thiough the
usage of mixed methods, among which aie (i) observational and historical methods foi the contii-
butions iegaiding the pattein language, (ii) industiial case-studies, and (iii) (quasi-)expeiiments
peifoimed in academic contexts.
oo visi:vcu vvoniim
Chapter ,
Pattern Ianguage
,. On Patterns and Pattern Ianguages . . . . . . . . . . . . . . . . . . . . . . o
,.i General Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
,. Technical Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o,
,. General Forces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . oo
,., Core Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . op
,.o Evolution Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8o
,.; Composing the Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . pi
,.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p
Tis chaptei focus on Goal : of this thesis, namely to formalize the underlying patterns of sys-
tems which domain model need to change frequently during runtime. We discuss when do
these type of systems occui, what aie theii advantages, and what aie theii undeilying iequiie-
ments. We fuithei delve into the existing iecuiient solutions that cope with each of them. Each
pattein also exposes the benets and liabilities of each specic solution. Tis main outcome of
this goal is the establishment of an unied conceptual pattein language, which allows aichitects
and designeis to iecognize and adequately use some of the best piactices in sofwaie engineeiing
that cope with these type of systems.
,. oN vn11vnNs nNu vn11vnN :nNocnovs
Te opening of thiid book on Pattein Languages of Piogiam Design [MRB,] staits with the
following sentence: Vhats new here is that theres nothing new here. Tis single asseition chai-
acteiizes the epistemological natuie of patteins, in what conceins its methodology and goals;
patteins iesult fiomthe obseivation, analysis and foimalizationof empiiical knowledge inseaich
foi stiongei invaiiants, allowing iational design choices and uncoveiing newei abstiactions. A
pattein should not iepoit on suiface piopeities but iathei capture hidden structure at a suitably
o: v:11iv i:cU:ci
general level. Acompiehensive discussion on the epistemology of patteins and pattein languages
can be found in a iecent woik by Kohls and Panke [KPo]:
Te argument that there is nothing new in a pattern must be rejected, otherwise there would
be nothing newto physics either, since physical objects and the laws of physics have been around
before, just as design objects or programming styles have been around before somebody sets up
a pattern language or collection. Te discovery and description of a new species is without
question considered scientic progress. Of course, the animals are not new they lived there
before but they are newly discovered. In the same way, the most important patterns capture
important structures, practices, and techniques that are key competencies in a given eld, but
which are not yet widely known [Copo].
,.. What is a Pattern Ianguage:
As discussed in :., (p. ), a patteinmay be iegaided as a iecuiient solution foi a specic problem,
that is able to achieve an optimal balance among a set of forces in a specic context. We could
succinctly dene eachpatteinas a tiiplet p = xproblem, forces, solutiony. Apatteincatalog would
thus be dened as a non-empty nite set of patteins on a specic domain PC = tp
1
, p
2
, ..., p
n
u.
A pattein language (PL) is an extension of a pattein catalogue in the sense that it has a set
of patteins; but it extends on the notion of catalogue by also incoipoiating the ielationships be-
tween its elements. Each pattein may be ielated to othei patteins by dieient ielationships, so
r = xp
a
p
b
, descriptiony wheie (r P PL). Te concept is close to that of an ontology,
since the language could be synthesized as a foimal iepiesentation of knowledge (in a specic
domain), and the ielationships between its concepts. Yet, while an ontology aims to be descrip-
tive, a pattein language is prescriptive it piovides noimative instiuctions intended to have an
impact on shaping the act of design.
,..i Form
Te patteins community have been expeiimenting with seveial stiuctuies of the pattein desciip-
tion. Teie is the oiiginal stiuctuie that has been dened by Alexandei et al. in theii book :
v:11iv i:cU:ci: 1ows, nUiiuics, cos1vUc1io [AIS,,], and is commonly known as
the Alexanders Pattern Language foimat (:vi). Ten, theie is the seminal woik of Gamma et
al. [GHJV] wheie a dieient foimat was used specically tailoied foi the aiea of sofwaie en-
gineeiing, commonly known as the Gang of Four foimat (coi). Both have benets and liabilities:
the :vi is implicitly stiuctuied, and iesults in a uid, naiiative-like text, peisuading the ieadei
to identify heiself with the pattein; the coi foimposes a moie methodological paititioning with
seveial explicit subsections.
Tis woik will use elements of both the :vi and coi foims, by explicitly stiuctuiing the
pattein into the following subsections when needed:
ciiv:i co1ix1 o,
:. Summary. An intioductoiy paiagiaph, which sets the intent of the pattein, and possibly
links to othei patteins.
:. Context. Usually a scenaiio in which the pioblem occuis and wheie this pattein can be
applied.
,. Problem. Tis section staits with an emphasized headline, which gives the essence of the
pioblem in one oi two sentences. Afei the headline comes the body of the pioblem, de-
sciibing the empiiical backgiound of the pattein, and the iange of dieient ways the pat-
tein can be manifested.
. Solution. Tis section also staits with an emphasized headline, which desciibes the con-
ciete action necessaiy to solve the stated pioblem.
,. Example. A situation wheie the pattein has been applied, with a possible giaphical iepie-
sentation, listing the classes and objects used in the pattein and theii ioles in the design.
o. Consequences. Applying a pattein geneiates a iesulting context, wheie the iesolution of
the foices now pose benets and liabilities.
,. Implementation notes. Some additional conceins on eectively applying the pattein and
dealing with lowei-level issues, such as performance and memory consumption.
8. Known Uses. A pattein is a pattein because theie is empiiical evidence foi its validity.
Tis section points to systems wheie the pattein has been pieviously obseived.
. Related Patterns. Te ielationship to othei patteins of the same language, oi moie othei
domains, thus foiming the basis of a pattein language.
Te iest of this chaptei is oiganized as follows. A geneial context is established in ,.:, by
piesenting a naiiative of a ieal-woild scenaiio. It is followed by an oveiview in ,., (p. o,) of
the technical backgiound needed to apply these patteins. Fiom the geneial context, ,. (p. oo)
diafs some common design foices shaied by all the patteins heie foimalized. Ten, ,., (p. o)
and ,.o (p. 8o) will desciibe the seven patteins cential to this chaptei. Finally, all the patteins aie
unied into a pioposed evolution of the pattein language in ,., (p. :), ist diafed by Welicki
et al. [WYWBJo,].
,.i ovNvnn: coN1vx1
In:oo, the authoi was leading a sofwaie pioject consisting onthe constiuctionof a geogiaphical
infoimation system which would help a depaitment of aichitectuial and aichaeological heiitage
o v:11iv i:cU:ci
to manage both theii inventoiy and business piocesses'. Although oui development method-
ology was a slight vaiiant of eXtreme Programming [BAo], we weie consideiably iestiicted in
applying some of the piactices foi this paiticulai pioject: (i) it was bided, so the cost was xed,
(ii) we could not ieduce the scope, although it was systematically enlaiged, (iii) we could not
have an on-site costumei, and (iv) somehow, the iesult should be consideied a success at all cost.
Oui pioblems begun in the veiy ist ocial meeting we had. Because the bid was made
yeais befoie the ocial stait of the pioject, the stakeholdeis undeistanding had evolved since
then. Teiefoie, the initial iequiiements weie no longei a ieection of theii cuiient manual
piocesses. Oui contiact enfoiced the delivei of a requirement analysis document which had to
undeigo validation befoie staiting the development. And so we begun the task of collecting
iequiiements... foi two yeais.
At ist, this seems a good example of howit should not be done; two yeais collecting iequiie-
ments smells like a good old waterfall. Howevei, oui meie piesence was diiectly contiibuting to
this status. We staited to question things they had foi gianted, and in the piocess of foimalizing
theii piactices, we uncoveied inconsistencies which could not be solved piomptly. Tis iesulted
in a seiies of analysis iteiations, wheie the stakeholdeis had to ie-think theii goals, theii pio-
cesses, and theii iesulting aitifacts, befoie we could synthesize a coheient domain model.
At the end of those two yeais, we weie stiongly convinced of one thing: no mattei howmany
time we invested in analysis, the iesulting system would haidly be consideied nished. As an
example, considei the following iequiiement: they needed to collect the physical piopeities of
aichaeological aitifacts found in excavations. At ist, length, width and height seemed a good
measuie. But some aitifacts aie highly iiiegulai, like a thiee thousand yeai old jar. Foi these,
weight and material composition aie gieatly moie useful. Othei aitifacts, like coins, aie veiy ieg-
ulai and iely on dieient piopeities, like radius and thickness. Ten we have things in-between,
such as plates. Te moie we categoiized, the moie complex and longei the hieiaichy become,
without any condence we would be able to covei all the exceptions. Oui model was being
haunted by accidental complexity, :. (p. o), and a simple solution uiged objects to be chaiac-
teiized by the end-usei accoiding to a pie-dened set of piopeities (which weie not pie-dened
at all). Of couise useis aie no piogiammeis, so they needed to add new piopeities and cie-
ate new hieiaichies on-the-y fiom inside the application, without being explicitly awaie of the
undeilying model.
As pieviously discussed in Chaptei : (p. :), this is a cleai example of an incomplete by design
system[GJTo,]. Te authoi will make usage of this stoiy hencefoith to illustiate paits and pieces
of the patteins.
' Tis conciete example was also used as a case-study foi this disseitation, and a detailed desciiption can be found
in Chaptei , (p. ::,).
1icuic:i uiscviv1io o,
,. 1vcnN:cn: uvscn:v1:oN
Te sepaiating line between data and model is bluiied when speaking about meta-data, in the
sense that eveiything is, ultimately, data; only its puipose is dieient. Foi example, the infoi-
mation that some paiticulai Video in oui system is named Te Matrix, and anothei one named
Lord of the Rings, is called data foi the puipose of using it as an infoimation system foi video
ienting. We could hypothetically diaw a line encompassing all the objects that account foi data
(noimally called instances) and name it the meta-level-zero (M
0
) of oui system.
Te way we would typically model such a simple systeminanobject-oiiented language would
be to cieate a class named Video, along with an attiibute named Title. But what may be consid-
eied the model in one context, may be seen as data in anothei, e.g., the compilei. As such, this
infoimation is meta-data in the sense that it is data about data itself: in fact, it conveys a veiy
ciucial infoimation, which is the datas stiuctuie (and meaning), foi the puipose of specifying
an executable piogiam. Once again, we could diaw a line aiound these things that iepiesent
infoimation about othei things classes, piopeities, etc. and call them meta-level-one (M
1
),
oi simply model.
But, what exactly is a class, oi a piopeity: What is the meaning of calling a method, oi stoiing
a value: As the ieadei might have guessed, once again, theie is stiuctuie behind stiuctuie itself
aninfrastructure andthe collectionof suchthings is calledmeta-level-two (M
2
), oi meta-model
foi shoit (i.e., a model that denes models), which is composed of meta-classes, class factories,
and othei similai aitifacts.
Hence, when we talk about data (oi instances) we aie iefeiiing to M
0
baie infoimation
that doesnt piovide stiuctuie. By model we aie iefeiiing to M
1
its infoimation gives stiuctuie
to data. By meta-model we aie iefeiiing to M
2
infoimation used to dene the infiastiuctuie.
And so on...
Ultimately, depending on the systems puipose, we will ieach a level which has no layei above.
Tis top-most level doesnt (yet) have a name; in MOF [OMG:oa] it is called a meta-meta-
model, due to being the thiid model layei. Tis building up of levels (oi layeis), wheie each one
is diiectly accountable foi pioviding stiuctuie and meaning to the layei below is known as the
Reective Tower, a visual metaphoi that can be obseived in Figuie ,.: (p. oo).
All this would not be veiy useful if it did not had a puipose. We alieady mentioned the
compilei, whose task is to iead a paiticulai kind of infoimation (known as source code) and
tianslate it into a set of stiuctuies and instiuctions (known as a program), which would latei be
executed by a computei a piocess known as compilation. Te compilei acts as a piocessing
machine: the input goes into one side, and the outcome comes fiomthe othei. Once the compilei
has done its job, it is no longei iequiied, and so it does not observe noi interact with the nal
piogiam. Should we wish to modify the nal piogiam, we would need to change the souice
Would it be the sixth, we seiiously doubt anyone would apply the same piex ve times.
oo v:11iv i:cU:ci
M2
M1
M0
Class Attribute
instanceOf instanceOf
M3 Class
Instance
instanceOf instanceOf instanceOf
classier
+title: string
Video
title = "Matrix"
:aVideo snapshot
instanceOf
Matrix
instanceOf
Figure ,.: Te Reective Tower of a video ienting system, showing foui layeis of data.
code and handle it again to the compilei.
Now let us suppose we wanted to add a new piopeity to a Video, like the name of its Direc-
tor, oi cieate new sub-types of videos as needed, like Documentary oi TV Series, each one with
dieient piopeities and ielations: In othei woids, what if we need to adapt the piogiam as it is
iunning: Foi that, we would need both to obseive and inteiact with oui iunning application,
modifying its stiuctuie on-the-y (the technical teim is duiing run-time). Te piopeity of sys-
tems that allow such thing to be peifoimed is called Reection, i.e., the ability of a piogiam to
manipulate as data something iepiesenting the state of the piogiam duiing its own execution.
Te two mentioned aspects of such manipulation, obseivation and inteiaction, aie iespectively
known as introspection, i.e., to obseive and ieason about its own state, and intercession, i.e., to
modify its own execution state (structure) oi altei its own inteipietation oi meaning (semantics).
Te technique of using piogiams to manipulate othei piogiams, oi the iunning piogiam
itself, is known as meta-programming, and the high-level design of such system is called a meta-
architecture. Te debate on the exact meaning of this woid seemingly due to the meta piex
which can be undeistood as being applied to the woid aichitectuie (i.e., an aichitectuie of aichi-
tectuies), oi as a subset categoiization, was alieady mentioned in :.:.o (p. :,). Foi the puipose
of this woik, we will stand with the lattei, i.e., a meta-architecture is a sofware systemarchitecture
that relies on reective mechanisms.
,. ovNvnn: voncvs
Eachpatteinhas a set of foices, things that shouldbe weightedinoidei toachieve a goodsolution.
Because the patteins heie foimalized aie deeply connected, most of themshaie a good amount of
foices in common. Figuie ,.: (p. o,) shows a schematic ielationship among some of the following
ciiv:i iovcis o,
Homogeneity
Transparency
Usability
improves
Adaptability
Reuse
Separation of Concerns
Proliferation
Granularity Performance
Concurrency
improves
changes
helps helps
hinders
leads to
leads to hinders
hinders helps
o
w
H
i
s
t
o
r
y
o
f
O
p
e
r
a
t
i
o
n
s
S
y
s
t
e
m
M
e
m
e
n
t
o
M
i
g
r
a
t
i
o
n
s
m
a
n
a
g
e
s
m
a
y
-
u
s
e
m
a
y
-
u
s
e
c
o
o
r
d
i
n
a
t
e
s
u
s
e
s
u
s
e
s
u
s
e
s
s
u
p
p
o
r
t
s
s
u
p
p
o
r
t
s
r
e
n
d
e
r
s
m
a
n
a
g
e
s
p
r
o
c
e
s
s
e
x
t
e
n
d
s
m
a
n
a
g
e
s
e
x
t
e
n
d
s
e
x
t
e
n
d
s
D
o
m
a
i
n
S
p
e
c
i
c
L
a
n
g
u
a
g
e
s
u
p
p
o
r
t
s
e
x
t
e
n
d
s
u
s
e
s
u
s
e
s
s
u
p
p
o
r
t
s
p
r
o
c
e
s
s
u
s
e
s
u
s
e
s
m
a
y
-
u
s
e
m
a
y
-
u
s
e
i
n
s
t
r
u
m
e
n
t
u
s
e
s
c
o
n
t
r
o
l
s
i
n
s
t
r
u
m
e
n
t
E
v
e
r
y
t
h
i
n
g
i
s
a
T
h
i
n
g
C
l
o
s
i
n
g
t
h
e
R
o
o
f
e
x
t
e
n
d
s
b
r
i
n
g
s
t
h
e
n
e
e
d
f
o
r
r
e
q
u
i
r
e
s
e
x
t
e
n
d
s
W
o
r
k
o
w
s
u
p
p
o
r
t
s
C
a
c
h
e
L
a
z
y
S
e
m
a
n
t
i
c
s
I
I
.
B
e
h
a
v
i
o
r
a
l
I
V
.
I
n
t
e
r
a
c
t
i
o
n
I
.
S
t
r
u
c
t
u
r
a
l
I
I
I
.
A
r
c
h
i
t
e
c
t
u
r
a
l
V
I
.
E
v
o
l
u
t
i
o
n
V
.
C
r
e
a
t
i
o
n
a
l
V
I
I
.
C
o
n
s
t
r
u
c
t
i
o
n
V
I
I
I
.
S
u
p
p
o
r
t
Figure ,.i: Pioposed evolution of the pattein language foi Adaptive Object-Models.
Chapter o
Reference Architecture & Implementation
o. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p,
o.i Tread of Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pp
o. Architectural Decomposition . . . . . . . . . . . . . . . . . . . . . . . . . oi
o. Crosscutting Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
o., User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
o.o Development Eort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
o.; Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o
Tis chaptei focus on Goals : and , of this thesis, namely to specify a reference architecture for
adaptive object-model frameworks, and to provide an industrial-level implementation of such
framework, codenamed Oghma. We stait by identifying the undeilying design piinciples and
guidelines i.e., the iequiiements of incomplete by design systems. We then piovide the high-
level aichitectuial viewof such fiamewoik, and decompose it into the key components involved.
In due couise, each component is showed how it addiesses the pioposed guidelines, pioviding
implementation details wheie necessaiy.
o. ovvnv:vw
Oghma is an object-oiiented fiamewoik [RJo, ATMBoo, FSJb], taigeted to the development
of infoimation systems whose stiuctuial iequiiements can be best desciibed as incomplete by de-
sign [GJTo,]. Applications making usage of this fiamewoik can easily implement the Au:v1ivi
On,ic1-Mouii meta-aichitectuial pattein [YBJo:b] to allowiun-time domain evolution by the
end-usei. It is stiuctuied as a collection of i:viviu comvoi1 iinv:vv [BMR
+
o], allow-
ing theii high-level composition to achieve dieient functional aichitectuies, e.g. client-seivei
v.s. single-piocess. It makes extensive usage of meta-piogiamming :.:.: (p. ::) and meta-
modeling :.:., (p. :) following the geneial guidelines of the N:xiu On,ic1s aichitectuial
o viiivici :vcui1ic1Uvi imviimi1:1io
pattein [Pawo] to piovide iuntime adaptation of the domain model, and automatic geneia-
tion of giaphical usei-inteifaces and peisistency. It extends the common meta-object/meta-class
model design [Caz8] by iaising object veisioning to a ist-class concept of the system. It also
adds the ability to specify a wide class of behavioial iules, such as deiived piopeities, class in-
vaiiants, and data views, by using the I1ivvvi1iv pattein [GHJV], and piesenting them to
the end-usei as a domain specic language, eithei thiough a classic textual syntax oi giaphical
iepiesentation.
o.. General Principles and Guidelines
Piobably the most well known systemspecically built to be incomplete by design is the VikiViki-
Veb, cieated by Waid Cunningham in :, [Cun,], and which is nowadays the base' foi a class
of systems commonly called wikis. At the coie of a wiki lies the set of piinciples and guidelines
shown in Table o.:.
Pvicivii Discviv1io
Simple Easiei to use than abuse. A wiki that ieinvents HTML maikup ([b]bold[/b], foi example) has
lost the path!
Open Should a page be found to be incomplete oi pooily oiganized, any ieadei can edit it as they
see t.
Inciemental Pages can cite othei pages, including pages that have not been wiitten yet.
Oiganic Te stiuctuie and text content of the site aie open to editing and evolution.
Mundane A small numbei of (iiiegulai) text conventions will piovide access to the most useful page
maikup.
Univeisal Te mechanisms of editing and oiganizing aie the same as those of wiiting, so that any wiitei
is automatically an editoi and oiganizei.
Oveit Te foimatted (and piinted) output will suggest the input iequiied to iepioduce it.
Unied Page names will be diawn fioma at space so that no additional context is iequiied to inteipiet
them.
Piecise Pages will be titled with sucient piecision to avoid most name clashes, typically by foiming
noun phiases.
Toleiant Inteipietable (even if undesiiable) behavioi is piefeiied to eiioi messages.
Obseivable Activity within the site can be watched and ieviewed by any othei visitoi to the site.
Conveigent Duplication can be discouiaged oi iemoved by nding and citing similai oi ielated content.
Table o.: Wiki design piinciples, quoted fiom [Cuno,].
Inspiied by the above piinciples, we aigue that any system delibeiately designed to cope with
incompleteness should piovide similai guidelines as those piesent in Table o.: (p. ,).
o..i High-level Architecture
Te high-level aichitectuie of the Oghma fiamewoik is depicted in Figuie o.: (p. ,). It allows
the development of :om-based infoimation systems by pioviding a Comvoi1 Linv:vv and a
' Not stiictly the code-base and neithei the iequiiements, but instead the coie functionalities.
Foi the puiposes of this disseitation, we will always considei infoimation systems.
ovivviiw ,
Pvicivii Discviv1io
Open Should a iesouice be found to be incomplete oi pooily oiganized, the end-usei can evolve it as
they see t.
Inciemental Resouices can link to othei iesouices, including those who have not yet been biought into exis-
tence.
Oiganic Stiuctuie and content aie open to editing and evolution. Evolution may be made moie dicult if
it is mandatoiy foi infoimation to stiictly confoim to a pie-established model.
Univeisal Te same (oi veiy similai) mechanisms foi modifying data and model should be exposed by the
system with no appaient distinction.
Oveit End-usei evolution should be made by non-piogiammeis. Te intioduction of linguistic con-
stiuctions (such as textual syntax) is usually iequiied in oidei to piovide foimalization. Howevei,
such constiuctions may ieveal unnatuial, intiusive and complex to the end-usei, thus model edi-
tion should be made as ieadily appaient (and tianspaient) as possible.
Toleiant Inteipietable behavioi is piefeiied to system halt.
Obseivable Activity should be exposed and ieviewed by end-useis, fomenting social collaboiation.
Conveigent Duplication is discouiaged and iemoved by inciemental iestiuctuiing and linking to similai oi
ielated content.
Table o.i: Design piinciples foi incomplete by design systems.
default Tuvi:u oi Co1voi. Te main components aie highly modulai, delibeiately designed
to cope with a iange of dieient needs and deployment scenaiios, such as (i) client-seivei, wheie
seveial piocesses aie oichestiated by a cential seivice, (ii) single-piocess, when one can disiegaid
concuiiency issues and choose a monolithic setup, (iii) web-based, wheieas a single piocess is
iunning but ieceiving multiple iequests, and (iv) distiibuted, which takes advantage of automatic
data-ieplication mechanisms piovided by undeilying peisistency engines to piopagate changes
acioss multiple seivices. Moie details will be given in o.:. (p. 8).
Communications
Core
Warehousing Controller User-interface
Structural Core Behavioral Core
Figure o.: High-level aichitectuie of the Oghma fiamewoik.
Oghma suppoits a custom object model closely iesembling class and object diagiams fiom
Umi and moi, and it is aimed to covei the entiie cycle of sofwaie development, fiom design to
deployment :., (p. ). Te intioduction of changes to the model, eithei oiiginating in the de-
8 viiivici :vcui1ic1Uvi imviimi1:1io
velopment team oi in the end-usei, can be peifoimed duiing iuntime. Fuitheimoie, the fiame-
woik leveiages the infiastiuctuie to iaise the oveiall awaieness of the systems evolution, pio-
viding functionalities such as auditing and time-traveling, in accoidance to piinciples diafed
in o.:.: (p. o).
o.. Key Components
Te pioposed aichitectuie identies the following components, paititioned accoiding to the
best-piactices of object-oiiented design, namely low-coupling and high-cohesion:
Core. Tis component piovides the model object suppoited by the fiamewoik; it can be
fuithei divided into the stiuctuial and behavioial coies.
Structural Core. Tis component desciibes the basic stiuctuie of the object model, e.g.,
the concepts of an object, a class, and a piimitive type, and the way they aie ielated.
Behavioral Core. Tis component addiesses the dynamic conceins, e.g., class invaiiants
and deiivation iules.
Controller. Tis component oichestiates the othei components in the system, by holding
the iesponsibility of the Tuvi:u oi Co1voi
Warehousing. Tis component piovides mechanisms foi stoiing data and metadata.
Communications. When seveial applications aie iunning (e.g., in a client-seivei aichi-
tectuie), a channel must be established between them.
User-interface. Eventually, the end-usei must inteiact with the application thiough non-
piogiammatic aitifacts.
o.. Component Composition
Each component may be specialized into dieient components, thus pioviding a modulai com-
posable aichitectuie. Foi example, the aichitectuie of a client-seivei application, with a iich cUi
and peisisting data into a ielational database is depicted in Figuie o.: (p. ). Heie, the contiollei
was fuithei specialized into a client and seivei contiollei, the foimei ielying in the communica-
tions component. Te waiehousing ielies on a peisistency module that deals with the ielational
database.
A dieient composition may be obseived in Figuie o., (p. ), taking advantages of a dis-
tiibuted database to eliminate the communications component. We will call any paiticulai com-
position of the components the application stack, and the way it is achieved will be desciibed in
due couise.
1uvi:u oi co1voi
Communications
Core
Warehousing
Persistency User-interface
Client Controller
Server Controller
Database
Figure o.i: Aichitectuie of a client-seivei setup of the Oghma fiamewoik.
Warehousing
Persistency
User-interface Controller
Distributed
Database
Warehousing
Persistency
User-interface Controller
Distributed
Database
data replication
Figure o.: Aichitectuie of a distiibuted setup of the Oghma fiamewoik.
o.i 1nnvnu ov coN1no:
As seen in Figuie o.: (p. ,), the contiollei seives as an entiy point foi both the usei-inteiface
and communications component, and its key iesponsibility is to oichestiate the seveial othei
components in the fiamewoik by establishing a thiead of contiol. Tis thiead of contiol may be
divided into thiee stages, viz. (i) the initialization piocess, also known as bootstiapping, (ii) the
main piocess, which ieceives exteinal events foi data queiying and manipulation, and inteiacts
with the waiehousing, and (iii) the shutdown piocess.
Te contiollei also holds the iesponsibility of pioviding Hooks to the fiamewoik thiough the
Cu:is oi Risvosiniii1v and PiUcis patteins, foi extensibility ieasons (e.g. inteiopeiability
with thiid-paity systems by allowing subsciibeis to inteicept iequests).
o.i. Bootstrapping
At the application staitup, the fiamewoik has to execute two types of bootstiapping, viz. (i)
infiastiuctuie bootstiapping, wheie the desciiption of the stiuctuial coie is loaded, and (ii) ap-
plication bootstiapping, wheie the ist veision of the model is loaded. Te lattei only occuis
if it is the ist time the application is staited, since subsequent staitups iely on the latest model
infoimation stoied in the waiehouse. Tis activity can be obseived in Figuie o. (p. :oo).
:oo viiivici :vcui1ic1Uvi imviimi1:1io
Stack initialization
Infrastructure
Bootstrap
Model Bootstrap
Initialize
Warehousing
[new warehouse]
[existing warehouse]
Load Latest
Model
Main Loop
Figure o.: Activity diagiam of the fiamewoik initialization.
Te exceipt of code listed in Souice o.: shows a small pait of the infiastiuctuie bootstiapping,
wheie one can obseive the stiuctuial coie being dened, namely the Thing, Named Element,
Owned Element and Enum Literal.
1 <e nt i t y i d= metathi ng name=MetaThing abs t r ac t= t r ue t o s t r i ng={
_i dent i t y }>
2 <at t r i d= _i dent i t y name= I d e n t i f i e r domain= i de nt i t y c a r di na l i t y=1
readonl y= t r ue />
3 <at t r i d= _nati vetype name= Nati ve Type domain= s t r i ng c a r di na l i t y=
0 . . 1 />
4 </ e nt i t y>
5
6 <e nt i t y i d=namedelement name=Named Element abs t r ac t= t r ue i n h e r i t s=
metathi ng t o s t r i ng={_name}>
7 <l i s t columns={ _i dent i t y }| {_name} />
8 <at t r i d=_name name=Name domain= s t r i ng c a r di na l i t y=1 />
9 <at t r i d= _displayname name= Di spl ay Name domain= s t r i ng c a r di na l i t y=
1 />
10 </ e nt i t y>
11
12 <e nt i t y i d= ownedelement name=Owned Element abs t r ac t= t r ue i n h e r i t s=
namedelement />
13 <e nt i t y i d= e numl i t e r al name= Li t e r a l t o s t r i ng={_displayname} i n h e r i t s=
namedelement i s i n s t a n c e o f=Oghma. Core . St r uc t ur al . EnumLi teral />
Source o.: A small exceipt fiom the infiastiuctuie bootstiapping.
o.i.i Main Process
Afei the bootstiapping, the fiamewoik enteis the main loop waiting foi events to occui. Teie
aie two main type of events, viz. (i) queiy events, which do not modify the cuiient state, and
(ii) commit events, which may intioduce new data oi meta-data. Tis activity is depicted in Fig-
uie o., (p. :o:).
Queiy and commit events may be ieceived by dieient thieads, but only queiy events can
be piocessed simultaneously. In oidei to ensuie consistency, paiticulaily due to modied causal
connections when model changes occui, commit events lock the application. Tis is a design de-
cisionthat may be subject to change, since it may intioduce performance issues inwiite-intensive,
1uvi:u oi co1voi :o:
Wait for Query
Wait for Commit Hold Lock
Wait on Lock
Release Lock
Trigger Hooks Execute Query
Execute Commit Trigger Hooks
Figure o.,: Activity diagiam of the main loop.
highly concuiient systems. Both queiy and commit events tiiggei befoie, duiing, and afei
Hooxs foi extension puiposes.
o.i. Query Events
Te majoiity of events duiing a noimal session aie queiies, which include: (i) iequesting a list of
instances based on the type, (ii) iequesting a list of instances based on conditionals, (iii) iequest-
ing a paiticulai instance based on its identiei. Due to the non-dieientiation between data and
meta-data, some possible events such as (iv) iequesting a list of types based on the meta-type,
aie vaiiants of iequesting instances. Othei queiy events may include veisioning conceins, such
as (v) iequesting the histoiy of tiansactions, oi (vi) iequesting instances in a given (pievious)
veision. Tis activity can be obseived in Figuie o.o.
Create Reply
Transaction
Query
Warehouse
Create Query
[dependent objects]
Return Reply
Transaction
[query]
Add to
Transaction
Figure o.o: Activity diagiam of queiy events.
o.i. Commit Events
Commit events modify the cuiient state of the application, by cieating oi updating its data and
metadata, as seen in Figuie o., (p. :o:). It includes (i) cieating a new instance, (ii) updating
an attiibute, (iii) establishing/deleting a link, (iv) deleting an instance. Again, due to the non-
dieientiation between data and meta-data, some possible events such as (v) cieating a newtype,
aie vaiiants of those ovei instances. Tis activity is slightly moie complex than the queiy activity;
ist, theie aie two ways of peifoiming a commit event: (i) state-based, wheie one piovides the
nal state of the object(s), and (ii) opeiation based, wheie it is sequence of opeiations peifoimed
upon an object(s) that aie piovided. If the contiollei ieceives the foimei, then it infeis a possible
sequence of opeiations, by using semantic heuiistics. Second, befoie applying the opeiations, a
meiged containei is cieated that piovides a safe view ovei the existing data; opeiations become
:o: viiivici :vcui1ic1Uvi imviimi1:1io
puie, i.e., they geneiate new objects. In the end, all validation iules (e.g., class invaiiants) aie
veiied, and side-eects due to tiiggeied iules, e.g., auto-numbeis, aie ieplied in a new tiansac-
tion.
Create Reply
Transaction
[operation based]
Apply Operations
in Order
[commit]
Build Operations
[state based]
Create Merged
Container
Verify
Consistency
Return Reply
Transaction
Figure o.;: Activity diagiam of commit events.
o. nncn:1vc1cnn: uvcomvos:1:oN
We now pioceed to decompose the high-level aichitectuie into components, and each compo-
nent into a conceptual stiuctuie (design).
o.. Structural Core
Te design of the stiuctuial coie of Oghma, built on top of the TvviSqU:vi ,.:., (p. ) pat-
tein, can be obseived in Figuie o.8. Te ObjectType is iened into Entities (that iepiesent
classes) and Interfaces. An Instance, which must comply to a given Entity, holds a collection
of Properties, which in tuin complies to its PropertyType. PropertyTypes aie iened into
RelationNodes and Attribute-Types. A Relation-Node species caidinality, navigability and
iole, by connecting to anothei node. Two connected nodes establish a RelationType. Foi piop-
eities belonging to ielations (similai to the Associative Class in UML), the RelationType may
iefei anothei Entity. Object-oiiented inheiitance and polymoiphism is established by linking
Entities with othei Entities and/oi multiple Interfaces.
meta-level
Instance
Entity
Property
PropertyType
AttributeType
RelationType Interface
ObjectType
assoc
0..1
implements
0..*
inherits
0..1
1
1
Navigability
Cardinality
Role
RelationNode
Figure o.8: Coie design of the stiuctuial meta-model.
:vcui1ic1Uv:i uicomvosi1io :o,
Extending the Property Pattern
Te usual foim to captuie ielationships between dieient objects is by using the AccoU1:nii-
i1v pattein, as pieviously discussed in Chaptei , (p. ,,). But we should ask what exactly is the
dieience between a eld and a ielation: Object elds, in oov, aie used to stoie eithei values
of native types (such as an int oi a oat in Java) oi iefeiences to othei objects. Tey can also be
eithei scalais oi collections. Some puie oo languages (e.g., Smalltalk) tieat eveiything as an ob-
ject, and as such do not make any dieience fiom native types to iefeiences`. Some also discaid
scalai values and instead use singleton sets. We may boiiow these notions to extend the Pvov-
iv1v pattein in oidei to suppoit associations between entities, as seen in Figuie o., piovided
we aie able to state piopeities such as caidinality, navigability, iole, etc. Te actual dieience
between what is a scalai piopeity and a ielation becomes a iuntime detail iesolution.
Entity Property
Lower-bound: int
Upper-bound: int
Cardinality
Association
Aggregation
Composition
enumeration
Role
isNavigable: bool
Property Type
Native Type: Type [0..1]
Entity Type
target
value
Figure o.p: An extension of the Tvvi-SqU:vi pattein.
One Hoox intioduced between the fiamewoik and the host language is the use of the Native
Type piopeity in Entity Type, to allow any custom Entity Type to be diiectly mapped into
a native type (such as integeis and stiings). Teie aie also seveial constiaints not depicted in
the diagiam. Foi example, the lowei and uppei bound in caidinality should iestiain the numbei
of associations fiom a single Property to Entities. Likewise, Properties should only link to
Entities which aie of the same Entity Type as that dened in Property Type. Te complete
foimalization of the semantics of the piesented models is outside of the scope of this disseitation,
but pait of it may be found in the test suits of the fiamewoik.
Self-Compliance
Te afoiementioned desciiption iepiesents a veiy simplied view of the entiie set of imple-
mentation conceins. Te bootstiapping of the infiastiuctuie iequiies that the meta-model be
dened in teims of itself, due to ieasons pieviously discussed in ,.,., (p. ,). moi is an example
of self-compliance, by making the M
3
layei self-desciibing. Teie aie seveial ieasons to make
that design choice: (i) it makes a stiict meta-modeling aichitectuie, since eveiy model element
` Anothei blatant simplication, since the smalltalk viitual machine do tieat piimitive types dieiently; they aie
just exposed as if they weie anothei object.
Almost nave.
:o viiivici :vcui1ic1Uvi imviimi1:1io
on eveiy level is stiictly in coiiespondence with a model element of above level; and (ii) the same
mechanisms used to view, modify and evolve data can be ieused foi meta-data.
serializable
State
Entity Type Entity
Identier {unique}
Thing
1..*
has
instanceOf
Figure o.o: Implementing the Evivv1uic is : Tuic pattein, and decoupling the Iui1i1v of an object
fiom its state.
One way to accomplish self-compliance ielies on using the Evivv1uic is : Tuic pattein
with Ciosic 1ui Rooi. Basically, it consists on abstiacting the elements of eveiy level into a
single, unifying concept; the Thing. A Thing is thus an instance of anothei Thing, including of
itself, such as depicted in Figuie o.:o. Tis implies that duiing bootstiapping, the system would
ist need to load its own meta-model, as discussed in o.:.: (p. ). Teiefoie, Entity Types
aie actually M
2
Entities, thus ielying on context foi piopei semantics.
Versioning
As seen in Figuie o.:o, the identity of each instance is maintained as Things, while the iespective
details aie kept as States. Teiefoie, all the pievious States of a Thing become ieachable to
the application, as seen in Figuie o.::, wheie two distinct values exist foi the same Property
Type, coiiesponding to two dieient changes to the same instance ovei time. Tis design choice
allows to leveiage of the Observable guideline o.:.: (p. o), e.g., to piovide auditability and time-
tiaveling mechanisms.
Name: Property Type
Value = "Michael Doe"
S1: State
Value = "John Doe"
S2: State
Patient: Entity Type
Figure o.: An example of two dieient states of the same entity.
Implementation Model
By also taking into consideiationveisioning conceins, a designmoie close to the implementation
may be obseived in Figuie o.:: (p. :o,).
:vcui1ic1Uv:i uicomvosi1io :o,
Abstract: bool
Readonly: bool
Entity
1..*
Identier: Identity
Thing nativeType
Name: string
Display name: string
Named Element
Classier
Object Type
Package
Lower bound: int
Upper bound: int
Unique: bool
Readonly: bool
/ Derived: bool
Property
Interface
owner
0..*
owner
redened-by
0..1
parent 0..1
Primitive Type
opposite
0..1
0..* implements
meta
1
system
Type 0..1
targetType 1
State Version
Owned Element
1..* 1..*
base
0..*
Literal
Enum
owned
1..*
owner
1
Figure o.i: Implementation model of the stiuctuial meta-model.
o..i Behavioral Core
In addition to stiuctuie, such as entities, piopeities and associations, a system possesses dynam-
ics; its data and metadata evolves ovei time. It also ielies on the ability to suppoit iules and
automatic behavioi. Some examples of these include, but aie not limited to (i) constiaints, such
as ielationship caidinality, navigability, type iedenition, default values, pie-conditions, etc. (ii)
functional iules, which include ieactive logic such as tiiggeis, events and actions, and (iii) woik-
ow logic.
Strategy and Rule Objects
Even duiing the bootstiapping of the infiastiuctuie, afei all types of objects and theii iespective
attiibutes aie cieated, theie aie some iules that must be consideied. Foi example, the caidi-
nality of an association should be pieseived; this is the same as saying that the taiget collec-
tions size should be between the lowei and uppei bounds dened by its type. To suppoit such
common iules, ielatively immutable oi otheiwise paiameteiized, one could iesoit to using the
S1v:1icv and RUii On,ic1 pattein, as pieviously discussed in ,.:.o (p. o) and seen in Fig-
uie o.:, (p. :oo).
An extension of the RUii On,ic1 is depicted in Figuie o.: (p. :oo), which allows the de-
nition of: (i) Entity Type invaiiants, which aie piedicates that must always hold, (b) deiivation
iules foi Property Types and Views, (c) the body of Methods, (d) guaid-conditions of Op-
Adding data to the system should also be consideied evolution.
:oo viiivici :vcui1ic1Uvi imviimi1:1io
Validate()
Mandatory
Validate()
Rule
1 Validate()
PatternMatch
Validate()
EntityType
Name: string
PropertyType
0..*
Figure o.: A class diagiam of the S1v:1icv and RUii On,ic1 patteins, foiming the stiuctuie of the
family of algoiithms foi enfoicing iules. Te dashed line iepiesents an invocation call.
erations, etc. Te stiuctuial constiaints above mentioned, such as the caidinality and unique-
ness of a Property Type, aie specializations of conditions. Methods may be invoked manually
and/oi tiiggeied by events, thus pioviding enough expiessivity to specify S1:1i M:cuiis and
Wovxiiows. Patteins such as Sm:v1 V:vi:niis and T:nii LooxUv also piovide an example
of common iules implemented as stiategies [YFRT8].
Property Type
Entity Type
Method Rule
invariant
body
1..*
derived by
0..*
Operation
guard
Condition
0..1
Create
Update
Delete
User-Activated
enumeration
Event
Figure o.: Dynamic coie of the Oghma fiamewoik.
Interpreter
When the desiied behavioi ieaches a ceitain level of complexity and dynamism, then a domain
specic language should be consideied to extend RUii On,ic1s. Afei paising, the language
can be conveited into an :s1 and fuithei piocessed using an I1ivvvi1iv [GHJV], wheie
piimitive iules aie dened and composed togethei with logical objects mimicking the tiee stiuc-
tuie to be inteipieted duiing iuntime, oi by a Viv1U:i M:cuii. Tey aie widely used to de-
ne: (i) ObjectType invaiiants, (ii) deiivation iules in PropertyTypes and Views, (iii) body
of Methods, (iv) guaid-conditions of Operations, etc. As such, they also play an impoitant
iole in assuiing semantic integiity duiing model evolution, as will be discussed in o.., (p. :::).
Souice o.: (p. :o,) shows a model exceipt stating a behavioial iule ensuiing that a peison cannot
be its own paient, using the custom-developed usi.
A common pioblem that aiises with the abstiaction of iules, is that the developei may fall
in the tiap of cieating (and then maintaining) a geneial-puipose piogiamming language, which
may iesult in incieased complexity iegaiding the implementation and maintenance of the taiget
application, fai beyond what would be expected if those iules weie haidcoded [YBJo:a].
:vcui1ic1Uv:i uicomvosi1io :o,
1 <e nt i t y i d= person name= Person >
2 <i nv name= notmyancestor >not s e l f . In ( Walk( pai ) )</ i nv>
3 <at t r i d= parent name= Parent domain= person c a r di na l i t y= 0 . . 1 />
4 </ e nt i t y>
Source o.i: Example of a model dening behavioial iules.
Views
Considei the following iequiiement: list all doctois ina paiticulai medical centei, along withthe
numbei of high-iisk pioceduies they have peifoimed and its total cost. In the design piesented
so fai, theie would be no mechanismto suppoit such queiy. We thus must dene the concept of a
view, as an Entity Type having a deiivation iule that ietuins a collection, and whose piopeities
also depend on deiivation iules (ofen manipulating each item of that collection). Tis allows
the existence of viitual entities, whose infoimation is not stoied, but automatically deiived.
Te iequiiement could then be fullled by a new type of entity, e.g. High-Risk Tieatments
Income by Doctoi, that iteiates ovei doctois and theii pioceduies, aggiegating the income and
so on.
o.. Warehousing and Persistency
Because of the evolutive natuie of the model, it is veiy complex and inecient to map and main-
tain data and meta-data in a classic ielational database, even with the help of common tech-
nologies such as Object-Relational Mapping (ovm), oi othei techniques such as model-to-model
tiansfoimations. An alteinative would be to make use of object-oiiented database management
systems (oounms).
Still, peisistency based on static-scheming, such as automatic geneiation of uui code foi
specifying ielational databases schema and subsequent umi code foi manipulating data, which
attempts a semantic coiiespondence between both models, signicantly incieases the imple-
mentation complexity, paiticulaily when dealing with model co-evolution. Tis has been long
iefeiied to as object-ielational impedance mismatch [Ambo,], and evidence of such issues may
be obseived in the way ovm fiamewoiks attempt to deal with them, ofen iequiiing knowledge
of both iepiesentations and manual specication of theii coiiespondence (e.g., the migiation
mechanism in RoR). Teiefoie, using the lesystem foi stoiing seiialized objects, oi maintain-
ing objects nions inkey-valued oi evenielational databases, without tiying to achieve a semantic
coiiespondence, has ievealed to be a bettei choice.
Akin to the queiying mechanisms (sqi) piesent in ielational databases.
:o8 viiivici :vcui1ic1Uvi imviimi1:1io
Warehouse Design
Despite all the above conceins, waiehousing encapsulates the details of maintaining objects and
peisisting its infoimation, fiom the iest of the system, by exposing and consuming data and
meta-data (i.e., Things) and managing veisioning (i.e., thiough Versions and States). Its most
abstiact concept is that of a Container, a collection of possibly inteiielated objects, as depicted
in Figuie o.:,.
interface
IEnumerable
Get<T>()
New<T>()
GetInstances<T>()
Add<T>()
Remove<T>()
interface
IContainer
T: Thing
Thing
0..*
0..1
decoratee
0..*
0..1
OnNew()
OnSet()
OnRelate()
OnUnrelate()
OnDelete()
Container
Strategy
Memory
Container
Transaction
Changeset
Mutable
Changeset
Merged Container
base overlay
Figure o.,: Class diagiam of the waiehousing design.
Its behavioi can be extended and modied thiough inheiitance and composition by using
the Dicov:1ov, Cu:i oi Risvosiniii1v and S1v:1icv patteins [GHJV], with Things
iegaided as opaque, key-valued objects. Tiansient memoiy-only, diiect data-base access, lazy
and jouinaling stiategies (e.g., using C:cuis) aie just a fewexamples of existing (and sometimes
simultaneous) conguiations.
Persistency Design
Stoiing and fetching infoimation fiom an exteinal datasouice, such as a database, is accom-
plished by specializing a containei (typically MemoryContainer) and inteifacing with the pei-
sistency components mainly thiough the IProvider inteiface, as sketched in Figuie o.:o (p. :o).
By fuithei specialization, GreedyProvider and LazyProvider implement dieient access stiate-
gies, iespectively: (i) by fetching all objects to memoiy, and doing a deep-write whenevei a
commit occuis; (ii) by keeping a C:cui of latest iequested/modied objects. Fuithei details aie
given in o..: (p. ::o).
Te Datasource Provider iequiies an implementation of IDatasource and IFTSSource.
Te ist one will ultimately be iesponsible foi connecting to a thiid-paity system. Cuiiently,
Oghma piovides foui dieient datasouices, viz. (i) SQLite, (ii) Oiacle, and (iii) MongoDB. Ex-
tending it to othei technologies is just a mattei of appiopiiately ieimplementing the IDatasource
inteiface. Te second iequiiement is a full text-seaich piovidei (i1s). Cuiiently Oghma only has
A deep-wiite is a piocess that ensuies infoimation is immediately stoied, disiegaiding caching mechanisms.
:vcui1ic1Uv:i uicomvosi1io :o
interface
IEnumerable
Query<T>()
Commit<T>()
Search<T>()
History<T>()
interface
IProvider
T: Thing
Memory
Container
Datasource Provider
GreedyProvider
interface
IDatasource
interface
IFTSSource
LazyProvider
1 1
Figure o.o: Class diagiam of the peisistency design.
an implementation ovei i1s, piovided by SQLite (since it can be used independently), but some
pieliminaiy tests have been made with Apache Lucene.
o.. Communications
When components aie concuiiently iunning, a channel must be established between them
to exchange all the necessaiy infoimation. Due to the modulaiity of the piesented aichitec-
tuie, it is possible to achieve dieient conguiations. Tose involving concuiient iequests aie
(i) client-seivei, wheie seveial piocesses aie oichestiated by a cential seivice, (ii) web-based,
wheieas a single piocess is iunning but ieceiving multiple iequests, and (iii) distiibuted, wheie
data-ieplication mechanisms piovided by undeilying peisistency engines aie used to piopagate
changes acioss multiple seivices. Foi moie infoimation see o.:.: (p. o) and o..: (p. ::o).
Main Concerns
Establishing a channel of communication acioss dieient seivices oi components, iaises a num-
bei of piactical conceins that may aect the aichitectuie and design of oui system. Mainly,
we should be woiiied with (i) minimization bandwidth, so that we only communicate what is
needed, (ii) maximization of peifoimance, (iii) maintenance of consistency, so that the system
does not suddenly become incoiiect, and (iv) suppoiting concuiiency, so that multiple seivices
oi components can inteiact simultaneously.
HTTP-based Communications
Conguiing Oghma foi client-seivei oi web-based aichitectuies will tiiggei a u11v-based stiat-
egy of communication, wheie the cuiient implementation piovides a vis1 :vi foi communi-
cation between the Server Controller and Client Controller thiough a paii of HTTP Bridge
::o viiivici :vcui1ic1Uvi imviimi1:1io
and Server Dispatcher acting as Pvoxiis [GHJV]. Eveiy Thing is addiessable by its unique
identiei as a iesouice. Te contents of States and Changesets aie seiialized in xmi. Simple
queiies can be expiessed diiectly in the Uvi; those moie elaboiate iequiie vos1 methods.
By specialization of the communication layei, othei types of technology can be used foi
biidging the contiolleis (e.g .NET Remoting). Foi example, in the case of a single-usei stack,
the Client Controller would inteiact diiectly with the Server Controller. A dieient appioach
fiom the client-seivei aichitectuie is to use distiibuted key-value databases (e.g. CouchDB), to
handle both peisistency and communication. Heie, eveiy application would assume diiect ac-
cess to the contiollei, delegating the iesponsibility of disseminating contents to the undeilying
data waiehouse.
o. cnosscc11:No coNcvnNs
Te following sections iefei to conceins that aie not paiticulai to any component, but instead
aie peivasive in the oveiall solution.
o.. Serialization
To suppoit the exchange of infoimation, objects (i.e., data and meta-data) need to be demate-
iialized, piopagated, and again mateiialized acioss dieient environments. Te same applies
foi iequests and ieplies. Tis means that they must be serializable, i.e., the infoimation must be
conveitible into an encapsulated foimat that can be stoied (oi tiansmitted) and latei iecoveied
in the same oi anothei computei enviionment. Tis is also iequiied foi peisistency, as discussed
in ::o (p. :o8).
Te pioposed aichitectuie deals with two dieient ways of achieving this, viz. (i) state-based,
and (ii) opeiation-based seiialization. Using state-based, the object is seiialized declaratively, i.e.,
the value of each piopeity is desciibed as is. An example of a possible seiialization in xmi using
this stiategy is shown in Souice o., (p. :::).
In opeiation-based seiialization, objects aie desciibed constructively, i.e., it is given the nec-
essaiy steps to ieconstiuct the intended state, based upon piimitive operations. Te equivalent
of Souice o., (p. :::) can be seen in Souice o. (p. :::)
Tis stiategy iequiies a set of piimitive opeiatois to be known and piecisely dened by all
involved paities. Figuie o.:, (p. :::) shows the most basic opeiations heie consideied, viz. (i)
cieate instance, (ii) update attiibute, (iii) cieate ielation, (iv) iemove ielation and (v) delete in-
stance. Highei-level opeiations (i.e., those that manipulate meta-data) aie vaiiants of these, and
will be discussed in o.., (p. :::).
Object seiialization is also used foi bootstiapping the system, since it is easiei to maintain
cvosscU11ic cocivs :::
1 <oghma ve r s i on= 127 >
2 <data>
3 <house hr e f= 5b6d2926 - 4 c86 - 47 c8 - b1ec - a9db737b94e3 >
4 <name>Home sweet home</name>
5 <s t r e e t>
6 <s t r e e t hr e f= 46a49183 - 50 aa - 4 f 4f - 9437 - c3d1b66b4af b as s oc= 45 f 32dce
- 5438 - 4 b75 - 8 dce - aabfb03da19b />
7 </ s t r e e t>
8 </house>
9 <s t r e e t hr e f= 46a49183 - 50 aa - 4 f 4f - 9437 - c3d1b66b4af b >
10 <name>Pi ccadel y Avenue</name>
11 </ s t r e e t>
12 <streetnumber hr e f= 45 f 32dce - 5438 - 4 b75 - 8 dce - aabfb03da19b >
13 <number>35</number>
14 </ streetnumber>
15 </data>
16 </oghma>
Source o.: Example of a seiialized state-based commit.
Operation State
Create Delete Update Relate Unrelate
1..*
Batch
* {ordered}
Merge
produces
Figure o.;: Data and meta-data aie manipulated thiough operations, similaily to the Comm:u pattein.
Each opeiations applies (oi cieates) Things to pioduce new States.
both the infiastiuctuie desciiption and the ist veision of the model in a xmi le. Foi moie
infoimation, see o.:.: (p. ).
o..i Integrity
Te toleiant guideline states that interpretable behavior is preferred to system halt o.:.: (p. o).
Howevei, due to causal connections betweenthe meta-data and data, the systemmust ensuie that
a coiiect inteipietation is possible, and if not, to allow coiiections to be piovided. Integiity can
thus be divided into two sepaiate conceins, viz. (i) stiuctuial integiity, discussed in :, (p. :::),
and (ii) semantic integiity, detailed in :, (p. ::,).
o.. (Co-)Evolution
Allowing collaboiative co-evolution of model and data by the end-usei intioduces a new set of
conceins not usually found in classic systems. Tey aie (a) how to pieseive model and data in-
::: viiivici :vcui1ic1Uvi imviimi1:1io
1 <oghma ve r s i on= 127 >
2 <ops>
3 <c r e at e i d=5b6d2926 - 4 c86 - 47 c8 - b1ec - a9db737b94e3 type= house />
4 <update i d=5b6d2926 - 4 c86 - 47 c8 - b1ec - a9db737b94e3 at t r= house: : name >
Home sweet home</update>
5 <c r e at e i d=46a49183 - 50 aa - 4 f 4f - 9437 - c3d1b66b4af b type= s t r e e t />
6 <update i d=46a49183 - 50 aa - 4 f 4f - 9437 - c3d1b66b4af b at t r= s t r e e t : : name >
Pi ccadel y Avenue</update>
7 <c r e at e i d=45 f 32dce - 5438 - 4 b75 - 8 dce - aabfb03da19b type= s t r e e t />
8 <update i d=45 f 32dce - 5438 - 4 b75 - 8 dce - aabfb03da19b at t r= s t r e e t : : numbe r >
35</update>
9 <r e l a t e i d=5b6d2926 - 4 c86 - 47 c8 - b1ec - a9db737b94e3 node= h o u s e : : s t r e e t
t ar ge t=46a49183 - 50 aa - 4 f 4f - 9437 - c3d1b66b4af b as s oc=45 f 32dce - 5438 - 4
b75 - 8 dce - aabfb03da19b />
10 </ops>
11 </oghma>
Source o.: Example of a seiialized opeiation-based commit.
tegiity, (b) how to iepioduce pieviously intioduced changes, (c) how to access the state of the
system at any aibitiaiy point in the past, and (d) how to allow concuiient changes. Tese con-
ceins can be found in sofwaie quality attiibutes such as tiaceability, iepioducibility, auditability,
disagieement and safety, and aie commonly found on veision-contiol systems.
Typically, evolution is undeistood as the intioduction of changes to the model. Yet, the pie-
sented design does not establish a dieience between changing data oi meta-data; both aie ie-
gaided as the evolution of Things, expiessed as Operations ovei States, and peifoimed by the
same undeilying mechanisms as pieviously discussed in o..: (p. ::o). To piovide enough
expiessivity such that semantic integiity can be pieseived duiing co-evolution, model-level
Batches opeiate simultaneously ovei data and meta-data.
Sequences of Operations aie encapsulated as ChangeSets, following the His1ovv oi Ov-
iv:1ios pattein ,.o.: (p. 8:), along with meta-infoimation such as usei, date and time, base
veision, textual obseivations, and data hashes. Whenevei the fiamewoik validates oi commits
a ChangeSet, the contiollei uses the meige mechanism depicted in Figuie o.:8 (p. ::,), inspiied
by the Svs1im Mimi1o pattein ,.o.: (p. 8,). Tis dynamically oveilays the modications
onto the base veision by oideily applying each Operation, allowing foi behavioial iules to be
evaluated, and nally iesulting in a new veision.
Structural Integrity
Te stiuctuial integiity of the system is asseited thiough iules stated in the meta-model. Foi
example, Instances should confoim to theii specied Entity (e.g. they should only hold Prop-
erties which PropertyType belong to its Entity). Nonetheless, evolving the model may coiiupt
stiuctuial integiity, such as when moving a mandatoiy PropertyType to its supeiclass (e.g. if it
cvosscU11ic cocivs ::,
ChangeSet Operation
State
Version
base
provides
has
1..*
1..*
Merged
Container
interface
IContainer
1..*
background
overlay
Merge
spawn
base
changes
1..*
Figure o.8: Meiging mechanism used to validate and apply opeiations, which aie stoied in a Changeset.
doesnt have a default value, it can iendei some Instances non-compliant). Some model evolu-
tions can be solved by foieseeing integiity violations and applying piioi steps to avoid them (e.g.
one could ist intioduce a default value befoie moving the PropertyType to its supeiclass).
Anothei issue aiiises when paits of a composite evolution violate model integiity, although
the global iesult would be valid. Foi example if a PropertyType is mandatoiy, one cannot delete
its Properties without deleting itself and vice-veisa. Tis pioblemis solved by the use of Tv:s-
:c1ios oi Changesets, and by suspending integiity check until the end.
Semantic Integrity
Semantic integiity, on the othei hand, is much haidei to ensuie since it is not encoded as iules.
Te systemsimply cannot look to the iesults of an aibitiaiy evolution and infei the steps that lead
to it. Considei the scenaiio depicted in Figuie o.:, wheie an AttributeType age is ienamed to
date-of-birth, iecalculated accoiding to the cuiient date, and moved to its supeiclass Person.
Patient: Entity Type
before
after
Value = 32
Age: Property Type
Person: Entity Type
Value = 8/1/1978
Date of Birth: Property Type
Patient: Entity Type
Figure o.p: Example of a simple model evolution.
Would we iely on the diiect compaiison of the initial and nal models, a possible solution
would be to delete the attiibute age in Employee and cieate the attiibute date-of-birth in Per-
:: viiivici :vcui1ic1Uvi imviimi1:1io
son. Howevei, the oiiginal meaning of the intended evolution (e.g. that we wanted to stoie
biith-dates instead of ages) would be missed. To solve this pioblem, Oghma makes use of Mi-
cv:1ios ,.o., (p. 8), pioviding and stoiing sequences of model-level opeiations that cascade
into instance-level changes.
End-user Evolution
If all changes to the data and model aie pieseived, one can easily iecovei past infoimation. Tis
not only solves the afoiementioned issues, but it also biings to infoimation systems the same
notions of veisioning inheient to collaboiation in wikis and sofwaie development. In oidei foi
the end-usei to peifoim aibitiaiy model evolutions, a suciently laige libiaiy of (composable)
opeiations should be piovided. Tis also opens way to solve concuiient changes to the model,
by allowing the existence of multiple bianches of evolution, and piovide disagieement and iec-
onciliation mechanisms.
o., csvn :N1vnvncv
Adaptive object-models iequiie the giaphical usei-inteifaces to also automatically adapt,
thiough inspection and inteipietation of the model, and by using a set of piedened heuiis-
tics and patteins [WYWBo,]. A minimalistic woikow foi an automated cUi can be used based
on: (i) a set of giouped entiy-points declaied in the model, and fuithei piesented to the usei
giouped by packages, (ii) a list of the instances by Entity Type oi View, which show seveial de-
tails in distinct columns, infeiied fiom special annotations made in the model, (iii) pie-dened
automated views infeiied by model inspection (edition and visualization) based on heuiistics
that considei the caidinality, navigability and iole of piopeities, (iv) geneiic seaich mechanisms,
(v) geneiic undo and iedo mechanisms, (vi) suppoit of custom panels foi special types (e.g.,
dates) oi model-chunks (e.g., usei administiation), thiough PiUcis, etc.
Te ieactive usei inteiface piovided by Oghma also iesembles a type of oine mode, similai
to using veision-contiol systems. Usei changes, instead of being immediately applied, aie stoied
into the usei Changeset, and sent to the main contiollei to subsequently asseit the iesulting
integiity of applying changes, and piovide feedback on behavioial iules. Te usei can commit
its woik to the system when she wants to save it, ieview the list of opeiations she has made, and
additionally submit a desciiptive text about hei woik.
Awaieness of the systems evolution is achieved thiough the usage of seveial feedback tech-
niques such as (i) chaits showing the histoiy of changes, (ii) aleits foi simultaneous pendent
changes in the same subjects fiomothei useis, (iii) ieconciliation wizaids whenevei conicts aie
detected due to concuiient changes, etc.
uiviiovmi1 iiiov1 ::,
o.o uvvv:ovmvN1 vvvon1
e
n
t
r
o
p
y
(
b
y
t
e
s
)
3
1
5
1
1
0
0
0
0
0
2
3
0
4
3
5
2008 2009 2010 072007 072010
Figure o.io: Oghma code-base complexity. Tis chait shows the evolutionof code complexity betweenJuly
:oo, and July :o:o, measuied in compiessed bytes. Te veitical lines shows the cumulative
size in bytes of the compiessed dieiences pei day.
Oghma has been undei development since July :oo, as seen in Figuie o.:o, and is being used
foi pioduction-level applications, which will be detailed in Chaptei , (p. ::,). Te guie shows
the evolution measuied in entropy, of a codebase with an aveiage of thiee contiibutois. Table o.,
shows some base metiics of the code-base, which allows to diaf some leained lessons.
P:cx:ci Cvciomi1vic Comviixi1v Ri:i LOC
Usei Inteiface :,, :o,:
Coie :,: ::o,
Coie.Behavioial ::, 8o,
Coie.Behavioial.Giammai :, ,:o8
Coie.Stiuctuial 8 ::,
Coie.Views ::: ,8:
Coie.Contiollei :o8 ,,,
Coie.Waiehousing :,: ,
Coie.Communications :, 8,
Web Seivei :: ,,
SQLite Datasouice :8 ,,:
Oiacle Datasouice : ,:,
Tests :: ::,
Table o.: Code metiics foi the cuiient implementation of Oghma.
Subjectively, the majoiity of the development eoit was peiceived as centeied aiound the
stiuctuial and behavioial coie, and main contiollei. But, objectively, it is the domain specic
language and usei-inteiface that have the laigest code-base measuied in ioc. Tis somewhat
explains the fact that most of the advanced featuies suppoited by the infiastiuctuie, such as
::o viiivici :vcui1ic1Uvi imviimi1:1io
diveigence and ieconciliation mechanisms by object-veisioning, aie not yet piesented in the
usei-inteiface.
o.; coNc:cs:oN
In this chaptei we specied a iefeience aichitectuie foi adaptive object-model fiamewoiks,
and piovided some implementation details on Oghma, an industiial-level implementation of
a fiamewoik to build :om-based systems. We have identied the undeilying design piinciples
of incomplete by design systems by taking inspiiation fiom the guidelines of wikis. An high-level
aichitectuial view of Oghma was followed, and fuithei decomposed into its key components.
Ten, each components design was detailed, showing how its iole in the whole system is oi-
chestiated. Finally, a geneial oveiview of the development of Oghma was piovided, leaving the
details of its usage foi Chaptei , (p. ::,).
Chapter ;
Industrial Case-Studies
;. Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ;
;.i Complexity Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
;. Baseline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p
;. Iocvs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p
;., Zephyr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
;.o Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
;.; Iessons Iearned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i;
;.8 Validation Treats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i8
;.p Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ip
Te aichitectuie and fiamewoik pioposed in this disseitation was developed and validated with
the help of two case studies and one expeiiment that evaluated how the iesults woik in piactice.
Tis case studies weie mainly used foi validating the fiamewoik duiing its development phase,
and they piovided a tight feedback mechanism foi new iequiiements. Te (quasi-)expeiiment
was subsequently peifoimed to hainess some validation thieats inheient to the use of case-
studies in Chaptei 8 (p. :,:). Tis chaptei piesents how the case studies weie iun to assess the
usefulness of the piimaiy outcomes, and it ends with the analysis of a questionnaiie handed to
paiticipants to evaluate theii piofessional opinion on the fiamewoik.
;. nvsvnncn uvs:oN
Te ieseaich conducted so fai is as follows: (i) empiiical obseivation is used to detect, acquiie
and captuie iequiiements and patteins, as desciibed in Chaptei , (p. o:); (ii) the iesulting ie-
quiiements and patteins help in deiiving theoietical models to be inciementally iened into
specication and design aitifacts, (iii) the combination of these aitifacts diive the implementa-
tion of a fiamewoik, thus pioducing a set of ieusable components, detailed in Chaptei o (p. ,),
::8 iuUs1vi:i c:si-s1Uuiis
and fuithei seiving as basis to (iv) enteipiise-level commeicial use-cases, which in tuin piovide
feedback foi tuning the fiamewoik iegaiding Ho1 Svo1s, the Comvoi1 Linv:vv, and othei
infiastiuctuie capabilities. Tis chaptei is then focused on those use-cases to assess the impact
in pioductivity, maintainability, developei customization and oveiall customei success of the
conducted ieseaich.
Two use-cases weie studied, viz. (i) Locvs, a medium-sized infoimation system foi aichi-
tectuial and aicheological heiitage and (ii) Zephyr, a small infoimation system foi document
iecoids management.
;.i comv:vx:1v nNn:vs:s
Te assessment of the impact on the use cases will be based on complexity analysis of the ie-
sulting aitifacts. In algoiithmic infoimation theoiy, the Kolmogoiov complexity of an object,
such as a piece of text oi code, is a measuie of the computational iesouices needed to specify
that same object. Moie foimally, the complexity of a stiing is the length of the stiings shoitest
desciiption in some xed univeisal desciiption language. It can be shown that the Kolmogoiov
complexity of any stiing cannot be moie than a fewbytes laigei than the length of the stiing itself.
Stiings whose Kolmogoiov complexity is small ielative to the stiings size aie not consideied to
be complex [Wik:ob, LVo8].
In oidei to appioximate the uppei bounds of the Kolmogoiov complexity K(s), of a stiing s,
one can simply compiess that stiing with some method, implement the coiiesponding decom-
piessoi in the chosen language, concatenate the decompiessoi to the compiessed stiing, and
measuie the iesulting stiings length. Foi this puipose, the authoi used the bzip2 [Opeo8] ap-
plication, setting its compiession level to the suppoited maximum (-9). If one is only inteiested
in a time-seiies analysis of a sequence of stiings, calculating the compiessed deltas is enough to
piesent a ielative measuie of complexity (oi entiopy) between any two stiings [CVo,]. Foi that,
the authoi used the di [GNU:o] unix tool, with the minimal paiametei, again followed by a
bzip2 compiession, with the afoiementioned settings. Te iesults aie shown iepiesenting the
cumulative compiessed size in bytes, and the veitical lines the cumulative size of the compiessed
dieiences pei day. Note that it is the ielative, not the absolute numbei of bytes, that is ielevant,
i.e., the shape of the cuive and the oveiall giowth.
Using an entiopy measuiement to assess the complexity evolution of a sofwaie aitifact has
some benets ovei measuiing the numbei of lines of code (ioc) oi size in bytes. Foi example,
the impact of supeiuous usage of blank space, long stiings, oi duplicated code is considei-
ably attenuated afei undeigoing compiession, as obseived in Figuie ,. (p. :::) when compaied
to Figuie ,., (p. :::). Tis technique also seems to be able to show uctuations in entiopy even
when the cumulative numbei of ioc does not change.
n:siiii ::
;. nnsv::Nv
2005 2006 2007 2008 2009 2010
0
e
+
0
0
4
e
+
0
5
8
e
+
0
5
e
n
t
r
o
p
y
(
b
y
t
e
s
)
Figure ;.: Tis chait shows the cis: evolution between :oo and :o:o (o yeais).
To establish the baseline foi compaiison, othei piojects that met the following ciiteiia weie
analyzed using the same techniques: (i) piojects should be fiom the same company, and (ii)
developeis expeitise should be appioximately the same'. Two sample piojects aie shown in Fig-
uie ,.: and Figuie ,.:. Foi puiposes that will be explained latei, one should obseive that the
evolution in mostly sub-lineai, appioaching logaiithmic best-ts at the end of iteiations.
2010
0
5
0
0
0
0
1
0
0
0
0
0
1
5
0
0
0
0
e
n
t
r
o
p
y
(
b
y
t
e
s
)
052009 072010
Figure ;.i: Tis chait shows the smqvU evolution between May :oo and July :o:o (: yeai).
;. :ocvs
Te municipal city hall of Poito established the goal of developing an infoimation system to
manage the collections, piemises and places in the city, with ielevant inteiest iegaiding aichitec-
' If possible, the same developeis should have woiked on all piojects.
::o iuUs1vi:i c:si-s1Uuiis
tuial, uibanism, landscaping and aicheological tiaits. Due to the complexity and scope of this
topic, the fulllment of this goal had a ist phase consisting on the elicitation of sectoiial infoi-
mation based on the Inventoiy of Aichitectuial Heiitage of Poito (IPAP), and in the pioduction
of aicheological iecoids iegaiding inteiventions and mateiials.
In a subsequent phase, the objective was to develop and deploy a sofwaie solution called
Locvs - Management Architectural and Archeological Heritage of the City of Porto, compiomising
two mainsub-goals (i) to allowthe iteiative and inciemental stiuctuiing of available infoimation,
and fostei its exploiation, and also (ii) to suppoit the woikow of managing and evolving this
system of sectoiial infoimation [PFSP:o].
In this section, we biiey document the development of the sofwaie system components of
Locvs, biiey desciibing its idiosynciatic tiaits, main occuiiences, and puisued activities w.r.t.
its ielevant phases foi this disseitation, namely: (i) iequiiement analysis, (ii) application devel-
opment, and (iii) sofwaie evolution.
;.. Core Concepts
Te conceptual stiuctuie of infoimation iegaiding architectural heritage is based on a gioup of
analysis units, namely (i) public spaces, (ii) architectural collections, (iii) buildings and private
spaces, and (iv) construction and ornamental materials. Each unit of analysis aggiegates a set
of foims which fundamentally contains the most ielevant infoimation foi the chaiacteiization
and evaluation of the ieality undei analysis, and in some cases, complementaiy infoimation of
photogiaphic, caitogiaphic, bibliogiaphical and otheiwise aichival natuie.
Aichitectonic heiitage, eithei undei piotection (i.e., accoiding to the law in vigoi) oi in the
piocess of becoming piotected (and thus undei inteinal iegulations), is dened as those exis-
tences pioduced at an aichitectuial scale, namely (i) constiuctions of monumental natuie oi iel-
evant inteiest, and (ii) collections of building, stieets, constiuctions oi spaces which iecognition
as heiitage may not be stiaightfoiwaid, and which evaluation iequiie them to undeigo a pio-
cess of iigoious analysis of all the known elements and theii ielationship with the suiiounding
enviionment.
Aicheological heiitage iefeis to (i) all the aicheological inteiventions that take place within
the city boundaiies, (ii) all the iecoids andestate diiectly iesultant fiomthem, and(iii) to singulai
ndings oi donations. Te systemalso encompasses the piocess of appieciation foi uibanization
licensing, with iespect to (i) the delimitation of aieas with high aicheological potential, (ii) the
establishment of aieas of such potential, and (iii) the establishment of seveial othei iestiictions
iesultant fiomthe PlanoDiiectoi Municipal [Min, Camo]. It alsoincludes the management
of infoimation, in diveise media suppoits (not always standaid), diiectly ielated to the activity
of managing the aicheological heiitage of the city.
iocvs :::
;..i Time-Series Analysis
Te development of Locvs staited in the :,' July :oo,, simultaneously with the Oghma fiame-
woik, with the ist beta deployment occuiiing two months latei in the :' of Septembei. Te
allocated teamhad a maximumsize of thiee membeis duiing this peiiod. As seen in Table ,.:, the
ist nal deployment occuiied in :o' Maich :oo8, and the initial implementation was consid-
eied nished one month latei, in :8' Apiil. Te customei then initiated a :o months ievision,
until the ocial acceptance in ,' August :oo. Te pioject was then assigned a maintenance
peiiod of one yeai.
2007 2007 2007 2007 2007 2007 2007 2007 2007 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2008 2009 2009 2009 2009 2009 2009 2009 2009 2009 2009 2009 2009 2009 2009
8 99 10 10 11 11 12 12 1 2 33 44 5 66 77 8 99 10 10 11 11 12 12 11 22 33 44 55 6 77 8
Implementation
Deployment (Beta)
Deployment
Customer Revision
Implementation (Revision)
Deployment (Revision)
Table ;.: Chionogiam of the development of Locvs.
Because the model denitioncould be seiialized as a xmi le, it was ielatively easy to measuie
its evolution. Te chait piesented in Figuie ,., shows the cumulative numbei of lines of xmi
code, along with the numbei of changes.
2008 2009 2010
0
5
0
0
0
1
5
0
0
0
l
i
n
e
s
o
f
m
o
d
e
l
Figure ;.: Tis chait shows the Locvs model evolutionbetweenJuly :oo, andJune :o:o(, yeais), measuied
in xmi-seiialized lines of code. Te veitical lines aie the numbei of changes. Dashed veitical
lines maik majoi milestones seen in ,..:.
;.. Conclusion
Fiomthe obseivationof Figuie ,.,, it seems obvious that the pioject has undeigone thiee dieient
levels of evolution. Te ist one, between the ist beta deployment in Septembei :oo, and
::: iuUs1vi:i c:si-s1Uuiis
the last stable deployment in Apiil :oo8, coiiesponds to :oo:ooo lines of model desciiption.
Because of the closely iesemblance between the two aitifacts (i.e., the usi used in Oghma and
Umi), it was the analysts opinion that this ist desciiption of the model iepiesented an accuiate
tianslation of the analysis aitifacts, namely Umi class diagiams and use-case stoiies. Tis phase
ended aiound model ievision ,,o, afei : iteiations (i.e., deployments) with an aveiage time of
two-weeks pei iteiation.
e
n
t
r
o
p
y
(
b
y
t
e
s
)
9
9
1
2
5
0
0
0
5
3
0
4
8
2008 2009 2010 072007 062010
Figure ;.: Locvs model complexity. Tis chait shows the evolution of model complexity between July
:oo, and June :o:o, measuied in compiessed bytes. Te veitical lines display the cumulative
size in bytes of the compiessed dieiences pei day.
Te secondleapincomplexity occuiiedduiing the :omonths lengthievision, witha diastic
change of infoimation neai the end of :oo8. Te fact that Figuie ,., (p. :::) shows a two-fold
inciease in ioc (to ioughly ,ooo), suppoited by a moie stiiking inciease in entiopy shown by
Figuie ,., piovides evidence that the ievision piocess intioduced moie stiuctuial elements (and
hence new iequiiements) than those elicited duiing analysis.
Te nal leap in complexity occuiied neai the ocial acceptance of the nal application,
aiound August :oo (ievisions :,,::,8), which boosted the ioc to ioughly :::o: (a foui-fold
inciease when compaied to the pievious phase), but without an obseivable impact in the total
numbei of stiuctuial elements afei manual obseivation of the model. Tese iesults aie consis-
tent with the massive inciease of non-stiuctuial elements (e.g., invaiiants, deiived iules, views,
etc.), which denition became possible (and a piioiity) as soon as the coie stiuctuie of the appli-
cation stabilized. Nonetheless, it is still notable that they alone account foi an entiopy inciease
of moie than :oo.
In summaiy, fiom the ist deployment to the ocial acceptance (:o months), one can ob-
seive a ten-fold inciease in the model desciiption (measuied in ioc), a ve-fold inciease in the
model complexity (measuied in entiopy), and a two-fold inciease in basic stiuctuial elements
(measuiedinstiuctuial elements), suppoiting the claimthat tiaditional development appioaches
would not had eciently coped with the natuie of this pioject in the same time-span heie ob-
zivuvv ::,
seived.
;., zvvnvn
With the advent of mass digitalization of documents, which until now iequiied physical stoi-
age, the need of ensuiing its coiiect maintenance and long-teim pieseivation is becoming
paiamount. As such, the municipal city hall of Poito has the goal to implement a cential unit of
digitalization in chaige of this piocess.
;.,. Core Concepts
Te demateiialization of the physical piocesses in digital objects becomes indissociable of ceitain
piemisses, such as (i) the coiiect identication of the digitized documents, and (ii) the mainte-
nance of all inheient stiuctuie to each of these documents. It is thus necessaiy to validate and
attach to each document eveiy infoimation that needs to be maintained about it, to ease subse-
quent access to the infoimation and data pieseivation. Te veiy act of stoiing this infoimation
is a piocess that can involve a multitude of paiticipants along the seveial phases a digital object
ows, mainly because duiing the lifespan of a document, its iegistiation (and metadata) may still
being alteied while not yet associated with the digital object it iepiesents.
Te Zephyr application, piesented as an extension module to cis: [CPP:o], is a tool that
allows to collect metadata about digital objects. Useis iely on Zephyr to cieate iecoids foi (i)
digital compound objects, such as a Piocesso de Obia, and (ii) simple digital objects, such as
Actas, Requeiimentos, etc. Afei captuiing metadata foi each of these units, Zephyr tians-
foims this infoimation, cieating ingestion packets in ioxmi [Fed:o], and ingesting them in a
FedoiaCommons [Stao,] iepositoiy.
;.,.i Time-Series Analysis
Te chait piesented in Figuie ,., (p. ::) shows the model entiopy, along with the dieiences
pei day. Contiaiy to Locvs, this pioject ievealed veiy stable, with an actual deciease of entiopy
aiound Septembei :oo.
;.,. Conclusion
Zephyr was a single-peison pioject, with minimal changes to the model, and veiy quick appli-
cation deployment. Its piimaiy usage as a use-case` was to discaid thiee conceins iaised by the
When the developei was asked foi the ieason of this deciease, it was shown that the initial model contained some
assumptions that ievealed unnecessaiy afei the application was ist deployed.
` If one choses to ignoie the commeicial ieasoning that Oghma was used because development was alieady expected
to be fastei.
:: iuUs1vi:i c:si-s1Uuiis
Jul Set Nov Jan Mar Mai
0
2
0
0
0
4
0
0
0
6
0
0
0
8
0
0
0
e
n
t
r
o
p
y
(
b
y
t
e
s
)
Figure ;.,: Zephyi model complexity. Tis chait shows the evolution of model complexity between June
:oo and May :o:o, measuied in compiessed bytes. Te veitical lines display the cumulative
size in bytes of the compiessed dieiences pei day.
on-going expeiience with Locvs, viz. (i) was the fiamewoik suciently decoupled fiom its ini-
tial application to be used in othei pioducts, (ii) would a non-fiamewoik developei have time
to adapt to Oghma and still delivei in an acceptable timespan, and (iii) is the fiamewoik only
suitable foi systems with unstable iequiiements:
Obviously, theie is a stiong inteipietation to data piesented in Figuie ,.,; the application was
not incomplete by design. Tis was known and expected, but the success in deploying Zephyr
shows that the fiamewoiks, albeit not intentionally, can easily act as a Rapid Application Devel-
opment tool. Still, it helps to suppoit hypothesis H:, H,, H,-H, see Chaptei (p. ).
;.o scnvvv
Aquestionnaiie was handed to piofessionals that had signicant contact with the Oghma fiame-
woik. Tis questionnaiie was designed as a set of ve-point Likeit-scale [Lik,:] items, oi state-
ments, which the iespondent is asked to evaluate accoiding to any kind of subjective oi objective
ciiteiia, thus measuiing eithei positive oi negative iesponse to the statement. Te scale was set
as: (:) stiongly disagiee, (:) somewhat disagiee, (,) neithei agiee noi disagiee, () somewhat
agiee, and (,) stiongly agiee. Tese items wheie divided into the following gioups: (i) Back-
giound, (ii) Oveiall satisfaction, (iii) Development style and piocess, (iv) Futuie expectations,
and (v) New featuies.
Te subjective volatility is based on judgment of the subjects. All chosen subjects weie di-
iectly involved in the host piojects as developeis, analysts, domain expeits and/oi inteinal useis.
Tey also had the task of ieviewing iequiiements. Teiefoie, we believe that they weie capable
of accuiately and ieliably completing the suivey. Te iaw data can be found in Table E.: (p. :8:)
foi n = 7.
sUvviv ::,
;.o. Background
Te iesults fiom the backgiound of each paiticipant can be found in Table ,.:. Paiticipants of
the study foimed a ielatively heteiogeneous gioup (as evidenced by some values of ), but with
consideiable expeiience with the object-oiiented paiadigm, Umi, and the C- piogiamming lan-
guage. Most weie used to develop industiial-level applications, by doing iequiiements engi-
neeiing and analysis and specication of infoimation systems. Regaiding development style,
paiticipants weie mainly used to classic and agile development methodologies.
I have consideiable expeiience ::,, x
with object-oiiented fiamewoiks . ,.,, :.:,
with the Oghma fiamewoik . ,., :.:,
with the C- piogiamming language . .oo :.oo
doing iequiiements engineeiing . ,.,, o.8
developing industiial-level applications . .oo :.,,
analyzing and specifying infoimation systems . ,.8o :.o,
testing and ensuiing pioduct quality . ,., :.:,
with object-oiiented aichitectuie, design and implementation . .oo o.,8
with agile development methodologies . ,.: o.o
with classical development methodologies . ,.: o.,o
with foimal development methodologies . :.8o :.o,
with UML . ,.: :.::
Table ;.i: Backgiound iesults of industiial suivey, each line iepiesenting the data of a single question, with
coiiesponding means and standaid deviation values.
;.o.i Overall Satisfaction
Te iesults foi the oveiall satisfaction can be found in Table ,., (p. ::o). Paiticipants answeis
suppoits the hypothesis that the fiamewoik piovides a suitable infiastiuctuie foi developing in-
complete by design systems. Te answeis also piovide evidence that the development focus moie
on domain objects than implementation aitifacts, easing the tianslation of conceptual specica-
tions and the constiuction of usei-inteifaces. Te eoit of adding oi changing existing iequiie-
ments was stiongly consideied lowei than any othei conventional appioach, and the usage of
iesulting aitifacts in pioduction-level iequiiements was signicantly suppoited.
;.o. Development Style & Process
Te iesults foi the development style can be found in Table ,. (p. ::o). As expected, the answeis
suppoit the hypothesis that using such fiamewoik, and geneially :omsystems, would be moie in
line with the agile piinciples in what conceins embracing change, and having constant feedback
ovei the pioject (which would be veiy high when developing face-to-face with the client).
::o iuUs1vi:i c:si-s1Uuiis
Oveiall, I ::,, x
found Oghma suitable foi solving most tasks I needed . ,.8o o.,8
thought moie in teims of domain objects than implementation aiti-
facts
. .oo o.8:
found it dicult to diiectly tianslate specications into nal aitifacts . :.: o.o
was able to cieate and evolve the object model at least as iapidly as I
could cieate a specication
. .oo o.8:
was able to cieate and evolve the usei inteiface at least as iapidly as it
could noimally have been piototyped
. .: o.o
felt that any additional iequiiements iepiesented consideiable added
eoit compaied to conventional appioaches
. :.8o o.o
felt that any change of iequiiements iepiesented consideiable added
eoit compaied to conventional appioaches
. :.8o o.o
would use the iesulting application in pioduction-level enviionments
with minimal oi no change
. .: o.,o
Table ;.: Oveiall satisfaction iesults of industiial suivey, each line iepiesenting the data of a single ques-
tion, with coiiesponding means and standaid deviation values.
I found the development style of this setup suitable foi ::,, x
using in the context of agile methodologies . ., o.8
using in the context of classic methodologies . ,.,: o.,o
using in the context of foimal methodologies . ,.: o.,o
developing face to face with the client . ,.8o o.o
Table ;.: Development style iesults of industiial suivey, each line iepiesenting the data of a single ques-
tion, with coiiesponding means and standaid deviation values.
Te iesults foi the development piocess can be found in Table ,., (p. ::,). As expected, most
of the diculties wheie centeied aiound undeistanding and extending the fiamewoik. Leaining
to use the fiamewoiks capabilities of peisistency, usei-inteiface and iules languages didnt pose
a pioblem.
;.o. Future Expectations
Te iesults foi the development piocess can be found in Table ,.o (p. ::,). Tese iesults cleaily
suppoit the hypothesis that development would be fastei, less expensive, and easily maintainable
than conventional appioaches. Paiticipants also agiee that the nal application would be moie
compiehensively tested, although not as stiongly. Tis may be due to the switch of focus in qual-
ity; deployed applications would be as thoioughly tested as the fiamewoik is, but still dependent
on the coiiect inteipietation of the iequiiements. It is inteiesting to obseive that theie weie no
negative answeis in these items, and that the values of aie ielatively low.
iissos ii:viu ::,
Most of my diculties duiing development wheie ::,, x
dealing with peisistency . :.: o.o
building the giaphical usei inteiface . :., o.8
implementing the coie business logic . ,., o.8
leaining the domain specic language . :.,: o.,o
undeistanding the infiastiuctuie . ,.: o.,o
extending the fiamewoik . ,.,, o.8
Table ;.,: Development piocess iesults of industiial suivey, each line iepiesenting the data of a single ques-
tion, with coiiesponding means and standaid deviation values.
Given that the basic infiastiuctuie now exists, and with suitable modi-
cations to the development piocess, my expectations aie that subsequent
systems developed with it, when compaied to a moie conventional ap-
pioach, would be ::,, x
developed fastei . .,, o.,
less expensive . .: o.,o
moie compiehensively tested . ,.,: o.
easiei to maintain . .: o.,o
Table ;.o: Futuie expectations iesults of industiial suivey, each line iepiesenting the data of a single ques-
tion, with coiiesponding means and standaid deviation values.
;.; :vssoNs :vnnNvu
Te development and usage of Oghma taigeting adaptive applications allows us to elicit some
lessons:
Skilled developers. Te skills needed to develop and maintain this type of aichitectuie (at
the infiastiuctuie level) aie not tiivial to nd, and developeis aie not necessaiily at ease to
woik at these levels of abstiaction. On the othei hand, the skills needed to woik on top of
the developei aie ioughly at the same level as with tiaditional piogiamming languages.
Domain specic v.s. general purpose. Fiom a fiamewoik standpoint, theie is also a thin
balance between a fiamewoik that makes the cieation of new systems a quick and easy
piocess, and one that is exible enough to covei a wide scope of systems. Because it is
veiy tempting to make the fiamewoik addiess all use-cases using an adaptive and model-
diiven appioach, theie is a iisk of the nal models becoming as elaboiate and complex as
a full-blown piogiamming language. In this sense, Hooxs aie a key issue, as they aie not
always easy to foiesee, but they establish the boidei line between what should be iegaided
as pait of the fiamewoik and what is paiticulai behavioi of a specic instantiation.
Quick prototyping and agile development. Applying :om-based systems in industiy pie-
::8 iuUs1vi:i c:si-s1Uuiis
sented evidence of howeasy it is to quickly build a functional piototype that can be shown
to the customei, thus pioviding veiy eaily feedback befoie iening it into a pioduction-
level application. Not only the customei involvement in this piocess will inciease due to
the highnumbei of iteiations that become possible, ieducing the buidenof up-fiont design
by allowing an inciemental appioach to foimalization of the undeilying business model,
but end-usei development capabilities oeied by the fiamewoik could also ease the de-
pendency on the developeis. It is now the team belief that, now that the infiastiuctuie is
ieady, the two-yeai analysis piioi to the development could have been gieatly ieduced, by
eaily pioviding functional piototypes.
;.8 vn::un1:oN 1nnvn1s
One issue that could aect conclusion validity is the numbei of case-studies (two) and involved
sofwaie aichitects, engineeis, and analysts (eight), despite the sheei dimension of the Locvs case-
study, which collected data spawn thioughout thiee whole yeais. In the context of sofwaie en-
gineeiing ieseaich conducted in industiial settings, one should be awaie that the company is
taking a high iisk employing novel techniques, with unpiedictable iesults, to theii noimal woik-
ow. Nonetheless, the success of the Oghma fiamewoik, and the conclusions heie piesented,
weie found sucient to at least piovide the basis foi fuithei usage in subsequent piojects, which
will allow the haivest of moie data foi fuithei analysis.
Te paiticipants of the study also foimed an heteiogeneous gioup. Mainly, we had foui dif-
feient ioles dealing with the Oghma fiamewoik: the analysts, the domain expeits, the fiamewoik
useis, and the fiamewoik developeis. Although some ioles weie oveilapped by the same people,
we believe that having chosen a homogeneous gioup would lead to the disadvantages of decieas-
ing the numbei of subjects and aecting exteinal validity. As was also mentioned, the subjective
volatility is based on judgement of the subjects. Because all chosen subjects had diiect contact
with the host piojects as developeis, analysts, domain expeits oi inteinal useis, we believe that
they weie capable of accuiately and ieliably completing the suivey.
Finally, the most ielevant thieat to validation comes fiom the natuie of use-case analysis;
theie is simply too much vaiiables out of contiol. A moie solid validation would iequiie moie
thanone teamallocatedto the same pioject, using dieient technologies, as well as tightei contiol
ovei the development lifecycle to allowa iigoious measuiement of time and eoit spent by teams.
Since this issue cannot be puisued within oui industiial enviionment, it will be addiessed in the
next chaptei.
cociUsio ::
;.p coNc:cs:oN
Tis chaptei piesented two case studies built on top of the piimaiy outcomes fiom this disseita-
tion, as well as a questionnaiie intended to evaluate the piofessional opinion of the paiticipants.
We based most of the time-seiies analysis on infoimation theoiy, specically by measuiing Kol-
mogoiov complexity and consideiing the piojects lifecycles, whichallowed to make compaiisons
among piojects using dieient technologies. Most hypothesis piesented inChaptei (p. ) weie
suppoited by evidence, although some validation thieats iemain due to the natuie of use-case
analysis. Tose issues will be addiessed in the next chaptei as a quasi-expeiiment peifoimed in
a contiolled enviionment.
:,o iuUs1vi:i c:si-s1Uuiis
Chapter 8
Academic Quasi-Experiment
8. Research Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.i Experiment Description . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8. Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p
8. Objective Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . p
8., Validation Treats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p
8.o Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
Tis chaptei details a quasi-expeiiment conducted within a contiolled expeiimental enviion-
ment using the Oghma fiamewoik. Although the industiial usage of the fiamewoik piovides
piagmatic evidence of its benets, as detailed in Chaptei , (p. ::,), seveial of the thieats inheient
to that type of validation aie heie discaided, by peifoiming a study on gioups of MSc students
building an infoimation system fiom sciatch, and applying two dieient tieatments, viz. (i) the
baseline, using Java, MySQL and Eclipse, and (ii) the expeiimental, using Oghma and Miciosof
Visual Studio. Pie-test evaluation and post-test questionnaiies aie used to assess the outcomes
of each tieatment, and the nal iesults ieveal consistent with those piesented in the pievious
chaptei.
8. nvsvnncn uvs:oN
(Quasi-)expeiiments conducted in an academic context should be iandomized, multiple-
gioup, compaiison designs, which may be implemented as pait of giaduate student teams lab
woik [CJMS:o]. Foi this expeiiment, :8 MSc students fiom the Integiated Masteis in Infoimat-
ics and Computing Engineeiing, lectuied at the Univeisity of Poito, Faculty of Engineeiing, weie
ieciuited. Tey all weie ' yeai students which chose to take an optional couise on Aichitectuie
of Sofwaie Systems, and hence weie inteiested and motivated in the design and constiuction
of complex (medium to laige-scale) systems.
:,: :c:uimic qU:si-ixvivimi1
Treatment A
Treatment B
Group
Formation
Main Tasks
Evolution
Tasks
Questionnaire
2 hours
1 hour
Figure 8.: Expeiiment design. Each gioup ieceived one of two possible tieatments. All then pioceeded
foi the main tasks. Afei two houis, the evolution tasks weie handed. At the end of the , houi,
the subjects fully stopped theii tasks, and pioceeded to answei the questionnaiie.
8.. Treatments
To peifoim the expeiiment, two dieient tieatments weie applied:
Baseline treatment. Te establishment of the baseline followed tiaditional development
methodologies and tools, assumed as familiai to the subjects, to constiuct and evolve the
givensystem. Tese consisted inJava foi piogiamming, suppoited by MySQLas a database
backend, and Eclipse as an IDE.
Experimental treatment. Te system undei test, Oghma, was handed to the subjects that
ieceived the expeiimental tieatment.
8..i Pre-test Evaluation
It is impoitant to ensuie that the base skills foi eveiy membei does not pose any signicant statis-
tical deviation. To ensuie that, a selectionof a subset of couises basedontheii academic tiack was
made, which could inuence the expeiiment outcome, namely: (i) Piogiamming Fundamentals,
(ii) Piogiamming, (iii) Algoiithms and Data Stiuctuies, (iv) AlgoiithmDesign and Analysis, (v)
Sofwaie Engineeiing, (vi) Sofwaie Development Laboiatoiy, and (vii) Infoimation Systems.
Te giades of each subject that paiticipated in the expeiiment can be found in Table A.: and
Table A.: (p. :o,). An independent-samples t-test was conducted to compaie the aveiage stu-
dents giades foi expeiimental and baseline gioups. As shown in Table 8.: and Table 8.: (p. :,,),
theie was no signicant dieience in the scoies foi the expeiimental (M = 14.20, SD = 1.27)
and baseline (M = 13.87, SD = 0.77) conditions; t(13) = 0.572, = 0.577, within a ,
condence inteival.
GvoUv N Mi: S1u. Divi:1io S1u. Evvov Mi:
: :.:oo :.:,,8 o.:o
: o :,.8o, o.,o, o.,::,
Table 8.: Student giades gioup statistics.
visi:vcu uisic :,,
F Sic. 1 ui Sic. (:-1:iiiu)
Eq. V:v. AssUmiu .,: o.o,8 o.,,: :,.ooo o.,,,
Eq. V:v. No1 AssUmiu o.o,: ::.: o.,,8
Table 8.i: Independent Samples Test. Te ist two columns aie the Levenes Test foi Equality of Vaiiances,
showing a signicance gieatei than o.o,. Te othei thiee columns aie the t-test foi Equality of
Means. Since we can assume equal vaiiances, the :-tailed value of o.,,, allow us to conclude
that theie is no statistically signicant dieience between the two conditions.
Teie is also the need to ensuie that all subjects shaie common skills with iespect to meta-
modeling, aichitectuial and design patteins, adaptive object-models and its ecosystem. Al-
though both GoF [GHJV] and POSA [BMR
+
o] patteins aie pait of the cuiiicula, it was
iequiied to add two lectuies about AOMs piioi to peifoiming the expeiiment. In these lectuies,
both gioups leained the coie patteins of AOMs, and peifoimed a simple exeicise of implement-
ing the Tvvi-On,ic1 [JW,] pattein in Java.
Neveitheless, it should be noted that the subjects undei the expeiimental tieatment nevei
had any contact with the fiamewoik piioi to the expeiiment. All the available infoimation was
handed at the beginning of the expeiiment, as a small digital document, whichis heie iepioduced
in Appendix D. Tis documentation was delibeiately incomplete, containing slight omissions
and inconsistencies foi the puipose of simulating a ieal-woild documentation and avoid any
bias towaids the tasks subjects weie meant to peifoim.
8.. Process
Tis (quasi-)expeiiment was intended to assess seveial distinct claims, which weie matched into
two dieient phases: development and maintenance. Te two tieatment gioups weie fuithei
split in gioups of thiee subjects. Each gioup would entei a iestiict laboiatoiy enviionment, with
(i) a single computei available with inteinet access, and (ii) a whiteboaid.
Data Collection
Te expeiiment had two live video feeds being iecoided: (i) a standaid cameia, pointing diiectly
at both the subjects and the whiteboaid, and (ii) a screencast of the computei the subjects weie
using. Tis was used to measuie time, coiiectness and complexity of the pioduced aitifacts non-
intiusively. Te analysis of this data is made in 8. (p. :).
First Phase: Construction
In the ist phase, a small Requiiements Specication Repoit wheie handed in a closed enve-
lope, which included biief usei stoiies and Umi class diagiams semi-foimalizing a small system
:, :c:uimic qU:si-ixvivimi1
foi managing scientic confeiences. Teii objective would be to implement a full system using
theii given technique and iestiictions. While the time available foi puisuing the implementation
could be based in eoit estimations made by sofwaie-engineei piofessionals, theie was seveie
time constiaints fiom the availability of the subjects. As such, the oveiall time limit was set to ,
houis, thus ieseiving : houis foi this phase. Te exact details of each task can be found in 8.:.:.
Second Phase: Evolution
Te subjects weie not awaie of a second phase, which goal was to assess the eciency in adapting
to changing iequiiements. As such, : houi befoie the time limit, the subjects weie handed a
second envelope as detailed in 8.:.: (p. :,,).
8.. Post-Test Questionnaire
At the end of the expeiiment, i.e., afei the thiee houis time limit, the questionnaiie in Appendix
B was handed to the subjects. Tis questionnaiie was designed using a Likeit scale [Lik,:]. Tis
psychometiic bipolai scaling method contains a set of Likeit items, oi statements, which the
iespondent is asked to evaluate accoiding to any kind of subjective oi objective ciiteiia, thus
measuiing eithei positive oi negative iesponse to the statement. In this expeiiment, we used ,
ve-point Likeit items with the following foimat: (:) stiongly disagiee, (:) somewhat disagiee,
(,) neithei agiee noi disagiee, () somewhat agiee, and (,) stiongly agiee. Te answeis fiom all
the paiticipants aie detailed in Appendix C, and fuithei analyzed in 8., (p. :,).
8.., Independent Validation
Te independent expeiimental validation of claims is not as common in Sofwaie Engineeiing as
in othei, moie matuie sciences. Teiefoie, the (quasi-)expeiiment heie detailed was designed as
an experimental package, to be peifoimed in dieient locations, and lead by dieient ieseaicheis,
in oidei to enhance the ability to integiate the iesults obtained and allow fuithei meta-analysis
on them.
8.i vxvvn:mvN1 uvscn:v1:oN
Te following sections desciibe eveiy task given to the paiticipants, quoting the piesented text.
8.i. First Phase: Construction
Duiing the constiuction phase the tasks weie mainly focused on assessing how eciently the
paiticipants could inciementally build an infoimation system, with thiee iteiations (oi ieleases):
ixvivimi1 uiscviv1io :,,
You have been given the job of implementing an information system for managing scientic
conferences. Afer a careful requirements analysis, the engineers have concluded that the system
should be implemented in three distinct iterations. For each of these iterations one for each
task youll nd a detailed cmi class diagram. Due to the fact that the client wants to validate
your system at the end of each iteration, youll have to produce three intermediate releases.
Each release should have a working Graphical User Interface and Persistency Engine. Te user
should be able to create, read, update and delete the modeled concepts.
Description of Task
* *
open-enum
Scientic Area
Name: text
Website: url
entrypoint
Conference
Number: nat
Year: nat
Theme: enum
Description: text
StartDate: date
EndDate: date
Edition
1..*
*
1..*
colocated-with
Class Diagram Task 1
Figure 8.i: Task :
Te ist task was designed to yield a veiy simple system, wheie only a single scieen would
be needed to view and edit the infoimation. Teie was no polymoiphism, shaied aggiegations
oi any type of conditional iules, and the whole system could be ioughly stoied in two database
tables:
In this task, youll implement the basic concepts of a scientic conference. A conference is typi-
cally related to a specic Scientic Area (e.g., Computer Science or Sofware Engineering), but
is it not uncommon to nd conferences related to several areas. Each conference has several
editions, normally once per year (e.g., Pattern Languages Of Programs :oo8). Due to several
factors, it is also common for conferences to be co-located with others. For example, the :oo8
editions of Pattern Languages of Programs and Object-Oriented Programming, Systems,
Languages o Applications were co-located. In the end of this iteration, the user should be
able to manage Conferences and Editions. Model elements tagged with the stereotype entry-
point represent main entry points to the system (e.g., the user should be able to invoke a list of
Scientic Areas from the applications main menu or similar mechanism).
Description of Task i
Te second task was designed to intioduce the need foi moie scieens (due to indexation), and
a false sense of polymoiphism in the session type. Te numbei of database tables could giew
fiom two to foui, but with minimal modication to exiting aitifacts:
:,o :c:uimic qU:si-ixvivimi1
Name: text
entrypoint
Index
A
B
C
enum
Ranking
*
0..*
1
Day: date
Start: time
End: time
Session
Presentation
Poster
0..*
* *
open-enum
Scientic Area
Name: text
Website: url
entrypoint
Conference
Number: nat
Year: nat
Theme: enum
Description: text
StartDate: date
EndDate: date
Edition
1..*
*
1..*
colocated-with
Class Diagram Task 2
Figure 8.: Task :
In this task, youll extend your systemwith two extra features. Te rst one Indexes classies
conferences according to a rating system per year. For example, the index ISI Veb of Knowl-
edge rates thousands of conferences every year. Te rating is given to a particular edition of a
conference, so ISI could rate Pattern Languages of Programs as an A in :o:,, and as a B in
:o:o. Te second one - Sessions - allows the user to manage the program (contents) of a confer-
ence. Tere are two types of sessions. (a) Presentations, and (b) Poster Sessions. For example,
the :oo8 edition of Object-Oriented Programming, Systems, Languages o Applications had
one (:) poster session, and twelve (::) presentations.
Description of Task
Te thiid task was delibeiately designed to iequiie moie complex usei-inteiaction and condi-
tional iules, involving shaied many-to-many ielations and ielation piopeities:
In this task, youll provide your system by adding some remaining core concepts of scientic
conferences. People that participate in conferences as authors have to submit at least one pa-
per, either alone or with colleagues. In addition, they may be Chairs, Organizers or simple
Participants. Dierent editions normally have dierent chairs and organizers.
Description of Task
Te puipose of the fouith task was to bieak any abstiactions that could have emeiged duiing
the pievious iteiations:
In this nal task, for reasons of practicability, the client has requested that whenever a paper
is submitted to a conference, an email should be sent for the Chairs with the Submission and
Authors relevant information.
ixvivimi1 uiscviv1io :,,
*
*
* *
Title: text
Paper: le
Submission
Name: text
Afliation: text
Email: url
entrypoint
Person
Chair
Organizer
Participant
enum
RoleType
Role
0..*
0..1
1..*
Name: text
entrypoint
Index
A
B
C
enum
Ranking
*
0..*
1
Day: date
Start: time
End: time
Session
Presentation
Poster
0..*
* *
open-enum
Scientic Area
Name: text
Website: url
entrypoint
Conference
Number: nat
Year: nat
Theme: enum
Description: text
StartDate: date
EndDate: date
Edition
1..*
*
1..*
colocated-with
Class Diagram Task 3
Figure 8.: Task ,
8.i.i Second Phase: Evolution
Duiing the evolution phase the tasks weie focused on assessing of eciently the paiticipants
could handle change in theii aitifacts:
During one of the validation sessions with the users, both of themrealized that some core aspects
of the system were neglected, and, as such, there would be slight changes in the requirements in
order to improve the overall value of the application.
Description of Requirements Change
Tis task was designed with the intention of changing some basic assumptions that would natu-
ially emeige in Task :. Te Scientic Aiea enumeiation was piomoted to an entrypoint. It also
intioduced tiue polymoiphism in Event, due to the ielation between Confeience and Woik-
shop:
It is imprecise to say that every scientic meeting is a conference. In fact, it is quite common for
conferences and workshops to occur simultaneously. Usually, workshops take place as events
within a conference. Tis way, Conference should now be considered a specialization of Event.
the same applies to Vorkshop. In addition, a workshop can only occur in the context of a single
Conference. Additionally, it is now relevant to promote Scientic Area to an entry point in the
system.
Description of Requirements Change i
Tis task was veiy small, but it could easily disiupt pievious assumptions. Te false poly-
moiphism in the type of Session (which could have been implemented using a simple type-
:,8 :c:uimic qU:si-ixvivimi1
Name: text
entrypoint
Scientic Area
* *
Conference
Workshop
0..1
0..* Name: text
Website: url
entrypoint
Event
Number: nat
Year: nat
Theme: enum
Description: text
StartDate: date
EndDate: date
Edition
1..*
*
1..*
colocated-with
Class Diagram Evolution 1
Figure 8.,: Changes foi Task :
disciiminatoi), now lead to the need of inheiitance, by extending the allowed sub-types and
intioducing a piopeity that only makes sense in Keynote:
A new session type is added the Keynote for which is necessary to store its synopsis.
Name: text
entrypoint
Index
A
B
C
enum
Ranking
*
0..*
1
Day: date
Start: time
End: time
Session
Presentation
Poster
Sinopse: text
Keynote
1..*
Name: text
entrypoint
Scientic Area
* *
Conference
Workshop
0..1
0..* Name: text
Website: url
entrypoint
Event
Number: nat
Year: nat
Theme: enum
Description: text
StartDate: date
EndDate: date
Edition
1..*
*
1..*
colocated-with
Class Diagram Evolution 2
Figure 8.o: Changes foi Task :
Description of Requirements Change
Tis nal task biing seveial iules to the system: the new ielations between Submission, Pie-
sentation and Postei oveiiide the pievious ielation between Submission and Session, specifying
dieient caidinalities in ielation ends. Role now also caiiies an additional piopeity:
Te users realized that, although Presentation and Poster sessions are always related to Sub-
mission (via Session), a presentation is always about a single submission, while posters sessions
u:1: ::ivsis :,
normally occur in parallel (i.e., all submitted posters presented at the same time). Keynotes,
on the other hand, have nothing to do with submissions, and are presented by a high-prole
invited researcher in a particular eld. A subtle detail is that the relationship between Person
and any particular Conference should allowusers to store some ^otes over the registration (e.g.,
some guests dont pay fee, other have special requests like vegetarian food, etc.)
*
*
* *
Title: text
Paper: le
Submission
Name: text
Afliation: text
Email: url
entrypoint
Person
Chair
Organizer
Participant
enum
RoleType
0..*
0..1
0..1
1
1..*
1 0..*
Notes: text
Role
Name: text
entrypoint
Index
A
B
C
enum
Ranking
*
0..*
1
Day: date
Start: time
End: time
Session
Presentation
Poster
Sinopse: text
Keynote
1..*
Name: text
entrypoint
Scientic Area
* *
Conference
Workshop
0..1
0..* Name: text
Website: url
entrypoint
Event
Number: nat
Year: nat
Theme: enum
Description: text
StartDate: date
EndDate: date
Edition
1..*
*
1..*
colocated-with
Class Diagram Evolution 3
Figure 8.;: Changes foi Task ,
8. un1n nNn:vs:s
Te post-test questionnaiie handed to the subjects was designed using a Likeit scale see Ap-
pendixes B and C. Tis expeiimental design used a , ve-point Likeit items with the following
foimat: (:) stiongly disagiee, (:) somewhat disagiee, (,) neithei agiee noi disagiee, () somewhat
agiee, and (,) stiongly agiee. Te , items wheie divided into the following ielevant gioups:
:. Background. Although an objective compaiison between the backgiound of each gioup
was alieady conducted using the subjects aveiage giades in key couises 8.:.: (p. :,:), it
is impoitant to asseit that theie is no subjective dieience among the paiticipants with
iespect to basic skills, with the exception of BG:.:, since no gioup had any piioi contact
with the Oghma fiamewoik.
:. External Factors. Analysis of exteinal factois allowed us to iemove any validation thieats
conceining the expeiimental conditions, paiticulaily the fact that subjects weie being
video-taped.
:o :c:uimic qU:si-ixvivimi1
,. Overall Satisfaction. Tis was the main gioup that piovided subjective validation to the
thesis, by questioning subjects about theii peifoimance, eectiveness, coiiectness, and
ieaction to the intioduced iequiiements change in Phase :.
. Development Process. Tis gioup of questions intended to put the expeiiment in pei-
spective with both pievious subject expeiiences, and the main diculties they had en-
counteied.
We will now piesent a detailed analysis foi the most ielevant items in the questionnaiie. Let
the null hypothesis be denoted as H
0
, the alteinative hypothesis as H
1
, the baseline gioup as
G
b
, the expeiimental gioup as G
e
, and the piobability estimatoi of wiongly iejecting the null
hypothesis. Ten, the alteinative hypothesis aie eithei: (i) H
1
: G
e
G
b
, the expeiimental
gioup dieis fiom the baseline, (ii) H
1
: G
e
G
b
, the measuie in the expeiimental gioup
is lowei than the baseline, oi (iii) H
1
: G
e
G
b
, the measuie in the expeiimental gioup is
gieatei than the baseline. Te outcomes of the two tieatments weie compaied foi eveiy answei
using the non-paiametiic, two-sample, iank-sum Wilcoxon-Mann-Whitney [HW] test, with
n
1
= n
2
= 9. Te signicance level foi all tests was set to ,. Piobability values of
0.05 aie consideied signicant, and 0.01 consideied highly signicant. Te coiiesponding
alteinative hypothesis aie fuithei detailed foi each question, and the iaw data can be found in
Table C.: (p. :,:).
8.. Background
Althoughanobjective compaiisonbetweenthe backgioundof eachgioupwas alieady conducted
using the subjects aveiage giades in key couises 8.:.: (p. :,:), this section iejects any subjective
dieience among the paiticipants with iespect to theii basic skills, despite a delibeiate disadvan-
tage in the expeiimental gioup w.r.t. the piogiamming language and enviionment, as obseived
in the iesults of items BG:.: and BG:.,.
BG. I have considerable experience using frameworks
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 1.000) in the scoies foi the ex-
peiimental ( x = 3.44, = 0.53) and baseline ( x = 3.44, = 0.88) conditions, as seen in Ta-
ble 8., (p. ::). Students ievealed a veiy modest knowledge on using fiamewoiks, consistent with
theii academic tiack.
BG.i I have considerable experience with this particular framework
Let H
1
: G
e
G
b
, theie was highly signicant dieience ( = 0.001) in the scoies foi the
expeiimental ( x = 1.11, = 0.33) and baseline ( x = 3.11, = 1.27) conditions, as seen
u:1: ::ivsis ::
ixvivimi1:i n:siiii s1:1is1ics
::,, x ::,, x H
1
W
BG:.: . ,. o.,, . ,. o.88 :.o :.ooo
BG:.: . :.:: o.,, . ,.:: :.:, oo.o o.oo:
BG:., . ,.,, :.:: . .,, o.,o :., o.o,
BG:. . :.,o o.,, . :.,8 o., ,o., o.,,:
BG:., . ,.:: o., . ,.oo :.oo ,., o.o:
BG:.o . .,, o.,: . ,. o.88 o:., o.o,o
BG:., . ,.o, o.,: . :.8 o., o:.o o.o,
BG:.8 . ,.8 o.oo . ,.o, o.,: 8., o.,,
BG:. . :.,8 o.8, . :.o, o.,: ,.o o.88
BG:.:o . .:: :.o, . ,. o.,, ,8., o.:o:
Table 8.: Summaiy of Backgiound iesults, including the values of the non-paiametiic signicance Mann-
Whitney-Wilcoxon test. Items with signicant statistical dieience in theii scoie have the value
of the piobability estimatoi undeilined.
in Table 8.,. Tis iesult is in accoidance to the fact that no subject had any piioi contact with the
Oghma fiamewoik.
BG. I have considerable experience with this particular programming language
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.045) inthe scoies foi the expeiimental
( x = 3.33, = 1.12) and baseline ( x = 4.33, = 0.50) conditions, as seen in Table 8.,. Tis
iesult was also expected, since Java plays a signicant iole in the students cuiiicula, with C- only
being maiginally mentioned, if at all.
BG. I have considerable experience developing industrial-level applications
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.731) in the scoies foi the expeii-
mental ( x = 2.56, = 0.73) and baseline ( x = 2.78, = 0.97) conditions, as seen in Table 8.,.
As expected fiom ' yeai students, theii subjective opinion shows that they weie not veiy expe-
iienced in developing industiial-level applications.
BG., I have considerable experience analyzing and specifying information systems
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.962) in the scoies foi the expeii-
mental ( x = 3.11, = 0.93) and baseline ( x = 3.00, = 1.00) conditions, as seen in Table 8.,.
Similaily to item BG:., theii subjective opinion is that they possess modeiate expeiience in
infoimation system analysis and specication.
:: :c:uimic qU:si-ixvivimi1
BG.o I have considerable experience with object-oriented architecture design and implemen-
tation
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.036) inthe scoies foi the expeiimental
( x = 4.33, = 0.71) and baseline ( x = 3.44, = 0.88) conditions, as seen in Table 8., (p. ::).
Tese iesults aie odd, since theii academic backgiound was the same, and the pie-test evaluation
8.:.: (p. :,:) showed no statistical deviation on theii giades. We assume this item was piobably
inuenced by the oveiall success using the Oghma fiamewoik, which changed theii subjective
undeistanding on how they peiceive object-oiiented aichitectuies.
BG.; I have considerable experience with agile development methodologies
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.043) inthe scoies foi the expeiimental
( x = 3.67, = 0.71) and baseline ( x = 2.89, = 0.93) conditions, as seen in Table 8., (p. ::).
Similaily to itemBG:.o, we also assume some subjective undeistanding on theii peiception afei
the expeiiment was done. Neveitheless, the scoies aie lowei than itemBG:.8, which is consistent
with theii academic backgiound.
BG.8 I have considerable experience with classical development methodologies
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.457) in the scoies foi the ex-
peiimental ( x = 3.89, = 0.60) and baseline ( x = 3.67, = 0.71) conditions, as seen in Ta-
ble 8., (p. ::). As expected, bothscoies aie consistently highei thanthe two othei methodologies
in items BG:., and BG:., which is consistent with theii academic backgiound.
BG.p I have considerable experience with formal development methodologies
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.848) in the scoies foi the ex-
peiimental ( x = 2.78, = 0.83) and baseline ( x = 2.67, = 0.71) conditions, as seen
in Table 8., (p. ::). Also as expected, both scoies aie consistently lowei than the two othei
methodologies in items BG:.8 and BG:., which is consistent with theii academic backgiound.
BG.o I have considerable experience with UMI class diagrams
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.102) in the scoies foi the ex-
peiimental ( x = 4.11, = 1.05) and baseline ( x = 3.44, = 0.73) conditions, as seen in Ta-
ble 8., (p. ::). Both gioups exhibited positive iesponses to this item (which is also consistent
with theii academic backgiound), and thus not posing a validation thieat to the usage of UML
class diagiams in theii tasks.
u:1: ::ivsis :,
8..i External Factors
In the design of this expeiiment, data gatheiing was done using video-cameias, miciophones,
and sofwaie that captuied scieencasts. Fiom the expeiimental point of view, it is impoitant to
discaid if these devices, and the fact that paiticipants knew they weie being obseived, posed a
thieat to validation. Additionally, each tieatment weie applied to gioups of thiee paiticipants,
so it is also impoitant to analyze if they woiked well togethei and didnt ieacted negatively to
the expeiiment. Tis is a two-fold analysis, both focusing on the paiticipants as a whole, and in
gioup compaiison.
ixvivimi1:i n:siiii s1:1is1ics
::,, x ::,, x H
1
W
EF: . :.8 o.,8 . :.,8 :., ,o.o o.,8
EF: . . o.,, . ,.,, :.:: o,., o.o,,
EF, . .o, o.,o . ,.8 o.,8 o,.o o.o,,
Table 8.: Summaiy of Exteinal Factois iesults, including the values of the non-paiametiic signicance
Mann-Whitney-Wilcoxon test.
EF I felt disturbed and observed by the cameras
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.389) in the scoies foi the expeii-
mental ( x = 1.89, = 0.78) and baseline ( x = 1.78, = 1.39) conditions, as seen in Table 8..
Moieovei, . of the total paiticipants felt indieient to the fact they weie being obseived by
the cameias, so this factoi can be discaided as a thieat.
EFi I enjoyed programming in the experiment
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.037) inthe scoies foi the expeiimental
( x = 4.44, = 0.73) and baseline ( x = 3.33, = 1.12) conditions, as seen in Table 8.. In othei
woids, this item was measuiing the fun factor oi the novel factor. Although both gioups ieacted
positively to the expeiience, 8 of the paiticipants in the expeiimental gioup agieed with the
asseition, among which o, stiongly agieed with it. Despite the seveial inteipietations to this
iesults, it is believed that the geneial success of the expeiimental gioup, as well as the feeling of
woiking with something new, contiibuted to the statistical dieience obseived. Nonetheless,
only two of the total paiticipants had a mildly negative feeling towaids the expeiiment, so this
factoi can also be discaided as a thieat to the whole expeiiment.
: :c:uimic qU:si-ixvivimi1
EF I would work with my partners again
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.035) inthe scoies foi the expeiimental
( x = 4.67, = 0.50) and baseline ( x = 3.89, = 0.78) conditions, as seen in Table 8. (p. :,).
Similaily to item EF:, the expeiimental gioup showed a slight evidence in woiking with the
same paitneis again. Nonetheless, the fact that theie weie no negative answeis fuithei allow us
to discaid this factoi as a thieat to the whole expeiiment.
8.. Overall Satisfaction
Tis was the main gioup that piovided subjective validation to the thesis, by questioning subjects
about theii peifoimance, eectiveness, coiiectness, and paiticipants ieaction to the intioduced
iequiiements change in Phase :.
ixvivimi1:i n:siiii s1:1is1ics
::,, x ::,, x H
1
W
OVS: . ,.o, o.,o . :. o.,, ,:.o o.oo:
OVS: . ,.oo o.8, . ,.o, o.,o ::.o o.,,
OVS, . :.8 o., . :.8 o.,8 :., o.,
OVS . :.:: o.8, . :.8 o.,8 :., o.o,:
OVS, . ,. o.,, . ,.:: o.o, 8., o.:,,
OVSo . ,.o, :.,o . :.,, o.,o ,,., o.oo:
OVS, . :.o, :.:: . :.,8 o.8, :,., o.o::
OVS8 . :.8 :.o, . ,.oo o.8, :o., o.o:o
OVS . :. o.88 . :.,o o.88 oo., o.o:
Table 8.,: Summaiy of Oveiall Satisfaction iesults, including the values of the non-paiametiic signicance
Mann-Whitney-Wilcoxon test.
OVS Overall this particular setup was suitable for solving every task presented
Let H
1
: G
e
G
b
, theie was highly signicant dieience ( = 0.002) in the scoies foi the
expeiimental ( x = 3.67, = 0.50) and baseline ( x = 2.44, = 0.73) conditions, as seen
in Table 8.,. Te iesults of this answei suppoit the hypothesis that the Oghma fiamewoik is
moie suitable to develop and evolve the type of infoimation system pioposed in this expeiiment
than a tiaditional appioach of using a geneial puipose language and a ielational database.
OVSi I found myself thinking more about the end system purely in terms of the structure of
domain objects
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.977) in the scoies foi the expeii-
mental ( x = 3.00, = 0.87) and baseline ( x = 3.67, = 0.50) conditions, as seen in Table 8.,.
u:1: ::ivsis :,
Te oiiginal hypothesis postulated that paiticipants in the expeiimental gioup would be moti-
vated to abstiact fiom implementation details and think moie in teims of domain objects. Sui-
piisingly, it was the baseline gioup that showed an highei tendency to agiee with this asseition,
although not statistically signicantly.
OVS I found myself thinking more about the end system more in terms of the structure of
the database and user interaction
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.594) in the scoies foi the ex-
peiimental ( x = 2.89, = 0.93) and baseline ( x = 2.89, = 0.78) conditions, as seen
in Table 8., (p. :). Similai to OVS:, the oiiginal hypothesis postulated that paiticipants in
the expeiimental gioup would be discouiaged fiom consideiing details such as database stiuc-
tuie and usei-inteiaction. Howevei, both gioups displayed similai answeis to this item and as
such we cannot ieject the null hypothesis.
OVS I found very dicult to directly translate specications into nal artifacts
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.072) in the scoies foi the ex-
peiimental ( x = 2.22, = 0.83) and baseline ( x = 2.89, = 0.78) conditions, as seen
in Table 8., (p. :). Despite no single paiticipant in the expeiimental gioup agieed with this as-
seition, theie isnt statistical signicance to suppoit the hypothesis of a dieience in complexity
when tianslating conceptual specications into nal aitifacts.
OVS, I was able to create the underlying object model at least as rapidly as I could normally
have created a specication
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.233) in the scoies foi the ex-
peiimental ( x = 3.44, = 0.73) and baseline ( x = 3.22, = 0.67) conditions, as seen
in Table 8., (p. :). Te iesults foi this item do not suppoit the hypothesis that cieating the
object model in the expeiimental gioup would be much quick that in the baseline gioup, when
subjectively compaiing to the eoit of cieating a specication. As such, the subjective notion
that the eoit of pioducing a specication would be as quick as declaiing the object model using
the fiamewoik is not suppoited by the iesults. Te inability to ieject the null hypothesis may be
ielated to the fact that the expeiimental gioup was having its ist contact with the fiamewoik,
and as such the timespan of the expeiiment wasnt enough to ieveal those benets.
OVSo I was able to create the user interface at least as rapidly as it could normally have been
prototyped
Let H
1
: G
e
G
b
, theie was highly signicant dieience ( = 0.001) in the scoies foi the
expeiimental ( x = 3.67, = 1.50) and baseline ( x = 1.33, = 0.50) conditions, as seen in Ta-
:o :c:uimic qU:si-ixvivimi1
ble 8., (p. :). As expected, the baseline gioup evidenced the complexity and time-consuming
activity inheient to building an maintaining a functional usei-inteiface, compaied to the genei-
ative appioach in the expeiimental tieatment.
OVS; Additional requirements represented considerable added eort
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.012) inthe scoies foi the expeiimental
( x = 1.67, = 1.12) and baseline ( x = 2.78, = 0.83) conditions, as seen in Table 8., (p. :).
Tese iesults suppoit the hypothesis that the eoit of adding new iequiiements was lowei in the
expeiimental gioup.
OVS8 Change of existing requirements represented considerable added eort
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.016) inthe scoies foi the expeiimental
( x = 1.89, = 1.05) and baseline ( x = 3.00, = 0.87) conditions, as seen in Table 8., (p. :).
Similaily to OVS,, these iesults suppoit the hypothesis that the eoit of changing and evolving
existing iequiiements is lowei in the expeiimental gioup.
OVSp I found that the resulting application could be used in production-level environments
with minimal or no change
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.029) inthe scoies foi the expeiimental
( x = 2.44, = 0.88) and baseline ( x = 1.56, = 0.88) conditions, as seen in Table 8., (p. :).
Despite no gioup had time to nish all tasks piesented, this item measuies the condence that
each gioup had to delivei the pioduct as-is, oi with minimal change. o, of the paiticipants
in the baseline gioup stiongly iejected the idea of deploying theii implementation, compaied
to :: in the expeiimental gioup. Still, even in the expeiimental gioup, no single paiticipant
agieed with this asseition, which could be explained by the expeiimental timespan available and
oveiall expeiience with the fiamewoik.
8.. Development Process
Tis gioup of questions intended to put the expeiiment in peispective with both pievious subject
expeiiences, and the main diculties they had encounteied.
DVP. I found the development style of this setup suitable for using in the context of agile
methodologies
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.022) in the scoies foi the expei-
imental ( x = 4.33, = 0.71) and baseline ( x = 3.33, = 0.87) conditions, as seen in Ta-
ble 8.o (p. :,). Tis item should be analyzed as potentially coiielated with BG:.,, wheie a sig-
u:1: ::ivsis :,
ixvivimi1:i n:siiii s1:1is1ics
::,, x ::,, x H
1
W
DVP:.: . .,, o.,: . ,.,, o.8, o,.o o.o::
DVP:.: . :.8 o.,8 . :.8 o.oo o.o :.ooo
DVP:., . :. :.o: . :. o.,, :.o o.:
DVP:. . .:: :.:, . :.,8 :., o,.o o.o::
DVP:.: . :.,, :.oo . ,.,o :., ::.o o.o,o
DVP:.: . :.oo :.:: . .:: o.o, o,.o o.oo:
DVP:., . ,.,, :.:: . :.8 o., oo.o o.:
Table 8.o: Summaiy of Development Piocess iesults, including the values of the non-paiametiic signi-
cance Mann-Whitney-Wilcoxon test.
nicant statistical deviation among the two dieient tieatments was obseived. Accoiding to the
iesults, the expeiimental gioup had a stiongei backgiound in agile methodologies than the base-
line gioup. Similaily, in this item, the expeiimental gioup also had a stiongei positive opinion
iegaiding the use of this technology in agile setups. Because of this coiielation, a conseivative
inteipietation to the hypothesis that the expeiimental tieatment is suitable foi agile enviion-
ments should be inconclusive, until fuithei studies, and a possible meta-analysis, discaid the
coiielation.
DVP.i I found the development style of this setup suitable for using in the context of classic
methodologies
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 1.000) in the scoies foi the expeii-
mental ( x = 2.89, = 0.78) and baseline ( x = 2.89, = 0.60) conditions, as seen in Table 8.o.
Since theie was also no statistical dieiences obseived in item BG:.8, one cannot ieject the null
hypothesis that the two tieatments aie indieient to the context of classic methodologies.
DVP. I found the development style of this setup suitable for using in the context of formal
methodologies
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.924) in the scoies foi the expeii-
mental ( x = 2.44, = 1.01) and baseline ( x = 2.44, = 0.53) conditions, as seen in Table 8.o.
Since theie was also no statistical dieiences obseived in item BG:., one cannot ieject the null
hypothesis that the two tieatments aie indieient to the context of foimal methodologies. Still,
when compaied to items DVP:.: and DVP:.:, the scoies aie slightly lowei, as expected.
:8 :c:uimic qU:si-ixvivimi1
DVP. I found the development style of this setup suitable for developing face to face with
the client
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.022) inthe scoies foi the expeiimental
( x = 4.11, = 1.27) and baseline ( x = 2.78, = 1.39) conditions, as seen in Table 8.o (p. :,).
Te scoie of this item suppoit the hypothesis that the expeiimental tieatment is moie suitable
foi quick piototyping and addiessing real-time iequiiements.
DVPi. Concerning this particular setup most of my diculties were dealing with the Persis-
tency Engine
Let H
1
: G
e
G
b
, theie was signicant dieience ( = 0.050) inthe scoies foi the expeiimental
( x = 2.33, = 1.66) and baseline ( x = 3.56, = 1.59) conditions, as seen in Table 8.o (p. :,).
Te scoie of this item suppoit the hypothesis that the eoit to deal with data peisistency when
iequiiements change would be signicantly lowei in the expeiimental setup.
DVPi.i Concerning this particular setup most of my diculties were building a Graphical
User Interface
Let H
1
: G
e
G
b
, theie was highly signicant dieience ( = 0.001) in the scoies foi the
expeiimental ( x = 2.00, = 1.22) and baseline ( x = 4.22, = 0.67) conditions, as seen in Ta-
ble 8.o (p. :,). Similaily to item DVP:.:, the scoie of this item suppoit the hypothesis that the
eoit to deal with the giaphical usei-inteiface when iequiiements change would be signicantly
lowei in the expeiimental setup.
DVPi. Concerning this particular setup most of my diculties were implementing the core
Business Iogic
Let H
1
: G
e
G
b
, theie was no signicant dieience ( = 0.991) in the scoies foi the ex-
peiimental ( x = 3.33, = 1.22) and baseline ( x = 1.89, = 0.93) conditions, as seen in Ta-
ble 8.o (p. :,). Contiaiy to expected, this scoies do not display a signicant statistic dieience
between the two gioups when consideiing that the expeiimental gioup should be lowei than the
baseline gioup (it shows a statistical dieience in the exact opposite diiection). Piobably this
is due to coiielation with items DVP:.: and DVP:.:, wheie paiticipants answeied piopoition-
ally to those items (i.e., because the expeiimental gioup had low diculties in the GUI and
peisistency, then, by elimination of choices, any diculties they had would fall into the Business
Logic). Hence, not only this scoie doesnt allowthe iejection of the null hypothesis, it also points
to a potential issue when designing Likeit-scale questionnaiies.
on,ic1ivi mi:sUvimi1 :
8. on)vc1:vv mvnscnvmvN1
Te expeiiment had two live video feeds being iecoided: (i) a standaid cameia pointing diiectly
to both the paiticipants and the whiteboaid, and (ii) a screencast of the computei the paiticipants
weie using. Te initial intent was to measuie time, coiiectness and complexity of the pioduced
aitifact in a non-intiusive mannei. Howevei, due to a design mistake, the paiticipants weie
not piopeily infoimed they should stiictly nalize each task independently, and as such they
paialleled the implementation. Tis pievented an objective measuiement of time expended foi
each task, since they tended to oveilap.
Neveitheless, it is still possible to measuie the nal aitifacts in teims of implemented ie-
quiiements. Each task may be paititioned into thiee majoi conceins: (i) domain stiuctuie, (ii)
peisistency, and (iii) usei-inteiface. A summaiy of the nal aitifacts is piovided in Table 8.,,
using the following giades: (A) peifect implementation, with usei-inteiface, peisistency and
iules, (B) mostly implemented, with minimal issues, (C) pooily implemented, with incomplete
usei-inteiface, peisistency and missing iules, (D) haidly implemented, with minimal oi no usei-
inteiface and peisistency, and (-) Not addiessed.
Cos1vUc1io EvoiU1io
T: T: T, T E: E: E,
Baseline Gioup I C - - - - - -
Baseline Gioup II C - - - D C D
Baseline Gioup III C C D - D C D
Expeiimental Gioup I A B B - B A B
Expeiimental Gioup II A A - - B A B
Expeiimental Gioup III B B - - - - -
Table 8.;: Implemented iequiiements.
No gioup in the baseline tieatment was able to pioduce an usable (even if minimal) usei-
inteiface, although they mostly tiied to design it using the giaphical tools piovided by Eclipse.
Te same applies foi peisistency. All gioups in both the baseline and expeiimental tieatments ig-
noied task . Most gioups weie also planning foi the whole ,h to pioduce tasks : , and thus the
development was in veiy eaily stages when the evolution tasks weie handed. Most gioups nevei
tiied to ie-addiess missing tasks once confionted with those ielated to the systems evolution.
8., vn::un1:oN 1nnvn1s
Te outcome of validation is to gathei enough scientic evidence to piovide a sound inteipieta-
tion of the scoies. Validation thieats aie issues and scenaiios that may distoit that evidence and
:,o :c:uimic qU:si-ixvivimi1
thus incoiiectly suppoit (oi discaid) expected iesults. Each validation thieat should be expected
and addiessed a priori in oidei to yield unbiased iesults:
Misunderstanding the given tasks. Because the tasks ielied on specications given in
textual foimand suppoited by Umi diagiams, it is necessaiy to ensuie that the paiticipants
coiiectly inteipiet them. Tis thieat is discaided by both the pie-test evaluation and the
iesults fiom item BG:.:o.
Unsuitable base skills to perform the tasks. Te tasks iequiied paiticipants to have the
necessaiy skills to build and evolve infoimation systems, namely knowing how to woik
with the given piogiamming language, integiated development enviionment and database
engine. Once again, this thieat is discaided by both the pie-test evaluation and the iesults
fiom items BG:.,, BG:.,, and BG:.o.
Overhead of necessary tools to perform the tasks. Because the expeiiment was timed, it
is necessaiy to ensuie that paiticipants focus on the tasks at hand. In oidei to discaid this
thieat, the necessaiy setup was conducted befoie the expeiiment by the ieseaicheis.
Prociency with the experimental treatment. Although it was iequiied that the baseline
gioup had pievious contact with the needed theoiy and tools, a conseivative appioach to
the expeiimental tieatment wheie no paiticipant had pievious contact with the fiamewoik
(as seen in item BG:.:) allows to completely discaid this thieat.
Disturbance due to observation procedures. Due to the natuie of data gatheiing devices
(i.e., video-cameias, miciophones, and scieencast sofwaie), paiticipants peifoimance
could be hindeied by the feeling of being judged and obseived. Te iesults of item EF:
allow this thieat to be discaided.
Disturbance due to social factors. Te fact that gioups weie foimed iandomly could lead
to situations weie some individuals wouldt woik well collaboiatively. Tis thieat is dis-
caided by the iesults of itemEF,, although the expeiimental gioup exhibited highei scoies.
Disturbance due to lack of motivation. Due to the length of the tasks (,h in total), and
the fact that theie was no compensation to individuals paiticipating in the expeiiment, the
lack of motivation could hindei the outcome. Tis thieat is discaided by the iesults of item
EF:, although the expeiimental gioup also exhibited highei scoies, consistent with item
EF,.
Te following thieats weie not completely discaided, and should be the focus of futuie stud-
ies:
cociUsio :,:
Dierent skills regarding agile methodologies. Te potential coiielation between items
BG:., and DVP:.:, may suggest that because the expeiimental gioup had highei skills in
agile methodologies, somehow it inuenced the expeiimental iesults. While it is haid to
see why such skills would make a signicant dieience in a setup weie the specications
weie not foimalized by the paiticipants, but given at the beginning of the expeiiment, one
could aigue that those with an agile backgiound weie skilled in the pioduction of aitifacts
moie suitable to change. Would this piemise be accepted, then a new study wheie the
tendency is changed (i.e., non-agile piactitioneis belonging to the expeiimental gioup),
would piovide moie data to coiiectly inteipiet the obseivations. Howevei, because no
paiticipant knewthat the iequiiements would be the taiget of change, one can discaid this
thieat with modeiate condence.
Biased responses in the background section due to post-test subjective perception. Te
items measuiing the backgiound expeitise weie pait of the post-test questionnaiie. Al-
though pie-test evaluation discaid this item as an expeiimental thieat, it doesnt eliminate
possible coiielations between the backgiound and othei scoies, due to a possible biased
subjective peiception gained a posteriori w.r.t. the achieved iesults. In oidei to eliminate
this thieat, a new study should move the backgiound section to a pie-test questionnaiie.
Correlation among dierent items due to no alternate choice. When paiticipants aie
faced with a set of items that may be inteipieted as a choice paitition (e.g. items DVP:.:,
DVP:.:, and DVP:.,), those items may become coiielated oi ielativized. A stiongei
issue can aiise if the items, though disjoint, aie not complete (i.e., theie could be moie
possible choices), and would foice a paiticipant to choose among one of the alteinatives.
In futuie studies, adding an extia item that would catch all othei unfoieseen choices
could diminish this potential thieat.
Te powei of this study could also be impioved by (i) incieasing the numbei of paiticipants,
and (ii) switching the paiticipant ioles, wheie all individuals in the expeiimental gioup would
be obseived undei the baseline tieatment, and vice-versa.
8.o coNc:cs:oN
Tis chaptei detailed a quasi-expeiiment conducted within a contiolled expeiimental enviion-
ment using the fiamewoik developed in pievious chapteis. One of the goals was to piovide evi-
dence in aieas that aie open to validation thieats inheient to case-studies analysis, as peifoimed
in chaptei Chaptei , (p. ::,). Te pie-test evaluation guaianteed no statistical deviation among
the two tieatments w.r.t. theii backgiound and basic skills.
Te post-test questionnaiie was used to assess the outcomes of each tieatment. Te nal
iesults suppoits the hypothesis that developing using the Oghma fiamewoik is moie ecient,
:,: :c:uimic qU:si-ixvivimi1
both in teims of pioducing a systemfiomsciatch, as well as dealing with changing iequiiements,
when compaied to a tiaditional appioach of using a geneial puipose language, and a ielational
database management system.
Some thieats to this validation weie identied and fuithei discaided by analyzing the scoies
in the post-test questionnaiie and due to the natuie of the expeiimental setup. Not all oiigi-
nal hypothesis weie suppoited, though, and some boideiline thieats which emeiged afei the
expeiiment can help to iene new studies.
Chapter p
Conclusions
p. Summary of Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
p.i Main Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,
p. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,,
p. Epilogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ,8
In this disseitation, we staited by looking at the iecuiient issues of the sofwaie engineeiing eld,
specically on two contingent factois: (i) that the eld is in crisis, in teims of the iatio between
successful and challenged/canceled piojects, and (ii) that no silver bullet has yet been found.
Behind this status quo, unieasonable expectations fiom the stakeholdeis and constant change
of the iequiiements aie to be blamed. And, as such, the mainstieam focus has mainly been on
coping with these issues thiough new sofwaie development methodologies. Yet, we decided to
tackle the pioblem fiom a dieient angle. Inspiied by the way agile methodologies looked upon
the development piocess to embrace change, we hypothesized how sofwaie specically synthe-
sizedto cope withcontinuous change wouldlook like. Andinseaichfoi this form, the aichitectuie
and design behind such systems, we have found the adaptive object-model aichitectuial pattein.
p. scmmnnv ov nvvo1nvsvs
Te authois fundamental ieseaich question was stated as:
Vhat form should this type of systems take, and which kind of tools and infrastructures should
be available to support the development of such sofware systems?
And fuithei decomposed into the following hypotheses, always in compaiison with a tiaditional
appioach of using a geneiic puipose language:
:, cociUsios
H: A:omfiamewoik would piovide a moie suitable infiastiuctuie foi developing incom-
plete by design systems.
Hi: Developeis focus would shif fiom implementation aitifacts to domain objects.
H: Tianslationof conceptual specications into nal applications would be moie stiaight-
foiwaid.
H: Te eoit of adding oi changing existing iequiiements would be lowei.
H,: Piototyped applications could be immediately, oi with little changes, used in
pioduction-level enviionments.
Ho: Te style of development would piomote agile piinciples.
H;: Te style of development would be suitable to develop face-to-face with the client.
p.i mn:N nvsc:1s
Te following items summaiize the main iesults obtained:
Contributions to the formalization of a pattern language for AOM. Seven new patteins
weie foimalized in Chaptei , (p. o:), viz. (i) Evivv1uic is : Tuic, which solves the
pioblemof nding a uniediepiesentationfoi obseiving andmanipulating data andmeta-
data, (ii) Ciosic 1ui Rooi, which addiesses the issue of having a possible unbound
numbei of (meta-)meta-models, (iii) Boo1s1v:vvic, which is used to cope with deni-
tions that depend on themselves, (iv) L:zv Sim:1ics, which is able to handle tiansiently
inconsistent/undened systemstates, (v) His1ovv oi Oviv:1ios, intended to keep tiack
of opeiations peifoimed upon objects, without knowing theii specic details, (vi) Svs1im
Mimi1o, which pieseives the notion of system-wide evolution, and allows access to any
aibitiaiy pievious state of the system, and (vii) Micv:1io, which suppoits the evolution
of a system while maintaining its integiity, thiough the composition of evolution iules.
Te specication of a reference architecture for AOM frameworks. A high-level aichi-
tectuie of a :om fiamewoik was dened, identifying the main components and theii iela-
tionships. Tiough the composition of patteins pieviously identied, it pioposes solutions
foi design conceins, namely: (i) the necessaiy abstiactions, (ii) the geneiic functionalities
it should piovide, (iii) a default, but modiable, behavioi, and (iv) the points of extension.
A reference implementation of such framework. Te implementation of an object-
oiiented fiamewoik taigeted to the development of infoimation systems whose stiuctuial
iequiiements could be best desciibed as incomplete by design, built upon the othei contii-
butions made in this disseitation.
iU1Uvi wovx :,,
Additionally, the iesults of validation pioceduies also add to the body of knowledge:
Study on the usage of AOM in industrial applications. Te fiamewoik pioposed in this
disseitation was validated using a time-seiies analysis peifoimed duiing the suic of two
case studies, viz. (i) Locvs, a medium-sized infoimation system foi aichitectuial and ai-
chaeological heiitage, and (ii) Zephyr, a small infoimation system foi document iecoids
management. Te expeiience gained in building and deploying industiial-level applica-
tions based on the :om meta-aichitectuie, as well as constiuction of a :om fiamewoik, is
documented in Chaptei , (p. ::,) and iepiesents per-se a contiibution not yet found in the
liteiatuie. Tis study piovided evidence that all the above mentioned hypotheses hold.
Study on key benets of AOMthrough (quasi-)experiments. Aquasi-expeiiment specif-
ically designed to discaid some validation thieats inheient to the use of case-studies, also
gatheis empiiical evidence of seveial claims on benets and liabilities of using :om. Tis
expeiiment piovided evidence that the hypothesis H:-H, and H, hold.
p. vc1cnv wonx
In the questionnaiie handed to the piofessionals that had contact with the fiamewoik, we asked
about what would they value as new featuies. Te summaiy of the answeis is piesented in Ta-
ble .:. At the top of the most-wanted featuies is a giaphical model editoi undeistandable since
the auto-geneiated cUi cuiiently only allows evolution to a ceitain extent, and the geneiated cUi
foi editing the model based on the meta-model is not veiy fiiendly. Te next two most-wanted
featuies is a u1mi-based inteiface, and suppoit foi woikows and business piocess modeling.
Conceining new fiamewoik featuies, I would value ::,, x
an web-poweied (HTML,) usei-inteiface . .: o.,o
woikows and business piocess management modeling . .: o.,
moie hooks . ,.,: o.,
giaphical model editoi . .,, o.,
inteiopeiability with thiid-paity model tools . ,., o.,
extensive suppoit foi model iefactoiing . .: o.o
Table p.: New featuies iesults of industiial suivey, each line iepiesenting the data of a single question,
with coiiesponding means and standaid deviation values, with n = 7.
Te following items pose fuithei ieseaich that could be puisued in line with this disseitation:
p.. Evolving Oghma
Peihaps one of the gieatest pioblems in puisuing empiiical validation on sofwaie engineei-
ing aitifacts is that they must exist. In this case, as pointed by Yodei et al. [Yodo:], no known
:,o cociUsios
fiamewoik foi building :om-based systems was published up until this point. If the oiiginal
thesis statement in this disseitation was to piove an existential, i.e., Dx@y : IsFramework(x) ^
Build(x, y) ^ IsAOM(y), then one could simply aigue about the (im)possibility of existing
such fiamewoik. But meiely pointing out to its possible existence, oi even diafing how it would
look like, wouldnt allow empiiical expeiimentation to be caiiied upon one is iequiied to
have it. As such, a consideiable amount of time and eort was dedicated to actually build such
fiamewoik, up to a point wheie it could be used in industiial-level applications'. Right now,
the fiamewoik slightly exceeds ,ok ioc, developed in a timespan of almost thiee yeais, as seen
in Figuie .:.
l
i
n
e
s
o
f
c
o
d
e
3
9
7
2
5
0
0
0
5
0
5
5
4
2008 2009 2010 072007 072010
Figure p.: Evolution of the Oghma implementation of, showing the pioject code-base between July :oo,
and July :o:o, measuied in lines of code. Te veitical lines display the cumulative size of the
dieiences pei day.
It shouldnt be suipiising that the aichitectuie and design piesented in Chaptei o (p. ,) al-
ieady points to solutions that aie not yet piesent inthe cuiient implementationof the fiamewoik,
e.g., bianching and ieconciliation of data and meta-data by the end-usei. At the time of this dis-
seitation, the latest development builds of the fiamewoik have been used as a staiting pioject foi
' yeai students to leain, exploie and develop on top of laige code bases on the couise Sofware
Development Laboratory [FCR:o].
p..i Web-based Adaptive User Interfaces
Up until now, only a small amount of woik iegaiding adaptive systems on the web can be found,
though seveial websites oei vaiying degiees of customization, such as iepositioning content on
the webpage, adding new content`, oi changing the oveiall look of the application [Goo, Pag].
' Which poses anothei pioblem per-se, since theie is a plethoia of conceins that must be addiessed and imple-
mented, and which does not contiibute to the state-of-the-ait.
Mastei in Infoimatics and Computing Engineeiing, fiom the Univeisity of Poito, Faculty of Engineeiing.
` Usually small applications known as widgets.
Commonly known as skinning oi theming.
iU1Uvi wovx :,,
Teie aie also some examples of adaptability to each individual usei. Tis is accomplished by
mining infoimation ielative to wheie the usei comes fiom and its past actions in oidei to catei
to the peiceived iesults the usei expected [GGGRo]. As alieady mentioned in this disseitation,
the fundamental piopeity of adaptive sofwaie is to allow end-useis to intioduce changes in
its undeilying stiuctuie and behavioi. Howevei, these websites do not allow theii end-useis to
modify the undeilying model of the system; only the oveiall look&feel and, to some extent, what
infoimation is displayed on the page thus still ielying on developeis to deal with stiuctuial
and behavioial iules. As such, these systems aie veiy dieient fiomthose discussed in this woik.
Neveitheless, such websites possess valuable infoimation iegaiding the most common usei-
inteiface mechanisms. Diag-and-diop is used extensively to ieoiganize infoimation and pei-
foim basic tasks such as adding and iemoving basic containei blocks. Tese mechanisms and
inteiaction paiadigms can be used to modify any kind of system fiom an end-usei peispective,
be it a :om system oi not. Tis study is cuiiently being puisued by Joao Giadim as his masteis
thesis [Gia:o].
p.. Improving Usability of Automatically Generated GUI
While automatic iun-time geneiated usei-inteifaces may not be on paii with custom-made ones
iegaiding usability, they seemto be consistent andbasedona stiict set of metaphois, suppoiting a
quick leaining piocess by useis. Nonetheless, which mechanisms should the fiamewoik piovide
to impiove usability and customization of cUi, while ietaining the capability of automatically
geneiating them: Tis study is cuiiently being puisued by Andi Caimo as his masteis thesis.
p.. Continuing the Pattern Ianguage
Te study on automatically geneiating cUi, and allowing non-piogiammei end-useis to e-
ciently cope with domain changes may piovide new patteins to add to the pattein language.
And despite the seven patteins heie piesented, the pattein language as a whole is not yet nished,
piobably iequiiing a multi-yeai, multi-peison eoit, with constant feedback fiom the patteins
community.
p.., Self-Hosting
Self-hosting is the capability of a piogiamming language to be built on top of itself. Few pio-
giamming languages actually exploit this chaiacteiistic, with iisv piobably being the most well
known [HL,]. In object-oiiented piogiamming, since the cieation of Smalltalk [Kay,], most
modein languages aie not designed with self-hosting in mind; instead, this featuie is delegated
to non-mainstieam piojects, such as PyPy [Pyp] foi Python and Rubinius [Rub] foi Ruby.
:,8 cociUsios
Likewise, Oghma is cuiiently not self-hosted (though it is self-compliant). It would be intei-
esting to see the advantages and disadvantages of attaining such goal.
p. vv::oocv
At the end of a peiiod of thiee yeais, it is inevitable to take a look back and pondei. When we stait
a Ph.D., we aie told that we must have novel ideas, that we must publish good iesults, and that
we must conduct science. Peihaps the biggest misundeistanding comes fiom what it is actually
meant foi novel, results and science.
At the beginning, it is usual to tiy to imagine something that no-one has evei done befoie.
Something we believe could solve most of the pioblems in oui aiea. Ten iealize that most ideas
we have had alieady been thought ofpiobably yeais ago. Tis is why one is iequiied to do an
extensive ieview of the liteiatuie: to leain about all those pievious ideas and tiy focus on the
specic pioblems yet to be solved. But how exactly aie we supposed to build on top of those
ideas: Peihaps in a bianch such as mathematics, one could point to otheis pioofs and theoiies
and then move to oui own. But in engineeiing, as the bianch of science conceined with the
design, building, and usage of stiuctuies, one must have those pievious stiuctuies. And when
they aient ieadily available, we aie faced with a dilemma: eithei we iestiict to build piototypes
pioof of concepts and leave the buiden of integiation foi someone else, oi we must get oui
hands diity and stait fiom sciatch. Looking back, I cannot be absolutely suie if the foimei
was the iight choice, given the available timespan, but it suiely was the best way to make this
woik usable in settings beyond the academy. ^ovel should thus be iegaided as advancing the
state-of-the-ait, taking caie to stand on the shoulders of giants.
Ten comes the pioblem of publishing iesults. Much has been said about the ieason and
impoitance of publishing, and fiom which I iefiain to make comments (consideiing my shoit
expeiience as a ieseaichei). But peihaps the intended message may be found by obseiving the
innovative ievision piocess of the confeiences on v:11iv i:cU:cis oi vvocv:ms (viov):
each papei has a shepheid a non-anonymous ieviewei that leads the authoi in a seiies of
iteiations to impiove the papeis content, befoie being accepted oi iejected. Even if accepted,
the content is fuithei discussed duiing the confeience by a gioup of peeis in a wiiteis woik-
shop. Only afei that unusually long cycle of ievisions is the papei consideied ieady foi digital
publication. Iterative and constant feedback aie impoitant keywoids heie, not suipiisingly mim-
icking (oi being mimicked by) the agile piinciples. Piesenting iesults becomes the pioduct of
an inciemental piocess of ieseaich; snapshots in time. Te same can be said about the aitifacts
Te tuiing taipit [Pei8:] being the most likely one.
Ideally, both good and bad ideas, though ieseaicheis aie piessed to only publish the good ones, and thus making
eveiyone else iecuiiently fall into the bad ones.
Not to disiegaid mathematicians, to which I have the utmost iespect.
iviiocUi :,
heie desciibed; foi a disseitation inspiied on the idea of incompleteness, it is, by itself, a meie
photography of an evei-evolving stiuctuie.
And nally, theie is science. It took me a shoit amount of time to iealize that woiks ielying
on mathematics weie moie inclined to be coined as scientic, but a long time to undeistand that
it is neithei about the numbeis noi the foimulas. Te key to make science is to undeistand what
epistemology is, and to make the same questions that epistemology does: what is knowledge:
howis knowledge acquiied: howdowe knowwhat we know: Once we undeistandthat by science
we mean the piocess of acquiiing and testing new knowledge, then, in the woids of Richaid
Feynman, the rst principle is that you must not fool yourself, and you are the easiest person to
fool.
:oo cociUsios
Appendices
Appendix A
Pre-Experiment Data
I II III IV V VI VII x
SUn,ic1 A :o :: :: :, :, :o :, :,., :.
SUn,ic1 B :, :o :: :: :: :8 : :., ,.:
SUn,ic1 C : :: :, :: :: :o - :,.o :.8
SUn,ic1 D :, :o :o :o :o :, :8 :o., :.o
SUn,ic1 E :, :, :o :8 :, :o :, :,., :.o
SUn,ic1 F :o :, :, :o :, :, :8 :,.: :.8
SUn,ic1 G :, :: :: :: :o :o :o :,.: :.,
SUn,ic1 H :: :, :: :, :: : :o :,.o :.o
SUn,ic1 I :: :, :o :o :o :8 :o ::.o ,.,
Table A.: Student giades foi the Expeiimental gioup. Each column iepiesents the following couises: (I)
Piogiamming Fundamentals, (II) Piogiamming, (III) Algoiithms and Data Stiuctuies, (IV)
Algoiithm Design and Analysis, (V) Sofwaie Engineeiing, (VI) Sofwaie Development Labo-
iatoiy, and (VII) Infoimation Systems.
I II III IV V VI VII x
SUn,ic1 J : :o : :, :o :, :, :. :.:
SUn,ic1 K :o :: :: :o :: :o :, :,., :.
SUn,ic1 L :, :o :, :: :: :o :, :,., :.
SUn,ic1 M :o :o :, :: :: :, :8 :. :.,
SUn,ic1 N :o :o :, : :: :, :, :,.o :.o
SUn,ic1 O :: :: :, :, :, :o :8 :., :.
SUn,ic1 P - - - - - - - - -
SUn,ic1 Q - - - - - - - - -
SUn,ic1 R - - - - - - - - -
Table A.i: Student giades foi the Baseline gioup. Each column iepiesents the same couises in Table A.:.
Te last thiee subjects did not had this infoimation publicly available at the time of the expeii-
ment.
:o vvi-ixvivimi1 u:1:
Appendix B
Post-Experiment Questionnaire
Te following is a copy of the anonymous questionnaiie handed to the subjects afei the end of
the expeiiment.
:oo vos1-ixvivimi1 qUis1io:ivi
Empirical Studies in Software Engineering
TENFOGS01
May - June 2010
Post-test Questionnaire
Thank you for participating in this experiment. We now ask you to take a deep breath, have a coke, and try
to answer this brief questionary that wont take you more than 5 minutes.
Each question relates to issues regarding your prole as a developer and your perception about the ex-
periment. The questionary is divided into sections with questions. Each question has an identier (for easy
processing later on) and may have either a single answer, or a list of possible answers. Each answer should
be rated as follows: 1 (Strongly Disagree), 2 (Somewhat Disagree), 3 (Neither Agree nor
Disagree), 4 (Somewhat Agree), 5 (Strongly Agree). Your should rate with an X every answer
as best it resembles your opinion as possible.
Questionnaire
Background
BG1. I have considerable experience...
1 2 3 4 5
...using frameworks.
...with this particular framework.
...with this particular programming language.
...developing industrial-level applications.
...analyzing and specifying information systems.
...with object-oriented architecture, design and implementation.
...with agile development methodologies.
...with classical development methodologies.
...with formal development methodologies.
...with UML class diagrams.
External Factors
1 2 3 4 5
EF1. I felt disturbed and observed by the cameras.
EF2. I enjoyed programming in the experiment.
EF3. I would work with my partners again.
1
:o,
Overall Satisfaction
1 2 3 4 5
OVS1. Overall, this particular setup was suitable for solving every task pre-
sented.
OVS2. I found myself thinking more about the end system purely in terms
of the structure of domain objects.
OVS3. I found myself thinking more about the end system more in terms
of the structure of the database and user interaction.
OVS4. I found very difcult to directly translate specications into nal
artifacts.
OVS5. I was able to create the underlying object model at least as rapidly
as we could normally have created a specication.
OVS6. I was able to create the user interface at least as rapidly as it could
normally have been prototyped.
OVS7. Additional requirements represented considerable added effort.
OVS8. Change of existing requirements represented considerable added
effort.
OVS9. I found that the resulting application could be used in production-
level environments with minimal or no change.!
Development Process
DVP1. I found the development style of this setup suitable for...
1 2 3 4 5
... using in the context of agile methodologies.
... using in the context of classic methodologies.
... using in the context of formal methodologies.
... developing face to face with the client.
DVP2. Concerning this particular setup, most of your difculties where...
1 2 3 4 5
... dealing with the Persistency Engine.
... building a Graphical User Interface.
... implementing the core Business Logic.
2
:o8 vos1-ixvivimi1 qUis1io:ivi
The Future
FT1. Given that the basic infrastructure now exists, and with suitable modications to the development
process, my expectations are that subsequent systems developed with it would be...
1 2 3 4 5
Developed faster when compared to a conventional approach.
Less expensive than using a more conventional approach.
More comprehensively tested than would using a more conventional ap-
proach.
More easy to maintain overall consistency.
Learning Support
LS1. Consider all the steps you took to solve a particular task. You have a couple of minutes to quickly
share your knowledge of how to solve that problem to other developers, or even to yourself if, later, you
need to come back to it. You would...
1 2 3 4 5
Point out the correct sequence of steps that lead to the solution.
Point out the superuous and "dead-end" paths to warn of the hazard.
Tell them what you thought the solution could be.
Tell them only the classes they need to look at. The rest is up to them.
The starting point you took. They eventually will dig out the rest.
LS2. If you were asking for help on how to reach a solution to a particular problem, and the developer as-
sisting you only had 30 seconds to answer (very busy person), what would you like to hear from him/her...
1 2 3 4 5
The minimal steps he/she took to reach the solution.
All the steps (including the "dead-ends") he/she took to reach the solution.
The starting-point and a direction would be sufcient.
The fundamental step that makes you "click" (Ah!! Got it!!).
What the previous developer thought of when trying to solve the problem.
The nal class diagram.
3
:o
LS3. During the process of solving the tasks, when do you think an expert's hint would benet you the
most (imagine you only have one shot at the expert)?
1 2 3 4 5
Right at the start.
Figuring out how concepts (classes) relate.
When writing code.
Testing.
1 2 3 4 5
LS4. I would be more condent using solving tips coming from other de-
velopers than from the inline help system.
LS5. I would be more productive if the system pointed to potential errors
instead of having to rely on the documentation.
LS6. If you had to continue developing with this setup, you would value...
1 2 3 4 5
... having extensive reference documentation.
... having written walk-throughs and tutorials.
... having screencasts/videos.
... having more example implementations.
If you wish to leave any further comments, please use the following space:
Thank you for your time.
4
:,o vos1-ixvivimi1 qUis1io:ivi
Appendix C
Post-Experiment Questionnaire Results
Exvivimi1:i x B:siiii x H
1
1-1is1 W
BG:.: , , , , , ,. o.,, , , , : , , ,. o.88 o.,oo :.o :.ooo o.,, o.,oo
BG:.: : : : : : : : : : :.:: o.,, : : : , , , ,.:: :.:, o.ooo oo.o o.oo: o.oo: :.ooo
BG:., , , : : : ,.,, :.:: , , , .,, o.,o o.o:, :., o.o, o.o:: o.8:
BG:. , , : , : : : : :.,o o.,, : : , : : : :.,8 o., o.:, ,o., o.,,: o.,oo o.o,:
BG:., : , : , , , , , ,.:: o., , , , : , : ,.oo :.oo o.o, ,., o.o: o.8: o.,,,
BG:.o , , , , , .,, o.,: : : , ,. o.88 o.o:o o:., o.o,o o.8o o.o:8
BG:., : , ,.o, o.,: , , , : , , : :.8 o., o.o,: o:.o o.o, o.8, o.o::
BG:.8 , , , ,.8 o.oo , , , , , ,.o, o.,: o.:: 8., o.,, o.8oo o.::
BG:. , , : , : : : :.,8 o.8, : , : , : : , , :.o, o.,: o.,8: ,.o o.88 o.o:, o.:
BG:.:o : , , , , , .:: :.o, , , , : ,. o.,, o.oo ,8., o.:o: o.,8 o.o,:
EF: : : : : : : , , : :.8 o.,8 : : : : : : , : , :.,8 :., o.: ,o.o o.,8 o.8,: o.:,
EF: , , , , , , . o.,, , : , , , : , , ,.,, :.:: o.o:: o,., o.o,, o.8, o.o:
EF, , , , , , , .o, o.,o , , , , , ,.8 o.,8 o.o:: o,.o o.o,, o.8o o.o:8
OVS: , , , ,.o, o.,o : : , : , : : : :. o.,, o.ooo ,:.o o.oo o. o.oo:
OVS: : , , , , , , ,.oo o.8, , , , ,.o, o.,o o.o,: ::.o o.o, o.o,o o.,,
OVS, : : , , , , , :.8 o., , , , , : : : :.8 o.,8 o.,oo :., o.88o o., o.,
OVS , : , , , : : : : :.:: o.8, , , : , : , : :.8 o.,8 o.o,o :., o.:, o.o,: o.o
OVS, , : , , ,. o.,, : , , , , , ,.:: o.o, o.:, 8., o.oo o.,o o.:,,
OVSo : , , : , , , , ,.o, :.,o : : : : : : : : : :.,, o.,o o.ooo ,,., o.oo, o. o.oo:
OVS, : : : , : : : : :.o, :.:: : : : , : , , :.,8 o.8, o.o:, :,., o.o:, o.o:: o.o
OVS8 : : : , : : : : :.8 :.o, : , : : , , ,.oo o.8, o.o:, :o., o.o,: o.o:o o.8,
OVS , , , : : : , , , :. o.88 : : : : : , : , : :.,o o.88 o.o: oo., o.o,8 o.,, o.o:
DVP:.: , , , , , .,, o.,: , , : : ,.,, o.8, o.oo8 o,.o o.o:: o.: o.o::
DVP:.: , , : , : , : :.8 o.,8 , , , , : , : , :.8 o.oo o.,oo o.o :.ooo o.,oo o.,,
DVP:., : , , , , : : : :. :.o: , , , : : : , : : :. o.,, o.,oo :.o o.: o.,,o o.o:
DVP:. : , , , , .:: :.:, , , , : : : : :.,8 :., o.o:, o,.o o.o, o.8: o.o::
DVP:.: : , : , : : : :.,, :.oo , , , : : : , , ,.,o :., o.oo, ::.o o.:o: o.o,o o.,
DVP:.: , , : : , : : : :.oo :.:: , , , , .:: o.o, o.ooo o,.o o.oo: o.oo: :.ooo
DVP:., : : , , , , : ,.,, :.:: , : : : , : : : , :.8 o., o.ooo oo.o o.o:, o.: o.o::
FT:.: , , , , , .,o o.,, , , , , , : ,.,8 :.,o o.o,8 ,,., o.:oo o.,: o.o8,
FT:.: , , , .:: o.oo , , , , , : ,.,, :.:: o.o: ,.o o.o8, o.oo o.o:
FT:., , , , : , : : :.,8 o., , , , , , : ,.,, :.:: o.:, :,., o.:: o.::: o.8,
FT:. , , , , , , , , ,.,, o.,: , : : , : ,.:: :.,o o.:: ,.o o.:o o.o, o.,,
LS:.: , , , : , , ,.,, :.:: , , : : , , ,.:: o.,8 o.,:o ,., o.,o o.,oo o.:,o
LS:.: , , , , .oo o.,: , , , , , , ,.,o o.,, o.:o, ,., o.:o o.:, o.o8
LS:., , , , , , ,. o.,, , , : , , , ,. o.88 o.,oo :.o :.ooo o.,, o.,oo
LS:. : : : : , : :.o, :.:: , : , : : : : : , :.:: o.o, o.:oo .o o.o o.8o o.::,
LS:., , , , : , , , ,.,o :.o: : , , , , : ,.:: o.,8 o.:,, ,o.o o., o.8:o o.:oo
LS:.: , , : , ,.8 o., , , : , : , ,.,o :.:, o.:,: ,., o., o.,,8 o.:,:
LS:.: : : , : : : : , :.:: :.o, , , , : : , ,.oo :.oo o.o, ::., o.o: o.o, o.o,
LS:., : , : , , , ,.,o :.:, , , , , , , ,.,o o.,, o.,oo :., o.o, o.,,o o.8:
LS:. , , , , : .:: :.:, , , : , .:: o., o.,oo .o o.,,o o.o,: o.,8,
LS:., : : , , : : , : :.,, :.oo : , : : , : : : :.,, :.: o.,oo ,., o.8: o.o:o o.:o
LS:.o , , : , , : : ,.:: :.o, : , , , , ,.:: o., o.:o ,,.o o.o: o.,:: o.,::
LS,.: , , , : , , , .oo :.:: : , : , ,.,o :.o: o.:, ,:.o o.,,o o.8, o.:,8
LS,.: , , : , , , ,.o, :.oo , , : , : , , ,. :.:, o.,,: ,., o.o8o o.o, o.,o
LS,., , : , : , , , : :.8 :.:, : : , , : : :.,8 :.o o.: :.o o.:, o.,,, o.o
LS,. : : , : : , : :.,, :.:: , : : , , : ,.:: :.:, o.:o: :o., o.::: o.::: o.oo
LS , , , , .:: o.o, , , , , , , ,.,, o.,o o.oo, o,., o.o:: o.o o.ooo
LS, , , , , , .:: o.,8 , : , , , , , ,.,, o.8, o.o,: oo., o.oo o.,: o.o,
LSo.: : , , .oo o.8, : , : : : , :.8 o., o.oo o,.o o.o:: o.: o.o::
LSo.: : , , , ,.o, o.8, : , : , : : , ,.:: :.,o o.:o, .o o.oo o.,, o.:,o
LSo., , , , , : , : ,.:: :.:, : : , : : , ,.oo :.,: o.:o :., o.8: o.,o o.o
LSo. , , , .,, o.,o , , , , , .:: o.,8 o.:: o., o.,8, o.,o o.:,
Table C.: Post-expeiiment questionnaiie iesults with coiiesponding means, standaid deviation, t-test
piobability values and the non-paiametiic signicance Mann-Whitney-Wilcoxon test; see
8., (p. :,).
:,: vos1-ixvivimi1 qUis1io:ivi visUi1s
Appendix D
Experimental Group Documentation
Te following is a copy of the available documentation handled to the expeiimental gioup dui-
ing the couise of the expeiiment. It should not be iegaided as the complete documentation of
the fiamewoik, since it contains delibeiate omissions and inconsistencies foi the puipose of the
expeiiment. Foi a compiehensive desciiption see Chaptei o (p. ,).
:, ixvivimi1:i cvoUv uocUmi1:1io
!"#$%&'()*$+,-%.(,
!"#$%&'()&
/,-0(1*).(,
This document provides the basic documentation for the Oghma framework.
2+3,"&-#+&40(5+)-&-(&)($467+
The following steps should get an empty Oghma project to compile with Visual Studio 2008:
- Download and unpack the source code;
- Open the main solution by double-clicking on oghma.sln inside your uncompressed folder;
- In the Solution Explorer, right-click on the project Template and set as the StartUp Project;
- In the Build menu, select Rebuild Solution. Use F5 to run (with the debugger attached);
- You should now be able to see the application running, with a single package (Main) and an
Empty Class.
8947(06,"&-#+&:(1+7&(;&%&<*,,6,"&89%$47+
Inside the main solution, youll nd MedSystem, a real-world use-case of Oghma. This project uses
the lename medsystem.xml for its initial system denition. These congurations can be found in
program.cs. Due to a bug in Visual Studio, youve to right-click in program.cs and choose View
Code
1
:,,
=#+&>,%-($?&(;&!"#$%:@
OghmaML is a XML vocabulary to dene the initial system. Its concepts are close to those of a class
diagram. The basic structure of an OghmaML le is:
<?xml version="1.0" encoding="UTF-8"?>
<model>
<data>
<!-- Packages -->
<!-- Enums -->
<!-- Entities -->
<!-- Relationships -->
</data>
<views>
<!-- Views -->
</views>
</model>
A%)B%"+C
A package represents an aggregation of concepts (namely, entities), and is also used to dene
which entities are considered entry points. Example:
<package id="main" name="Clinic">
<entity id="patient" entrypoint="true" />
<entity id="appointment" entrypoint="true" />
</package>
Packages and entry points are shown on the left menu bar of the application:
8,..+C
An entity is one of the main objects in the system. Its denition is close to that of a Class. It has
properties attributes and relationships. The following example shows the skeleton of an entity:
<entity id="" name="" inherits="" abstract="" tostring="">
<list columns="" />
<attr />
...
</entity>
2
:,o ixvivimi1:i cvoUv uocUmi1:1io
The Entity tag has several attributes:
- id: Unique identier for the entity. Mandatory, and should not contain numerals.
- name: String dening the label text (e.g. display name) for this object.
- inherits: indicates the ID of a class from which this class is derived.
- abstract: Flagged with true or false, it indicates if this entity is abstract (and hence not
able to be instantiated). Optional eld, false by default.
- tostring: Expression that determines how this entity is shown textually. The attributes of
the entity and their ancestors can be part of the expression, and are identied by their id and
the use of brackets (e.g. My name is {name} and Im {age} yrs old)
The contents of an Entity tag can only have one List declaration and may enclose several Attribute
tags (see Attributes).
Examples:
<entity id="car" name="Car" inherits="vehicle" tostring="{brand}">
<list columns="{brand}|{name}" />
<attr id="carbrand" name="Brand" domain="string" />
<attr id="carmodel" name="Model" domain="string" cardinality="1"/>
</entity>
D%C+&'($%6,C
The following domains can be used in attributes:
- string: is a sequence of characters and is drawn as a text-eld.
- text: is a (big) sequence of characters and is drawn as a text-area.
- oat: is a numeral that accepts decimals and is drawn as a text-eld.
- integer: is a natural number and is drawn as a text-eld.
- boolean: is a boolean (true/false) and is drawn as a checkbox.
>E06F*-+C
An entity is typically composed by several attributes:
<attr id="" name="" domain="" cardinality="" role="" tostring="" isreadonly="" />
- id: Unique identier for the attribute. Mandatory, and should not contain numerals.
- name: String dening the label text (e.g. display name) for this object.
- domain: Field dening a data type associated with this eld. Different data types have differ-
ent visual representations in Oghma (see Data Types).
Vehicle
Brand: string
Model: string [1]
entrypoint
Car
3
:,,
- cardinality: Denes the cardinality of this side of the relation. Cardinality is indicated by a
lower and upper bound (lower..upper). Examples: 0..*,1..*, 1 or 0..2.
- role: Optional eld specifying if this attribute is either a composer or an agreggator.
- tostring: Expression that determines how this attribute is shown textually. The attribute
itself can be part of the expression, identied by its id and the use of brackets.
- isReadOnly: Optional eld that species if this attribute should be read-only. Accepts true
or false. If an attribute is read-only, that means this attribute can only be one instance that
has already been created.
See Entity for examples.
NOTE: When the domain of an attribute is another entity (instead of a base-type), oghma auto-
matically transforms the attribute into a relationship. Example:
Wheels: wheel [0..*]
Car
Wheel
0..*
wheels
Car
@6C.,"
Listing refers to how several instances of an entity are presented on a table or list. It is an optional
element within the entity element:
<list columns="" />
- columns: Denes which columns should appear when representing an entity in a list or table.
The attributes to show can be identied by its unique id between brackets (e.g. {name}).
Columns should be separated by using a pipe character (e.g. {name}|{age}).
See Entity for examples.
<+7%.(,C#64C
Denes a relation between two entities. A relation contains two node elements (one for each end of
the relation) that aim to dene its scope.
<relationship id="" entity="" >
<node entity="" id="" name="" cardinality="" navigable="" role="" />
<node entity="" id="" name="" cardinality="" navigable="" role="" />
</relationship>
4
:,8 ixvivimi1:i cvoUv uocUmi1:1io
- id: Unique identier for the node. Mandatory, and should not contain numerals.
- entity: Optional eld with the ID of the associative entity for this relationship.
- name: String dening the label text for this object.
- cardinality: Denes the cardinality of this side of the relation. Cardinality is indicated by a
lower and upper bound (lower..upper). Examples: 0..*,1..*, 1 or 0..2.
- navigable: Indicates navigability to this side of the relation. Accepted values are true,
false and unspecified. true means that the node can be navigated to; false means the
relation cannot be accessed thru this node. unspecified does not imply any type of restric-
tions to navigability and assumes the default value.
Examples:
<relationship id="car_wheel">
<node entity="car" id="wheel" name="Wheels" cardinality="1" />
<node entity="wheel" id="car" name="Car" cardinality="0..*" />
</relationship>
NOTE: Cardinality should be expressed in reverse!!! This is a known issue.
For associative entities, use the entity attribute in relationship:
<entity id="role_id" name="Role" ...>
...
</entity>
<relationship id="person_company" entity=role_id>
<node entity="person" ... />
<node entity="company" ... />
</relationship>
Wheel
0..*
wheels car
1
Car
Person Company
Role
5
:,
8,*$+0%.(,C
An enumeration is simply an entity that inherits from enum. Dening the initial values of that
enumeration is currently not supported, though they can be edited in runtime.
<entity id="sex" name="Sex" inherits="enum" />
An enumeration is displayed as a combo-box when the upper-bound of the attribute 1, and as a
check-list if the upper-bound greater than 1 (e.g. 0..*)
G6+HC
If an entity doesnt have a view specied in the XML le, the system will automatically generate a
default one. For examples on usage of custom views, see medsystem.xml.
I#+,&+J+0?-#6,"&"(+C&H0(,"
Dont panic... This is an alpha version, and as such it has some bugs. Probably, the most problem-
atic issue is that if the XML le is ill-dened, the debugger will stop in the thrown exception in-
stead of showing an error message. When this happens, double-check your initial model denition
for errors, like mismatching identiers, redundant XML tags, etc.
If data becomes inconsistent, you can always delete both the database and the full-text search les.
These are normally stored as database.db and fts.db when using the SQLiteDataSource provider.
When running from Visual Studio, these are present in the debug folders /bin/debug or /x86/
bin/debug of the running project (e.g. /examples/medsystem/medsystem).
Male
Female
enum
Sex
6
:8o ixvivimi1:i cvoUv uocUmi1:1io
Appendix E
Industrial Survey
:8: iuUs1vi:i sUvviv
:swivs ::,, x
BG: , , : . ,.,, :.:,
BG: , , , : . ,., :.:,
BG, , , : . .oo :.oo
BG , , : , . ,.,, o.8
BG, , , , , : , . .oo :.,,
BGo , , : , . ,.8o :.o,
BG, : , : , . ,., :.:,
BG8 , , . .oo o.,8
BG : , , : . ,.: o.o
BG:o , , , : . ,.: o.,o
BG:: : : : : : : . :.8o :.o,
BG:: : , : . ,.: :.::
OVS: , . ,.8o o.,8
OVS: , , , , . .oo o.8:
OVS, , , : : : : : . :.: o.o
OVS , , , , . .oo o.8:
OVS, , , , , , . .: o.o
OVSo , : , : : : : . :.8o o.o
OVS, , : , : : : : . :.8o o.o
OVS8 , , , , . .: o.,o
DVP:.: , , , , , , , . ., o.8
DVP:.: , , , , . ,.,: o.,o
DVP:., , , , , , , , . ,.: o.,o
DVP:. , , , , , . ,.8o o.o
DVP:.: , : : : : : , . :.: o.o
DVP:.: , : : : : , . :., o.8
DVP:., , , , : , . ,., o.8
DVP:. , : , : : , . :.,: o.,o
DVP:., , : , , . ,.: o.,o
DVP:.o , , : , . ,.,, o.8
FT: , , , , , , . .,, o.,
FT: , , , , . .: o.,o
FT, , , . ,.,: o.
FT , , , , . .: o.,o
LS: , , , , , . .: o.o
LS: , , , , , , , . .: :.o,
LS, , , , , , , . .: o.,
LS , , , , . ,., o.,,
LS, , , , , , . ,.8o o.o
W: , , , , . .: o.,o
W: , , , , , , . .: o.,
W, , , : . ,.,: o.,
W , , , , , , . .,, o.,
W, , , , , , , . ,., o.,
Wo , , , , , . .: o.o
Table E.: Industiial suivey iesults, each line iepiesenting the data of a single question, with coiiesponding
means and standaid deviation values.
Nomenclature
Abstraction Te piocess oi iesult of geneialization by ieducing the infoimation content of a
concept oi an obseivable phenomenon, typically to ietain only infoimation which
is ielevant foi a paiticulai puipose [Wik:oa].
Accidental Complexity Complexity that aiises in computei aitifacts, oi theii development piocess, which
is non-essential to the pioblem to be solved.
Actor In UML, it species a iole played by a usei oi any othei system that inteiacts with
the subject [OMG:od].
Adaptability Chaiacteiistic of a system that empoweis end-useis without oi with limited
piogiamming skills to customize oi tailoi it accoiding to theii individual oi
enviionment-specic iequiiements.
Agile Agile sofwaie development iefeis to a collection of development methodologies
based on iteiative development, wheie iequiiements and solutions evolve thiough
collaboiation between self-oiganizing cioss-functional teams.
AOM Acionym foi Adaptive Object-Model [YBJo:b].
API Acionym foi Application Piogiamming Inteiface.
BNF Acionym foi Backus-Naui Foim. A meta-syntax foi context-fiee giammais such
as those dening piogiamming languages.
Case Study Reseaich methodology based on an in-depth investigation of a single individual,
gioup, oi event to exploie causation in oidei to nd undeilying piinciples.
Concurrency A piopeity of systems in which seveial computations aie executing simultane-
ously, and potentially inteiacting with each othei.
CRUD Acionym foi Cieate, Read, Update, and Delete.
DBMS Acionym foi Database Management System.
DDD Acionym foi Domain-Diiven Design [Evao,].
DDI Acionym foi Data Denition Ianguage.
DMI Acionym foi Data Manipulation Ianguage.
DSI Acionym foi Domain Specic Ianguage.
DSMI Acionym foi Domain Specic Modeling Ianguage.
EMF Acionym foi Eclipse Modeling Fiamewoik.
Encapsulation Te piocess of compaitmentalizing the elements of an abstiaction that constitute
its stiuctuie and behavioi; encapsulation seives to sepaiate the contiactual intei-
face of an abstiaction and its implementation [BME
+
o,].
End-user In sofwaie engineeiing, it iefeis to an abstiaction of the gioup of peisons who
will ultimately opeiate a piece of sofwaie, i.e., the expected usei oi taiget-usei.
:8 omici:1Uvi
Epistemology Te bianch of philosophy conceined with the natuie and scope (limitations) of
knowledge.
Essential Complexity In contiast to Accidental Complexity, it is that consideied inheient and unavoid-
able to peifoim a desiied computation oi expiess a sofwaie aitifact.
Extensibility It is a systemic measuie of the ability to extend a system and the level of eoit
iequiied to implement the extension.
FR Acionymfoi Functional Requiiement. Afunctionof a sofwaie systemoi its com-
ponent, desciibed as a set of inputs, expected behavioi, and consequent outputs.
Framework In Object-Oiiented Piogiamming, fiamewoiks aie ieusable designs of all oi pait
of a sofwaie system desciibed by a set of abstiact aitifacts and the way they col-
laboiate [RJo].
Generative Programming Systematic tiansfoimation of an (high) level desciiption of a system (model) into
executable code oi code skeleton [RKS8].
Granularity In the context of ieective systems, iepiesents the smallest aspect of the base-
entities of a computation system that aie iepiesented by dieient meta-entities.
GUI Acionym foi Giaphical Usei Inteiface.
Hollywood Principle A fiamewoik design piinciple based on the clich iesponse given to amateuis au-
ditioning in Hollywood, Dont call us, well call you.
IDE Acionym foi Integiated Development Enviionment.
Information Flux Measuies the amount of infoimation that is exchanged between elements of a sys-
tem to peifoim a desiied computation.
kIOC Acionym foi kilo Iines Of Code eectively thousands of LOC.
Iifecycle In the context of ieective systems, it is the peiiod of the system execution in
which a specic meta-entity has to exist.
IOC Acionym foi Iines Of Code.
MDA Acionym foi Model-Diiven Aichitectuie [OMG:ob].
MDE Acionym foi Model-Diiven Engineeiing [Schoo].
Meta-Architecture Aichitectuies that can dynamically adapt at iuntime to new usei iequiiements.
Metamodelling In sofwaie engineeiing, it is the analysis, constiuction and development of the
fiames, iules, constiaints, models and theoiies applicable and useful foi modeling
a piedened class of pioblems.
Metaprogramming Te piocess of wiiting piogiams that geneiate oi manipulate eithei othei pio-
giams, oi themselves, by tieating code as data [CI8].
MOF Acionym foi Meta-Object Facility [OMG:oa].
MVC Acionym foi Model-View-Contiollei [BMR
+
o].
Naked Objects A sofwaie aichitectuial pattein that heavily emphasizes the automatic geneia-
tion of giaphical usei inteifaces fiom a veiy stiaightfoiwaid inteipietation of the
domain models [Pawo].
NFR Acionym foi Non-Functional Requiiement. Species ciiteiia that can be used
to judge the opeiation of a system, iathei than specic behaviois, i.e., while FRs
dene what a system is supposed to do (function), NFRs dene how a system is
supposed to be (foim).
omici:1Uvi :8,
OO Acionym foi Object-Oiiented.
OOP Acionym foi Object-Oiiented Piogiamming.
OOUI Acionym foi Object-Oiiented Usei Inteiface.
ORM Acionym foi Object-Relational Mapping.
Pattern In sofwaie, it is a iecuiient, iecognized good solution foi a iecuiient aichitec-
tuial, design oi implementation pioblem [AIS,,, GHJV].
Performance Geneial measuie that may mean shoit iesponse time, high thioughput, low uti-
lization of computing iesouices, etc.
PIM Acionym foi Platfoim-Independent Model.
Proliferation In the context of ieective systems, it is a measuie of the quantity of objects nec-
essaiy to peifoim, oi iepiesent, a given meta-computation.
PSM Acionym foi Platfoim-Specic Model.
Requirement It is a statement that identies a necessaiy attiibute, capability, chaiacteiistic, oi
quality of a system in oidei foi it to have value and utility to a usei.
Reuse Te ability of using existing aitifacts, oi knowledge, to build oi synthesize new
solutions, oi to apply existing solutions to dieient aitifacts.
SDIC Acionym foi Sofwaie Development Iifecycle.
Separation of Concerns A concept that establishes the fact that a paiticulai functionality of a systems
should be the concein of dieient, specialized, components.
Silver Bullet In sofwaie engineeiing, it iefeis to the claim that theie is no single development,
in eithei technology oi management technique, which by itself piomises even one
oidei of magnitude (tenfold) impiovement within a decade in pioductivity, ieli-
ability, and/oi simplicity [Bio8,].
Sonware Product Iine A set of sofwaie systems which shaie a common, managed set of featuies that
satisfy the specic needs of a paiticulai maiket segment oi mission and that aie
developed fiom a common set of coie assets in a piesciibed way [CNo:].
Transparency In ieective systems, it is a measuie of how much of the undeilying system is
available thiough ieection.
UI Acionym foi Usei Inteiface.
UMI Acionym foi Unied Modeling Ianguage [OMG:od].
Usability Te extent to which a pioduct can be used by specied useis to achieve speci-
ed goals with eectiveness, eciency and satisfaction in a specied context of
use [ISO8].
Use Case In sofwaie engineeiing, it is a desciiption of an intended systems behavioi as the
iespond to an outside iequest oi inteiaction.
Variability Te need of a sofwaie systemoi aitifact to be changed, customized oi conguied
foi use in dieient contexts [JVBSo:].
VM Acionym foi Viitual Machine.
XMI Acionym foi eXtensible Maikup Ianguage. An open standaid which species a
set of iules foi encoding documents in both human and machine-ieadable foim.
XP Acionym foi eXtieme Piogiamming. An agile sofwaie development methodol-
ogy which is intended to impiove sofwaie quality and iesponsiveness to changing
customei iequiiements [BAo].
:8o omici:1Uvi
XSIT Acionym foi eXtensible Stylesheet Ianguage Tiansfoimations. A declaiative,
XML-based language used foi the tiansfoimation of XML documents into othei
XML (oi textual) documents.
References
[ABBLo,] M Ainoldi, K Beck, M Bieii, and M Lange, Time travel. A pattern language for values that change.
Cited on pp. 88 and 8.
[ADo,] Ademai Aguiai and Gabiiel David, Vikiwiki weaving heterogeneous sofware artifacts, WikiSym o,:
Pioceedings of the :oo, inteinational symposium on Wikis (New Yoik, NY, USA), ACM, :oo,,
pp. o,,. Cited on p. ,.
[AEQ] Jim Ailow, Wolfgang Emmeiich, and John Quinn, Literate modelling capturing business knowl-
edge with the uml, UML8: Selected papeis fiom the Fiist Inteinational Woikshop on Te Unied
Modeling Language (London, UK), Spiingei-Veilag, :, pp. :8:. Cited on p. :,.
[AGo,] Katja Andiesen and Noibeit Gionau, An approach to increase adaptability in erp systems, Pioceedings
of the :oo, Infoimation Recouices Management Association Inteinational Confeience, Idea Gioup
Publishing, May :oo,, pp. 88,88,. Cited on p. :o.
[Aguo,] Ademai Aguiai, A minimalist approach to framework documentation, Ph.D. thesis, Faculdade de En-
genhaiia da Univeisidade do Poito, Septembei :oo,. Cited on pp. ,, and ,.
[AIS,,] Chiistophei Alexandei, Saia Ishikawa, and Muiiay Silveistein, A pattern language. Towns, buildings,
construction, Oxfoid Univeisity Piess, Octobei :,,. Cited on pp. , ,8, o:, and :8,.
[AKK] KAltmanningei, GKappel, and AKusel, Amortowards adaptable model versioning, info.fundp.ac.be.
Cited on pp. 8,, 8, and :.
[Aleo] Chiistophei Alexandei, ^otes on the synthesis of form, Haivaid Univeisity Piess, Octobei :o. Cited
on pp. 8, , and ,,.
[Ambo,] Scott Amblei, Agile database techniques. Eective strategies for the agile sofware developer, John Wiley
& Sons, Inc., New Yoik, NY, USA, :oo,. Cited on p. :o,.
[And] F Andeison, A collection of history patterns, Collected papeis fiom the PLoP8 and EuioPLoP8
Confeience. Cited on p. 88.
[AOSDo,] Nicolas Anquetil, Kathia M. Oliveiia, Kleibei D. Sousa, and Maicio G. Batista Dias, Sofware main-
tenance seen as a knowledge management issue, Inf. Sofw. Technol. p (:oo,), no. ,, ,:,,:. Cited
on p. .
[Aisoo] A Aisanjani, Rule object. A pattern language for adaptive and scalable business rule construction, Pio-
ceeding of PLoP (:ooo). Cited on pp. o, , and o.
[ASo] Haiold Abelson and Geiald J. Sussman, Structure and interpretation of computer programs, MITPiess,
Cambiidge, MA, USA, :o. Cited on p. ::.
[ATMBoo] Mehmet Aksit, Bedii Tekineidogan, Fiancesco Maicelloni, and Lodewijk Beigmans, Deriving object-
oriented frameworks from domain knowledge, Building Application Fiamewoiks: Object-Oiiented
Foundations of Fiamewoik Design (Mohamed E. Fayad, Douglas C. Schmidt, and Ralph E. Johnson,
eds.), John Wiley & Sons Inc., New Yoik, USA, :ooo, pp. :o:8. Cited on pp. ,: and ,.
:88 REFERENCES
[BAo] Kent Beck and Cynthia Andies, Extreme programming explained. Embrace change, :nd ed., Addison-
Wesley Piofessional, :oo. Cited on pp. , o, and :8,.
[Bas8,] P.G. Bassett, Frame-based sofware engineering, IEEE Sofwaie (:8,), :o. Cited on p. ::.
[BBHo] F. L. Bauei, L. Bolliet, and Di. H. J. Helms, Sofware engineering, Repoit on a confeience sponsoied by
the NATOSCIENCE COMMITTEE (Petei Naui and Biian Randell, eds.), Scientic Aaiis Division,
NATO, :o, p. :,o. Cited on p. :.
[BEK
+
o] Baitosz Bbel, Johann Edei, Chiistian Koncilia, Tadeusz Moizy, and Robeit Wiembel, Creation and
management of versions in multiversion data warehouse, SACo: Pioceedings of the :oo ACMsym-
posium on Applied computing (New Yoik, NY, USA), ACM, :oo, pp. ,:,,:,. Cited on pp. 8o, 8,,
8, and :.
[BME
+
o,] Giady Booch, Robeit A. Maksimchuk, Michael W. Engel, Bobbi J. Young, Jim Conallen, and Kelli A.
Houston, Object-oriented analysis and design with applications, Addison-Wesley Piofessional, :oo,.
Cited on p. :8,.
[BMR
+
o] Fiank Buschmann, Regine Meuniei, Hans Rohneit, Petei Sommeilad, and Michael Stal, Pattern-
oriented sofware architecture volume :. A system of patterns, Wiley, August :o. Cited on pp. , ,8,
,,, ,, :,,, and :8.
[Bio8,] Fied P. Biooks, ^o silver bullet essence and accidents of sofware engineering, IEEE Computei io
(:8,), :o:. Cited on pp. :, ,:, and :8,.
[BWo] Fedeiico Biancuzzi and Shane Waiden, Masterminds of programming. Conversations with the creators
of major programming languages, OReilly Media, Inc., :oo. Cited on p. ::.
[Camo] Camaia Municipal do Poito, Reviso do Plano Director Municipal do Porto Regulamento, Maio :oo.
Cited on p. ::o.
[Caz8] Waltei Cazzola, Evaluation of object-oriented reective models, Pioceedings of ECOOP Woikshop on
Reective Object-Oiiented Piogiamming and Systems (EWROOPS8), in ::th Euiopean Confei-
ence on Object-Oiiented Piogiamming (ECOOP8) (:8). Cited on pp. :o, ::, and o.
[CEoo] Kiysztof Czainecki and Uliich Eiseneckei, Generative programming. Methods, tools, and applications,
Addison-Wesley Piofessional, June :ooo. Cited on p. :,.
[CEF8] Andy Cailson, Shaion Estepp, and Maitin Fowlei, Temporal patterns, PLoP 8: Pioceedings of the
,th Confeience on Pattein Languages of Piogiams, August :8. Cited on p. 88.
[CI8] Robeit D. Cameion and M. Robeit Ito, Grammar-based denition of metaprogramming systems, ACM
Tiansactions on Piogiamming Languages and Systems o (:8), no. :, :o,. Cited on pp. :: and :8.
[CJMS:o] Jeiey C. Caivei, Letizia Jaccheii, SandioMoiasca, andFoiiest Shull, Achecklist for integrating student
empirical studies with research and teaching goals, Empiiical Sofw. Eng. , (:o:o), no. :, ,,,. Cited
on p. :,:.
[Cle88] J. Ciaig Cleaveland, Building application generators, IEEE Sofw. , (:88), no. , :,,,. Cited on p. ::.
[CLG
+
o] Betty H. Cheng, Rogiio Lemos, Holgei Giese, Paola Inveiaidi, and Je Magee (eds.), Sofware engi-
neering for self-adaptive systems, Spiingei-Veilag, Beilin, Heidelbeig, :oo. Cited on p. :o.
[CNo:] Paul Clements and Linda Noithiop, Sofware product lines. practices and patterns, Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, :oo:. Cited on pp. :8 and :8,.
[Copo] James O. Coplien, Sofware patterns, :o. Cited on p. o:.
[CPP:o] Filipe Coiieia, Fatima Piies, and Auilio Piies, Tech. iepoit, PaiadigmaXis, S.A., :o:o, http://gisa.
paradigmaxis.pt/. Cited on p. ::,.
REFERENCES :8
[Cun,] Waid Cunningham, VikiVikiVeb, :,, http://c2.com/cgi/wiki. Cited on pp. , and o.
[Cuno,] , Viki design principles, :oo,, http://c2.com/cgi/wiki$?WikiDesignPrinciples. Cited on
pp. , and o.
[CVo,] Rudi Cilibiasi and Paul Vitanyi, Clustering by compression, :oo,, pp. :,:,:,,. Cited on p. ::8.
[CWo] A Coiiea and C Weinei, Applying refactoring techniques to uml/ocl models, UML (:oo). Cited on
p. :.
[Czao] Kizysztof Czainecki, Overview of generative sofware development, Unconventional Piogiamming
Paiadigms (UPP), Spiingei-Veilag, Septembei :oo, pp. ,:,,:8. Cited on p. :,.
[ddB:o] Antoine dOtieppe de Bouvette, Aspyct, :o:o, [Online; Accessed :8-August-:o:o]. Cited on p. :,.
[Dij,:] Edsgei Wybe Dijkstia, Te Humble Programmer, Communications of the ACM , (:,:), no. :o,
8,8oo. Cited on p. :.
[DSo] Petei DeGiace and Leslie Hulet Stahl, Vicked problems, righteous solutions, Youidon Piess, Uppei
Saddle Rivei, NJ, USA, :o. Cited on p. ,.
[DW] Desmond F. DSouza and Alan Cameion Wills, Objects, components, and frameworks with uml. the
catalysis approach, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, :. Cited on
p. ,:.
[DYBJo8] Ayla Dantas, Joseph Yodei, Paulo Boiba, and Ralph Johnson, Using aspects to make adaptive object-
models adaptable, Reseaich Repoits on Mathematical and Computing Sciences (:oo8). Cited on p. :,.
[EV:o] J. Lauienz Eveleens and Chiis Veihoef, Te rise and fall of the chaos report gures, IEEE Sofwaie i;
(:o:o), ,o,o. Cited on p. :.
[Evao,] Eiic Evans, Domain-driven design. Tackling complexity in the heart of sofware, Addison-Wesley Pio-
fessional, August :oo,. Cited on pp. :8 and :8,.
[FAFo] Hugo Seieno Feiieiia, Ademai Aguiai, and Joao Pascoal Faiia, Adaptive object-modelling. Patterns,
tools and applications, Inteinational Confeience on Sofwaie Engineeiing Advances (Los Alamitos,
CA, USA), IEEE Computei Society, :oo, pp. ,,o,,,. Cited on p. :,.
[FCR:o] Nuno Floies, Filipe Coiieia, and Rosaldo Rossetti, :o:o, https://www.fe.up.pt/si/disciplinas_
geral.FormView?P_CAD_CODIGO=EIC0086&P_ANO_LECTIVO=2010/2011&P_
PERIODO=1S [Online; accessed :o-Decembei-:o:o]. Cited on p. :,o.
[FCWo8] Hugo Seieno Feiieiia, Filipe Figueiiedo Coiieia, and Leon Welicki, Patterns for data and metadata
evolution in adaptive object-models, PLoP o8: Pioceedings of the :,th Confeience on Pattein Lan-
guages of Piogiams (New Yoik, NY, USA), ACM, :oo8, pp. :. Cited on p. ,8.
[Fed:o] Fedoia Commons, Introduction to Fedora Object XML (FOXML), :o:o, http://www.fedora-
commons.org/download/2.0/userdocs/digitalobjects/introFOXML.html [Online; accessed ,:-
July-:o:o]. Cited on p. ::,.
[FJoo] Mohamed E. Fayad and Ralph E. Johnson, Domain-specic application frameworks. framework expe-
rience by industry, John Wiley & Sons, Inc., New Yoik, NY, USA, :ooo. Cited on p. ,:.
[Fowo] MaitinFowlei, Analysis patterns. Reusable object models, Addison-Wesley Piofessional, Octobei :o.
Cited on pp. o and .
[Fow,] , Analysis patterns. reusable objects models, Addison-Wesley Longman Publishing Co., Inc,
Boston, MA, USA, :,. Cited on p. .
[Fow] , Refactoring. Improving the design of existing code, Addison-Wesley, Boston, MA, USA, :.
Cited on p. :.
:o REFERENCES
[Fowo:] , Patterns of enterprise application architecture, Addison-Wesley Piofessional, Novembei
:oo:. Cited on pp. 8:, 8o, 8, o, and :.
[Fow:oa] , Analysis patterns. Audit log, :o:o, http://www.martinfowler.com/ap2/auditLog.html
[Online; accessed ,-July-:o:o]. Cited on p. 8,.
[Fow:ob] , Analysis patterns. Eectivity, :o:o, http://www.martinfowler.com/ap2/effectivity.html
[Online; accessed ,-July-:o:o]. Cited on p. 88.
[Fow:oc] , Analysis patterns. Temporal object, :o:o, http://www.martinfowler.com/ap2/
temporalObject.html [Online; accessed ,-July-:o:o]. Cited on p. 88.
[Fow:od] , Analysis patterns. Temporal property, :o:o, http://www.martinfowler.com/ap2/
temporalProperty.html [Online; accessed ,-July-:o:o]. Cited on p. 88.
[FPRoo] Maicus Fontouia, Wolfgang Piee, and Beinhaid Rumpe, Te UML Prole for Framework Architec-
tures, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, :ooo. Cited on pp. ,: and ,,.
[FRo,] Robeit Fiance and Beinhaid Rumpe, Model-driven development of complex sofware. A research
roadmap, FOSE o,: :oo, Futuie of Sofwaie Engineeiing (Washington, DC, USA), IEEE Computei
Society, :oo,, pp. ,,,. Cited on pp. :,, :, and ,o.
[FSJa] Mohamed E. Fayad, Douglas C. Schmidt, and Ralph E. Johnson, Building application frameworks.
object-oriented foundations of framework design, John Wiley & Sons, Inc., New Yoik, NY, USA, :.
Cited on p. ,:.
[FSJb] , Implementing application frameworks. object-oriented frameworks at work, John Wiley &
Sons, Inc., New Yoik, NY, USA, :. Cited on pp. ,: and ,.
[FY,] Biian Foote and Joseph Yodei, Big ball of mud, Pattein Languages of Piogiam Design, Addison-
Wesley, :,, pp. o,,o:. Cited on pp. , and ,:.
[GAo,] Miguel Goulao and Feinando Biito Abieu, Modeling the experimental sofware engineering process,
QUATIC o,: Pioceedings of the oth Inteinational Confeience on Quality of Infoimation and Com-
munications Technology (Washington, DC, USA), IEEE Computei Society, :oo,, pp. ,,o. Cited
on p. ,8.
[Gabo] Richaid P. Gabiiel, Patterns of sofware. tales from the sofware community, Oxfoid Univeisity Piess,
Inc. New Yoik, NY, USA, :o. Cited on p. xix.
[GGGRo] Poonam Goyal, Navneet Goyal, Ashish Gupta, and T. S. Rahul, Designing self-adaptive websites using
online hotlink assignment algorithm, Pioceedings of the ,th Inteinational Confeience on Advances in
Mobile Computing and Multimedia, :oo, pp. ,,,8,. Cited on p. :,,.
[GHJV] Eiich Gamma, Richaid Helm, Ralph Johnson, and John M. Vlissides, Design patterns. Elements of
reusable object-oriented sofware, Addison-Wesley Piofessional, Novembei :. Cited on pp. , ,,,
,8, ,, o, ,, ,,, o:, 8:, 8,, 8,, 88, o, o, :oo, :o8, ::o, :,,, and :8,.
[GHV,] E. Gamma, R. Helm, and J. Vlissides, Design patterns applied, :,. Cited on p. ,8.
[GJTo,] Raghu Gaiud, Sanjay Jain, and Philipp Tueitschei, Incomplete by design and designing for incomplete-
ness, Oiganization studies as a science of design (Maiianne and Geoiges Romme, eds.), :oo,. Cited
on pp. ,, o, and ,.
[GNU:o] GNU, G^U Diutils, :o:o, http://www.gnu.org/software/diffutils/ [Online; accessed ,-July-
:o:o]. Cited on p. ::8.
[Goo] Google, iGoogle, http://google.com/ig [Online; accessed :o-July-:o:o]. Cited on p. :,o.
[Gopoo] Ganesh Gopalakiishnan, Computation engineering. Applied automata theory and logic, Spiingei-
Veilag New Yoik, Inc., Secaucus, NJ, USA, :ooo. Cited on p. xx.
REFERENCES ::
[Gouo8] Miguel Goulao, Component-based sofware engineering. a quantitative approach, Ph.D. thesis, Facul-
dade de Cincias e Tecnologia, Univeisidade Nova de Lisboa, :oo8. Cited on pp. :o and :,.
[GPHSo8] Cesai Gonzalez-Peiez and Biian Hendeison-Selleis, Metamodelling for sofware engineering, Wiley
Publishing, :oo8. Cited on p. :.
[GR8,] Adele Goldbeig and David Robson, Smalltalk-8o. the language and its implementation, Addison-
Wesley Longman Publishing Co., Inc., Boston, MA, USA, :8,. Cited on p. ,,.
[Gia:o] Joao Giadim, :o:o, http://paginas.fe.up.pt/ei05030/thesis/ [Online; accessed :o-Decembei-
:o:o]. Cited on p. :,,.
[Han] David Heinemeiei Hansson, Ruby on rails, [Online; Accessed :8-August-:o:o]. Cited on p. ,,.
[HBJo] Maikus Heiimannsdoeifei, Sebastian Benz, and Elmai Jueigens, Cope - automating coupled evolution
of metamodels and models, Genoa: Pioceedings of the :,id Euiopean Confeience on ECOOP :oo
Object-Oiiented Piogiamming (Beilin, Heidelbeig), Spiingei-Veilag, :oo, pp. ,:,o. Cited on
pp. 8, and :.
[HCo:] Geoige T. Heineman and William T. Councill (eds.), Component-based sofware engineering. putting
the pieces together, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, :oo:. Cited on
p. :,.
[Hei8] Constance L. Heitmeyei, Onthe need for practical formal methods, FTRTFT8: Pioceedings of the ,th
Inteinational Symposium on Foimal Techniques in Real-Time and Fault-Toleiant Systems (London,
UK), Spiingei-Veilag, :8, pp. :8:o. Cited on p. ,.
[HL,] Tim Hait and Mike Levin, Ai memo -the new compiler. Cited on p. :,,.
[Hof,] Douglas R. Hofstadtei, Godel, escher, bach. An eternal golden braid, Basic Books, Inc., New Yoik, NY,
USA, :,. Cited on p. :,.
[HW] Myles Hollandei and Douglas A. Wolfe, ^onparametric statistical methods, :nd ed., Wiley-
Inteiscience, Januaiy :. Cited on p. :o.
[ISO8] ISO ::-::::8, Ergonomic requirements for oce work with visual display terminals (vdts) part ::.
Guidance on usability, ISO, Geneva, Switzeiland, :8. Cited on pp. o, and :8,.
[Jet:o] JetBiains, Meta Programming System, :o:o, [Online; Accessed :8-August-:o:o]. Cited on p. :o.
[JF88] Ralph E. Johnson and Biian Foote, Designing reusable classes, Jouinal of Object-Oiiented Piogiam-
ming (:88), no. :, ::,,. Cited on p. ,:.
[JO8] Ralph Johnson and Je Oakes, Te user-dened product framework, :8. Cited on p. ,8.
[Joh,8] Stephen C. Johnson, Yacc. Yet another compiler-compiler, Tech. iepoit, Bell Laboiatoiies, :,8. Cited
on p. :o.
[JVBSo:] GuipJilles Van, JanBosch, andMikael Svahnbeig, Onthe notionof variability insofware product lines,
WICSA o:: Pioceedings of the Woiking IEEE/IFIP Confeience on Sofwaie Aichitectuie (Washing-
ton, DC, USA), IEEE Computei Society, :oo:, p. ,. Cited on pp. : and :8,.
[JW,] Ralph Johnson and Bobby Woolf, Te type object pattern, Pattein Languages of Piogiam Design ,,
Addison-Wesley, :,, pp. ,o,. Cited on pp. o, :, :, and :,,.
[KAKB
+
o8] Baibaia Kitchenham, Hiyam Al-Khilidai, Muhammed Ali Babai, Mike Beiiy, Kail Cox, Jacky Ke-
ung, Felicia Kuiniawati, Maik Staples, He Zhang, and Liming Zhu, Evaluating guidelines for reporting
empirical sofware engineering studies, Empiiical Sofw. Eng. (:oo8), no. :, ,:::. Cited on p. ,8.
:: REFERENCES
[Kay,] Alan C. Kay, Te early history of smalltalk, HOPL-II: Te second ACM SIGPLAN confeience on His-
toiy of piogiamming languages (New Yoik, NY, USA), ACM, :,, pp. o,. Cited on pp. :, ,,
and :,,.
[KHo:] Giegoi Kiczales and Eiik Hilsdale, Aspect-oriented programming, ESEC/FSE-: Pioceedings of the
8th Euiopean sofwaie engineeiing confeience held jointly with th ACM SIGSOFT inteinational
symposium on Foundations of sofwaie engineeiing (New Yoik, NY, USA), ACM, :oo:, p. ,:,. Cited
on pp. :, and :,.
[KMo,] Giegoi Kiczales and Miia Mezini, Aspect-oriented programming and modular reasoning, ICSE o,:
Pioceedings of the :,th inteinational confeience on Sofwaie engineeiing (New Yoik, NY, USA),
ACM, :oo,, pp. ,8. Cited on p. :,.
[KOSo,] John Kiogstie, Andieas L. Opdahl, and Guttoim Sindie (eds.), Advanced information systems en-
gineering, :th international conference, caise :oo,, trondheim, norway, june ::-:,, :oo,, proceedings,
Lectuie Notes in Computei Science, vol. ,, Spiingei, :oo,. Cited on p. :,.
[KPo] Chiistian Kohls and Stefanie Panke, Is that true...? thoughts on the epistemology of patterns, PLoP
o: Pioceedings of the :oth Confeience on Pattein Languages of Piogiams, :oo. Cited on p. o:.
[LCo,] Donal Laeity and Vinny Cahill, Language-independent aspect-oriented programming, OOPSLA o,:
Pioceedings of the :8th annual ACMSIGPLANconfeience on Object-oiiented piogiaming, systems,
languages, and applications (New Yoik, NY, USA), ACM, :oo,, pp. :::. Cited on p. :,.
[Lev8o] Leon S. Levy, A metaprogramming method and its economic justication, IEEE Tians. Sofw. Eng. i
(:8o), no. :, :,::,,. Cited on p. :,.
[Lewo] Action research and minority problems, Jouinal of Social Issues i (:o), no. , ,o. Cited on p. ,.
[Lik,:] Rensis Likeit, A technique for the measurement of attitudes, Aichives of Psychology ii (:,:), no. :o,
:,,. Cited on pp. :: and :,.
[LVo8] Ming Li and Paul M.B. Vitnyi, An introduction to kolmogorov complexity and its applications, Spiingei
Publishing Company, Incoipoiated, :oo8. Cited on p. ::8.
[MBo:] Stephen J. Melloi and Maic Balcei, Executable uml. A foundation for model-driven architectures,
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, :oo:. Cited on p. ,o.
[Medo,] MediaWiki, MediaViki MediaViki, Te Free Viki Engine, :oo,, [Online; accessed:o-August-:o:o].
Cited on p. ,.
[MFJo,] Pieiie-Alain Mullei, Fianck Fleuiey, and Jean-Maic Jzquel, Veaving executability into object-
oriented meta-languages, Pioceedings of the 8th Inteinational Confeience on Model Diiven Engi-
neeiing Languages and Systems, Octobei :oo,. Cited on p. :.
[MHSo,] Maijan Meinik, Jan Heeiing, and Anthony M. Sloane, Vhen and how to develop domain-specic lan-
guages, ACM Comput. Suiv. ; (:oo,), no. , ,:o,. Cited on p. :o.
[Min] Ministiio do Equipamento, do Planeamento e da Administiaao do Teiiitoiio, Decreto-Lei n. 8o/,
Setembio :. Cited on p. ::o.
[MJoo] Petei Meso and Radhika Jain, Agile sofware development. Adaptive systems principles and best prac-
tices, Infoimation Systems Management i (:ooo), no. ,, :,o. Cited on p. :o.
[MMo,] J. Millei and J. Mukeiji, Mda guide version :.o.:, Tech. iepoit, Object Management Gioup (OMG),
:oo,. Cited on pp. : and ,o.
[MRB,] Robeit Maitin, Diik Riehle, and Fiank Buschmann (eds.), Pattern languages of program design ,
Addison-Wesley, :,. Cited on p. o:.
REFERENCES :,
[MSo,] David Meitz and Michele Simionato, Metaclass programming in Python, :oo,, [Online; Accessed :o-
July-:o:o]. Cited on p. :,.
[Nai,] Bonnie A. Naidi, A small matter of programming. Perspectives on end user computing, MIT Piess,
Cambiidge, MA, USA, :,. Cited on p. ,:.
[NDPo] Oscai Nieistiasz, Stphane Ducasse, and Damien Pollet, Squeak by example, Squaie Biacket Asso-
ciates, Octobei :oo. Cited on p. ,,.
[NLoo] Colin J. Neill and Philip A. Laplante, Paying down design debt with strategic refactoring, Computei p
(:ooo), :,::,. Cited on p. ,.
[OMG:oa] OMG, MetaObject Facility (MOF), :o:o, http://www.omg.org/mof/ [Online; accessed ,-July-
:o:o]. Cited on pp. ,o, o,, and :8.
[OMG:ob] , Model Driven Architecture (MDA), :o:o, http://www.omg.org/mda/ [Online; accessed
,-July-:o:o]. Cited on pp. ,o and :8.
[OMG:oc] , Object Constraint Language (OCL), :o:o, http://www.omg.org/spec/OCL/ [Online; ac-
cessed ,-July-:o:o]. Cited on p. :,.
[OMG:od] , Unied Modelling Language (UML), :o:o, http://www.uml.org/ [Online; accessed ,-July-
:o:o]. Cited on pp. :,, :8,, and :8,.
[Opeo8] Open Souice, bzip:, :oo8, http://www.bzip.org/ [Online; accessed ,-July-:o:o]. Cited on p. ::8.
[Ope:o] , Prevayler the open source prevalence layer, :o:o, http://www.prevayler.org [Online;
accessed ,-July-:o:o]. Cited on pp. 8,, 8, and :.
[Pag] Pageakes, http://pageflakes.com/ [Online; accessed :o-July-:o:o]. Cited on p. :,o.
[Paio,] Teience Paii, Te Denitive A^TLRReference. Building Domain-Specic Languages, Piagmatic Book-
shelf, :oo,. Cited on p. :o.
[Pawo] Richaid Pawson, ^aked objects, Ph.D. thesis, Univeisity of Dublin, Tiinity College, June :oo. Cited
on pp. :8, o, and :8.
[Pei8:] Alan J. Peilis, Special feature. Epigrams on programming, SIGPLAN Not. ; (:8:), ,:,. Cited on
p. :,8.
[PFSP:o] Auilio Piies, Hugo Seieno Feiieiia, Hugo Silva, and Jos Poito, Locvs gesto do patrimonio ar-
quitectonico e arqueologico da cidade do porto, Tech. iepoit, PaiadigmaXis, S.A., :o:o, Pioduced foi
Camaia Municipal do Poito. Cited on p. ::o.
[PQ,] Teience Paii and Russell Quong, A^TLR. A Predicated-LL(k) parser generator, Jouinal of Sofwaie
Piactice and Expeiience, i, (:,), no. ,, ,88:o. Cited on p. :o.
[Pie] Hot-spot-driven development, John Wiley and Sons., :. Cited on p. ,:.
[PTo,] Caila Pacheco and Edmundo Tovai, Stakeholder identication as an issue in the improvement of sof-
ware requirements quality, CAiSEo,: Pioceedings of the :th inteinational confeience on Advanced
infoimation systems engineeiing (Beilin, Heidelbeig), Spiingei-Veilag, :oo,, pp. ,,o,8o. Cited on
p. .
[Pyp] Pypy, http://codespeak.net/pypy/dist/pypy/doc/ [Online; accessed :o-July-:o:o]. Cited on
p. :,,.
[RD8] D Riehle and E Dubach, Vhy a bank needs dynamic object models, OOPSLA Woikshop on Metadata
and Active Object Models (:8). Cited on p. ,8.
: REFERENCES
[RFBLOo:] Diik Riehle, Steven Fialeigh, Diik Bucka-Lassen, and Nosa Omoiogbe, Te architecture of a uml vir-
tual machine, OOPSLA o:: Pioceedings of the :oth ACM SIGPLAN confeience on Object-oiiented
piogiamming, systems, languages, and applications (New Yoik, NY, USA), ACM, :oo:, pp. ,:,,:.
Cited on pp. :,, :, :,, :, and ,o.
[RG8] Diik Riehle and Tomas Gioss, Role model based framework design and integration, SIGPLAN Not.
(:8), no. :o, ::,:,,. Cited on p. ,:.
[RJo] Don Robeits and Ralph Johnson, Evolving frameworks. A pattern language for developing object-
oriented frameworks, Pioceedings of the Tiid Confeience on Pattein Languages and Piogiamming,
vol. ,, :o. Cited on pp. ,:, ,:, ,,, ,,, ,,, ,, and :8.
[RKS8] G Roy, J Kelso, and C Standing, Towards a visual programming environment for sofware development,
Pioceedings on Sofwaie Engineeiing: Education & Piactice (:8). Cited on pp. :, and :8.
[RLo] Awais Rashid and Nicholas Leidenfiost, Supporting exible object database evolution with aspects,
Spiingei, :oo, pp. ,,. Cited on pp. 8o, 8:, 8,, 8, and :.
[Roy8,] Winston W. Royce, Managing the development of large sofware systems. concepts and techniques, Pio-
ceedings of the th inteinational confeience on Sofwaie Engineeiing (Los Alamitos, CA, USA), ICSE
8,, IEEE Computei Society Piess, :8,, pp. ,:8,,8. Cited on p. .
[Rub] Rubinus, http://rubini.us/ [Online; accessed :o-July-:o:o]. Cited on p. :,,.
[SAJ
+
o:] Eva Sdeistim, Biigei Andeisson, Paul Johannesson, Eiik Peijons, and Benkt Wanglei, Towards a
framework for comparing process modelling languages, CAiSE o:: Pioceedings of the :th Inteina-
tional Confeience on Advanced Infoimation Systems Engineeiing (London, UK), Spiingei-Veilag,
:oo:, pp. oooo::. Cited on p. :.
[Sch,] Han Albiecht Schmid, Systematic framework design by generalization, Commun. ACM o (:,),
no. :o, 8,:. Cited on p. ,:.
[Scho,] Baiiy Schwaitz, Te paradox of choice. Vhy more is less, Haipei Peiennial, Januaiy :oo,. Cited on
p. .
[Schoo] D.C. Schmidt, Model-driven engineering, IEEE Computei (:ooo), no. ,. Cited on pp. : and :8.
[Scho,] Weinei Schustei, Vhats a ruby dsl and what isnt?, June :oo,, http://www.infoq.com/news/2007/
06/dsl-or-not. Cited on p. :o.
[Shao:] Maiy Shaw, Te coming-of-age of sofware architecture research, ICSE o:: Pioceedings of the :,id
Inteinational Confeience on Sofwaie Engineeiing (Washington, DC, USA), IEEE Computei Society,
:oo:, p. o,o. Cited on p. ::.
[Spoo:] Joel Spolsky, Te law of leaky abstractions, :oo:, http://www.joelonsoftware.com/articles/
LeakyAbstractions.html [Online; accessed ,-July-:o:o]. Cited on p. ::.
[SSSo,] Foiiest Shull, Janice Singei, and Dag I.K. Sjobeig, Guide to advanced empirical sofware engineering,
Spiingei-Veilag New Yoik, Inc., Secaucus, NJ, USA, :oo,. Cited on p. ,8.
[Sta] Standish Gioup Inteinational, Te chaos report, Tech. iepoit, :. Cited on p. :.
[Stao,] Tointon Staples, An open-source digital object repository management system, :oo,. Cited on p. ::,.
[Steoo] Fiiediich Steimann, Te paradoxical success of aspect-oriented programming, OOPSLA oo: Pioceed-
ings of the ::st annual ACM SIGPLAN confeience on Object-oiiented piogiamming systems, lan-
guages, and applications (New Yoik, NY, USA), ACM, :ooo, pp. 8:,. Cited on p. :,.
[Suio,] James Suiowiecki, Te wisdom of crowds, Anchoi, :oo,. Cited on p. ,.
REFERENCES :,
[SVoo] Tomas Stahl and Maikus Vltei, Model-driven sofware development. Technology, engineering, man-
agement, Wiley, May :ooo. Cited on p. :.
[Szyo:] Clemens Szypeiski, Component sofware. Beyond object-oriented programming, Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, :oo:. Cited on p. :,.
[THB
+
oo] Dave Tomas, David Hansson, Leon Bieedt, Mike Claik, James Duncan Davidson, Justin Gehtland,
and Andieas Schwaiz, Agile web development with rails, Piagmatic Bookshelf, :ooo. Cited on pp. ,,
and ,o.
[THP,] Waltei F. Tichy, Nico Habeimann, and Lutz Piechelt, Summary of the dagstuhl workshop on future
directions in sofware engineering. February :,::, ::, schlodagstuhl, SIGSOFT Sofw. Eng. Notes
8 (:,), no. :, ,,8. Cited on p. ::.
[TN8o] Hiiotaka Takeuchi and Ikujiio Nonaka, Te new new product development game, Haivaid Business
Review (:8o). Cited on p. ,.
[TPTo] Susanna Teppola, Paivi Paiviainen, and Juha Takalo, Challenges in deployment of model driven devel-
opment, Inteinational Confeience on Sofwaie Engineeiing Advances (:oo), :,:o. Cited on p. ,o.
[Undo8] Understanding migrations in ruby on rails, :oo8, http://wiki.rubyonrails.org/rails/pages/
understandingmigrations [Online; accessed 8-August-:oo8]. Cited on p. :.
[Usio8] Using migrations in ruby on rails, :oo8, http://wiki.rubyonrails.org/rails/pages/
UsingMigrations [Online; accessed 8-August-:oo8]. Cited on p. :.
[Vlo,] Maikus Vltei, A catalog of patterns for program generation, Pioceedings of the Eighth Euiopean
Confeience on Pattein Languages of Piogiams, June :oo,. Cited on p. :,.
[Wai] Maitin P. Waid, Language-oriented programming, Sofwaie Concepts and Tools , (:), no. ,
:,:o:. Cited on p. :o.
[WBJo] Rebecca J. Wiifs-Biock and Ralph E. Johnson, Surveying current research in object-oriented design,
Commun. ACM (:o), no. , :o::. Cited on p. ,:.
[WCo,] Lauiie Williams and Alistaii Cockbuin, Guest editors introduction. Agile sofware development. Its
about feedback and change, Computei o (:oo,), ,,. Cited on p. .
[WEoo] Han-Chieh Wei and Ramez Elmasii, Schema versioning and database conversion techniques for bi-
temporal databases, Annals of Mathematics and Aiticial Intelligence o (:ooo), no. :-, :,,:. Cited
on pp. 8o, 8,, 8, and :.
[Web:o] Websteis Online Dictionaiy, Design, :o:o, http://www.websters-online-dictionary.org/ [Online;
accessed ,-July-:o:o]. Cited on p. 8.
[WGM8] Andi Weinand, Eiich Gamma, and Rudolf Maity, Design and implementation of ET++, a seamless
object-oriented application framework, Stiuctuied Piogiamming (:8), o,8,. Cited on p. ,:.
[Wik:oa] Wikipedia, Abstraction wikipedia, the free encyclopedia, :o:o, http://en.wikipedia.org/w/index.
php?title=Abstraction&oldid=373722967 [Online; accessed-July-:o:o]. Citedonpp. :oand:8,.
[Wik:ob] , Kolmogorov complexity wikipedia, the free encyclopedia, :o:o, http://en.wikipedia.org/
w/index.php?title=Kolmogorov_complexity&oldid=375473546 [Online; accessed :-August-
:o:o]. Cited on p. ::8.
[Wik:oc] , Metamodeling Vikipedia, Te Free Encyclopedia, :o:o, [Online; accessed -Septembei-
:o:o]. Cited on p. :,.
[Wik:od] , Vikipedia, Te Free Encyclopedia, :o:o, [Online; accessed :o-August-:o:o]. Cited on p. ,.
:o REFERENCES
[WYWBo,] Leon Welicki, Joseph Yodei, and Rebecca Wiifs-Biock, A pattern language for adaptive object models.
Part i-rendering patterns, PLoP o,: Pioceedings of the :th Confeience on Pattein Languages of
Piogiams, :oo,. Cited on pp. ,8, :, 8o, and ::.
[WYWBo] Leon Welicki, Joseph Yodei, and Rebecca Wiifs-Biock, Adaptive object-model builder, PLoP o: Pio-
ceedings of the :oth Confeience on Pattein Languages of Piogiams, :oo. Cited on pp. ,8 and 8o.
[WYWBJo,] Leon Welicki, Joseph Yodei, Rebecca Wiifs-Biock, and Ralph E. Johnson, Towards a pattern language
for adaptive object models, OOPSLA o,: Companion to the ::nd ACM SIGPLAN confeience on
Object-oiiented piogiamming systems and applications companion (New Yoik, NY, USA), ACM,
:oo,, pp. ,8,,88. Cited on pp. ,8, ,, o, :, , ,,, o,, 8o, 8:, and :.
[YBJo:a] Joseph Yodei, Fedeiico Balaguei, and Ralph Johnson, Adaptive object-models for implementing busi-
ness rules, Uibana (:oo:). Cited on pp. :, 8, and :oo.
[YBJo:b] , Architecture and design of adaptive object-models, ACMSIG-PLANNotices o (:oo:), ,ooo.
Cited on pp. :,, ,,, ,8, o, ,, 8, ,, and :8,.
[YFRT8] Joseph Yodei, Biian Foote, Diik Riehle, and Michel Tilman, Metadata and active object-models, OOP-
SLA 8 Addendum: Addendum to the :8 pioceedings of the confeience on Object-oiiented pio-
giamming, systems, languages, and applications (Addendum) (New Yoik, NY, USA), ACM, :8.
Cited on pp. ,8 and :oo.
[Yodo:] Joseph Yodei, Te adaptive object model architectural style, Sofwaie Aichitectuie: System Design
(:oo:). Cited on pp. , ,, , ,,, and :,,.
[ZW8] Maivin V. Zelkowitz and Doloies R. Wallace, Experimental models for validating technology, Com-
putei (:8), :,,:. Cited on pp. :: and ::.