MDE Ferramentas Modelagem

1
Simpósio Brasileiro de Sistemas
Multimídia e Web (WebMedia)
Marcos Alves Vieira
Sérgio Teixeira de Carvalho
marcos.vieira@ifgoiano.edu.br
sergio@inf.ufg.br
17 de outubro de 2017
Engenharia Dirigida por Modelos no Desenvolvimento de
Aplicações Ubíquas:
Tecnologias, Ferramentas e Linguagens
Material de apoio:
http://bit.ly/webmedia2017

2
Roteiro
1. Introdução
2. Fundamentação Teórica
i. Computação Ubíqua
ii. Computação Sensível ao Contexto
iii. Espaços Inteligentes Fixos
iv. Espaços Inteligentes Pessoais
v. Objetos Inteligentes
vi. Engenharia Dirigida por Modelos (Model-driven Engineering - MDE)
3. Fundamentação Tecnológica
i. Eclipse Modeling Framework (EMF)
ii. Eclipse Graphical Modeling Framework (GMF)
iii. Epsilon: uma família de linguagens e ferramentas relacionadas à MDE
4. Prática: desenvolvendo um editor gráfico de modelagem 1

3
1. Introdução
1

4
Objetivo
– Construção de uma ferramenta de modelagem gráfica para
construção de modelos em conformidade com um metamodelo
Público-alvo
– Estudantes (graduação e pós-graduação)
– Profissionais (desenvolvimento de sistemas)
Abordagem
– Teórico/prática
1. Introdução

5
1

6
Fases da computação (Weiser e Brown, 1997):
1. Era dos mainframes
– Computador era recurso escasso e atendia diversos
usuários
2. Computadores pessoais (PCs)
– Cada pessoa tem acesso exclusivo a um PC
3. Computação ubíqua
– Computação invisível ao usuário, fundida a elementos do
dia-a-dia
– Não requer interação por dispositivos tradicionais (i.e.
teclado e mouse)
– Foco do usuário está na tarefa e não no dispositivo
Computação Ubíqua

7
Algumas definições:
(Schilit e Theimer, 1994):
Adaptação do software de acordo com a sua localização de uso, o
conjunto de pessoas e os objetos próximos, assim como as
mudanças que esses objetos sofrem no decorrer do tempo
(Abowd et al., 1999) e (Dey, 2001):
Qualquer informação que possa ser usada para caracterizar a
situação de uma pessoa, lugar ou objeto relevante para a
interação entre um usuário e uma aplicação, incluindo estes
dois últimos.
Exemplo:
Computação Sensível ao Contexto
Temperatura Software Ar-condicionado

8
Definição (Lupiana et al., 2009):
Um ambiente computacional e sensorial altamente integrado que
efetivamente raciocine sobre os contextos físico e de usuário do
espaço para agir transparentemente com base em desejos
humanos.
Espaços Inteligentes Fixos (1/2)

9
humanos.
Altamente integrado:
saturado com dispositivos de computação ubíqua e sensores
completamente integrados com redes sem fio

10
humanos.
Raciocínio efetivo:
mecanismo pseudo-inteligente para o ambiente como um todo

11
humanos.
Contexto de usuário:
perfis individuais, políticas, localização atual e status de mobilidade

12
humanos.
Transparência:
ações humanas e com o suporte à mobilidade sem necessidade de
interação direta do usuário

13
Possibilita um maior controle sobre (Cook e Das, 2007):
– Os problemas de integração
– O comportamento do usuário
– A aquisição de conhecimento do ambiente e usuário
Desvantagens (Taylor, 2011):
– Espaços geograficamente limitados
Ilhas de ubiquidade (Crotty et al., 2009):
– Suporte limitado à computação ubíqua
– Não há compartilhamento de serviços e dispositivos com outros
espaços inteligentes

14
Personal Smart Spaces (PSS)
– Computação ubíqua + redes corporais
Projeto PERSIST (Dolinar et al., 2008):
– PSS → interface entre o usuário e
os serviços e dispositivos
– Interação com outros espaços inteligentes
Características de um PSS (Roussaki et al., 2008):
1. É móvel
2. Tem um “dono”
3. Deve ser capaz de se adaptar
4. Pode aprender com interações anteriores
Espaços Inteligentes Pessoais
Figura: PSS vs. espaço inteligente fixo.
Adaptado de (Gallacher et al., 2010).
mobilidade
autoaperfeiçoamento

15
Definição (Kortuem et al., 2010):
Entidades físico/digitais, aumentados com capacidades de sensoriamento,
processamento e possibilidade de conexão em rede
Capacidades (Siegemund, 2004):
– Perceber o ambiente por
meio de sensores
– Se comunicar com outros
objetos inteligentes
Objetos Inteligentes (1/2)
– Trabalhar colaborativamente
– Determinar o contexto
– Adaptar seu comportamento

16
Propriedades (Kawsar, 2009):
– ID única
– Ser identificado unicamente
– Autoconsciência
– Saber seu estado operacional e situacional
– Capacidade se descrever
– Sociabilidade
– Comunicar com outros objetos inteligentes e entidades
computacionais (e.g., uma aplicação sensível ao contexto)
– Autonomia
– Tomar ações (e.g., mudar-se do estado desligado para ligado;
decisões autônomas)
Objetos Inteligentes (2/2)

17
Engenharia Dirigida por Modelos (Model-driven Engineering - MDE) (Seidewitz, 2003),
(Schmidt, 2006) e (Völter et al., 2013):
– Modelos são:
– Os principais artefatos no
desenvolvimento de um sistema
– Representação gráfica ou textual
de alto nível de um sistema
– Os relacionamentos e abstrações são
descritos por um metamodelo
Desenvolvimento Dirigido por Modelos
(Model-driven Development - MDD) e
Arquitetura Dirigida por Modelos
(Model-driven Architecture - MDA):
– Uso de abstrações mais próximas do domínio do problema
– Mitigar a distância semântica (semantic gap) existente entre o problema a ser
solucionado e o ferramental (software)
Engenharia Dirigida por Modelos (1/4)
Modelos ≠ Diagramas UML
‒ UML é apenas uma linguagem
de modelagem
‒ Diferentes domínios têm
diferentes abstrações
‒ Modelos ≠ figuras
‒ Modelos podem ser
gráficos ou textuais
‒ ou ambos...

18
Arquitetura de metamodelagem
Meta-Object Facility (MOF)
(Völter et al., 2013):
– Forma de padronização
para a construção de
modelos e metamodelos
– Apresentada pelo Object
Management Group (OMG)
– Cada elemento de uma
camada inferior é uma
instância de uma camada
superior
Figura: Camadas da arquitetura MOF.
Adaptado de (Völter et al., 2013).

19
Camada M3:
– Representa o meta-metamodelo
da MOF, também chamado de
Modelo MOF
– Utilizado para construção
dos metamodelos
– Exemplos de membros dessa
camada:
– Modelo MOF
– Ecore

20
Camada M2:
– Contém os metamodelos
– Utilizados para modelar
sistemas de domínio
específico
– Exemplo de membro dessa
camada:
– UML (Unified Modeling
Language)

21
Camada M1:
– Composta por modelos
– Descrevem sistemas
utilizando as definições
constantes em seus
respectivos metamodelos
presentes em M2
camada:
– Um diagrama de classes da
UML

22
Camada M0:
– Contém as entidades ou objetos
que formam o sistema em
execução
– São criadas a partir das
definições presentes em M1
camada:
– O objeto cliente da classe
Pessoa de um sistema de
vendas

23
Linguagem de Modelagem Específica de Domínio
(Domain-specific Modeling Language - DSML)
(Van Deursen et al., 2000) e (Chiprianov et al., 2014)
– Linguagem textual ou gráfica para construção de modelos específicos de um
determinado domínio
– Definida por um metamodelo
– Possui sintaxe e semântica
– Sintaxe abstrata
– Conceitos e seus relacionamentos
– Sintaxe concreta
– Elementos visuais que representam a sintaxe abstrata
– Semântica
– Significado das representações da sintaxe

24
Requisitos para construção de DSMLs (Kolovos et al., 2006):
1. Conformidade
2. Ortogonalidade
3. Suporte
4. Integração
5. Longevidade
6. Simplicidade
7. Qualidade
8. Escalabilidade
9. Usabilidade
Requisitos gerais
Requisitos adicionais

25
1. Conformidade
– As construções devem corresponder a importantes conceitos do
domínio
2. Ortogonalidade
3. Suporte
4. Integração
5. Longevidade
6. Simplicidade
7. Qualidade
8. Escalabilidade
9. Usabilidade

26
1. Conformidade
2. Ortogonalidade
– Cada construção da linguagem deve ser usada para representar
exatamente um conceito distinto do domínio
3. Suporte
4. Integração
5. Longevidade
6. Simplicidade
7. Qualidade
8. Escalabilidade
9. Usabilidade

27
1. Conformidade
2. Ortogonalidade
3. Suporte
– Ferramentas para modelagem e gerenciamento de programação
e.g., criação de código, edição e transformação de modelos
4. Integração
5. Longevidade
6. Simplicidade
7. Qualidade
8. Escalabilidade
9. Usabilidade

28
1. Conformidade
2. Ortogonalidade
3. Suporte
4. Integração
– A linguagem, e suas ferramentas podem ser utilizadas em conjunto
com outras linguagens e ferramentas com o mínimo de esforço
5. Longevidade
6. Simplicidade
7. Qualidade
8. Escalabilidade
9. Usabilidade

29
1. Conformidade
2. Ortogonalidade
3. Suporte
4. Integração
5. Longevidade
– O domínio persista por um período de tempo suficiente para
justificar a construção da linguagem e suas ferramentas
6. Simplicidade
7. Qualidade
8. Escalabilidade
9. Usabilidade

30
1. Conformidade
2. Ortogonalidade
3. Suporte
4. Integração
5. Longevidade
6. Simplicidade
– Uma linguagem deve ser o mais simples possível
7. Qualidade
8. Escalabilidade
9. Usabilidade

31
1. Conformidade
2. Ortogonalidade
3. Suporte
4. Integração
5. Longevidade
6. Simplicidade
7. Qualidade
– Fornecer mecanismos para construção de sistemas de qualidade
8. Escalabilidade
9. Usabilidade

32
1. Conformidade
2. Ortogonalidade
3. Suporte
4. Integração
5. Longevidade
6. Simplicidade
7. Qualidade
8. Escalabilidade
– Fornecer construções para ajudar a gerenciar descrições de larga
escala, além de permitir a construção de sistemas menores
9. Usabilidade

33
1. Conformidade
2. Ortogonalidade
3. Suporte
4. Integração
5. Longevidade
6. Simplicidade
7. Qualidade
8. Escalabilidade
9. Usabilidade
– Economia, acessibilidade e facilidade de compreensão
– Coberto pelos requisitos gerais, e.g.,
simplicidade → compreensão → facilidade de uso

34
1

35
O que é?
– Framework de modelagem construído sobre o IDE Eclipse
Características
– Fornece mecanismos para criação, edição e validação de modelos e
metamodelos
– Possibilita a geração automática de código a partir dos modelos
– Os metamodelos construídos no EMF são instâncias do meta-
metamodelo Ecore
– Ecore é a linguagem central do EMF
Eclipse Modeling Framework (EMF) (1/5)

36
Figura: Meta-metamodelo Ecore (Merks e Sugrue, 2009).

37
Um metamodelo com base no Ecore é definido por meio de instâncias de:
– EClass
– Representa uma classe composta por atributos e referências
– EAttribute
– É um atributo que possui um nome e um tipo
– EReference
– Define uma associação entre classes
– ESuperType
– Define a(s) super-classe(s) de uma classe (possibilita herança múltipla)
– EDataType
– Tipo de um atributo
– Primitivo (número inteiro ou real, string, booleano, etc...)
– Enumeração EEnum
– Referência a uma EClass

38
Definindo metamodelos Ecore
– Editor com base em estrutura de árvore
– Editor com base em diagramas
– Linguagem Emfatic
– Sintaxe textual para definição de metamodelos Ecore
– Importação de
– Código Java
– Schema XML

39
Figura: Visão de estrutura de árvore.
Figura: Visão de diagrama.
Exemplo de metamodelo construído no EMF
Figura: Linguagem Emfatic.

40
Linguagem textual para definição de metamodelos Ecore
– Bastante similar ao Java
Suportado pelo IDE Eclipse
– Destaque de código
– Reportagem de erros
Mapeamento entre Emfatic ↔ Ecore
– É possível gerar um metamodelo Ecore a partir de um arquivo Emfatic
– É possível gerar um arquivo Emfatic a partir de um metamodelo Ecore
Emfatic (1/7)

41
Emfatic (2/7)
Figura: Editor Emfatic.

42
Emfatic (3/7)
‒ Especifica os atributos nsURI
e nsPrefix da classe
EPackage

43
Emfatic (4/7)
‒ Definição do pacote
(EPackage)
‒ No Ecore, um EPackage é
semanticamente o mesmo
que um metamodelo

44
Emfatic (5/7)
‒ Definição de classes
(EClass)
‒ A declaração de classes em
Ecore é bastante similar ao
Java

45
Palavra-chave
Emfatic
Significado Ecore
attr EAttribute
op EOperation
ref
normal EReference
(EReference.containment = false)
val
"by value" EReference
(EReference.containment = true)
Emfatic (6/7)
‒ Definição de características
das classes
‒ Atributos
‒ Referências
‒ Operações
Tabela: Palavras-chave para tipos de características
de classes.

46
Emfatic (7/7)
‒ Multiplicidade das
características da classe
‒ Define o limite inferior
(lowerBound) e superior
(upperBound) para cada
relacionamento
Emfatic
ETypedElement
lowerBound
ETypedElement
upperBound
none 0 1
[?] 0 1
[] 0 ilimitado (-1)
[*] 0 ilimitado (-1)
[+] 1 ilimitado (-1)
[1] 1 1
[n] n n
[0..4] 0 4
[m..n] m n
[5..*] 5 ilimitado (-1)
[1..?] 1 não especificado (-2)
Tabela: Expressões de multiplicidade.

47
Eclipse Graphical Modeling Framework (GMF) (1/7)
O que é?
– Framework com base no EMF para construção de editores gráficos
– Permite a criação de modelos em conformidade com um metamodelo

48
– Requer a criação de modelos específicos para a geração de um editor gráfico
– Modelo gráfico (GMFGraph)
– Especifica os elementos gráficos do editor
– Formas, conexões, rótulos, decorações, etc.
– Modelo da ferramenta (GMFTool)
– Especifica as ferramentas disponíveis na paleta do editor
– Criação de elementos do metamodelo
– Modelo de mapeamento (GMFMap)
– Mapeia
– Elementos gráficos no
modelo gráfico
– Ferramentas de criação no
modelo da ferramenta
‒ sintaxe abstrata no
metamodelo Ecore
(classes, atributos,
referências, etc.)

49
Obstáculos
– Os modelos do GMF são complexos e repletos de referências cruzadas
– O processo de geração dos modelos é propenso a erros
– Em caso de mudança no metamodelo, os modelos do GMF precisam ser
gerados novamente

50
Figura: GMF dashboard: assistente para criação dos modelos GMF (VIEIRA, 2016).

51
Figura: Processo de criação dos modelos GMF.
Adaptado de: <https://wiki.eclipse.org/Graphical_Modeling_Framework/Documentation/Index> (Vieira, 2016).

52
Figura: Exemplo de editor gráfico construído no GMF.

53
Figura: Editando o arquivo .gmfmap para customização do editor gráfico.

54
O que é?
– Família de linguagens e ferramentas para manipulação de modelos
– Geração de código, transformação, comparação, união, refatoramento
e validação de modelos
Composto pelas linguagens:
– Epsilon Object Language (EOL)
– Epsilon Validation Language (EVL)
– Epsilon Transformation Language (ETL)
– Epsilon Comparison Language (ECL)
Eugenia
– Ferramenta que auxilia na geração dos modelos requeridos pelo GMF
Epsilon
– Epsilon Merging Language (EML)
– Epsilon Wizard Language (EWL)
– Epsilon Generation Language (EGL)

55
O que é?
– Núcleo das linguagens da família Epsilon
– As demais linguagens estendem a EOL em sintaxe e semântica
– Oferece funcionalidades sobre as quais as demais linguagens são
implementadas
– Pode ser usada independentemente
– Criar, consultar e modificar modelos
Epsilon Object Language (EOL) (1/4)

56
Características
– Todas as construções usuais em programação
– Laços while e for, variáveis, etc.
– Possibilidade de criar e realizar chamadas a métodos de objetos Java
– Suporte para a adição dinâmica de operações em metaclasses em tempo
de execução
– Suporte a interação com o usuário
– Possibilidade de criação de bibliotecas de operações para serem
importadas e utilizadas em outras linguagens Epsilon

57
Figura: Visão geral do sistema de tipos de dados da linguagem EOL (Kolovos et al., 2015).

58
Código: Exemplo de código em linguagem EOL para calcular e imprimir a
profundidade de cada árvore (Tree) (Kolovos et al., 2015).

59
Objetivo
– Oferecer funcionalidades de validação à família Epsilon
– Especificar e avaliar restrições (invariantes) em modelos de um metamodelo
Características
– Distinção entre erros (error) e avisos (warning) durante a validação
– Especificação de consertos (quick fix) para erros encontrados pelas restrições
– Permite definir dependências entre as invariantes
– e.g., se a restrição A falhar, então não avalie a restrição B
– Todas as funcionalidades oferecidas pela linguagem EOL
– Suporte a operações lógicas de primeira ordem oriundas da OCL (select,
reject, collect, etc.)
– Suporte a interação com usuário
Epsilon Validation Language (EVL) (1/12)

60
– Especificações das validações são organizadas em módulos (EvlModule)
– Um módulo pode conter um conjunto de restrições (invariantes)
– Agrupadas pelo contexto em que serão aplicadas
Código: Exemplo de código em linguagem EVL para impedir autoreferenciamento em
uma determinada metaclasse (Vieira, 2016). Figura: Descrição do erro
(Vieira, 2016).
Figura: Erro encontrado no modelo
(Vieira, 2016).

61
Figura: Sintaxe abstrata da linguagem EVL (Kolovos et al., 2015).

62
Context
– Especifica o tipo de instâncias sobre as quais as invariantes (Invariant) serão avaliadas
– Pode opcionalmente definir uma guarda (guard)
– Limita sua aplicabilidade para um subconjunto menor
– Se uma guarda falha para uma instância de um tipo específico, nenhuma de suas
invariantes é avaliada

63
Invariant
– Cada invariante define um nome e um corpo (check)
– Pode ser do tipo
– restrição (Constraint), que lança um erro (error)
– crítica (Critique), lançando um aviso (warning)
– Pode opcionalmente definir uma guarda
(guard)
– Pode definir uma mensagem (message)
descrevendo o erro
– Pode opcionalmente definir um ou mais
consertos (Fix)

64
Guard
– Limita a aplicabilidade das invariantes a instâncias do tipo especificado
– Pode ser usada em dois níveis:
– No nível do contexto (Contex), limita todas as invariantes do contexto
– No nível da invariante (Invariant), limita uma invariante específica

65
Fix
– Permite a correção semi-automática de erros encontrados durante a validação
– É possível definir um título (title) e um bloco do, onde a funcionalidade de
conserto deve ser definida usando a linguagem EOL
– Deve-se garantir que o conserto realmente repare a inconsistência

66
Constraint
– Define restrições que são usadas para capturar erros críticos que invalidam o
modelo
– Gera um erro (error)
– São uma subclasse de Invariant, herdando suas características

67
Critique
– Define restrições usadas para capturar situações que não invalidam o modelo,
mas devem ser consideradas para melhorar sua qualidade
– Gera um aviso (warning)
– São uma subclasse de Invariant, herdando suas características

68
Pre | Post
– Contém declarações EOL que podem ser executadas antes (pre) ou após
(post) a avaliação das invariantes

69
Fases da execução de um módulo EVL:
Fase 1
– Executa a seção pre
Fase 2
– Para cada instância, a guarda (guard) e o contexto (context) são avaliados
– Se a guarda (guard) de uma invariante for satisfeita, o corpo (body) da invariante é
avaliada
– Caso o corpo seja avaliado como falso, a mensagem (message) definida,
juntamente com os consertos (fix) disponíveis, são adicionados à
ValidationTrace
Fase 3
– Examina a ValidationTrace por restrições não satisfeitas
– As mensagens são apresentadas
– O usuário pode selecionar um ou mais consertos (fix)
Fase 4
– Executa a seção post

70
Código: Exemplo de código EVL (Vieira, 2016).
‒ Verifica se um nome foi
definido para instâncias
da metaclasse Actuator
‒ Gera um erro (error)
‒ Só é avaliada se satisfizer
a restrição HasName
‒ Verifica se o nome inicia
com letra minúscula
‒ Oferece duas opções para
conserto (fix)
‒ Gera um aviso (warning)

71
O que é?
– Ferramenta da família Epsilon que gera automaticamente os modelos
GMFGraph, GMFTool e GMFMap, necessários para a implementação de
um editor GMF
Objetivo
– Diminuir a complexidade na criação de ferramentas de modelagem gráficas
com base no GMF
Funcionamento
– Utiliza um metamodelo Ecore anotado, escrito em linguagem Emfatic
– Anotações de alto nível
– Realiza transformações automatizadas com base nas anotações
Código Emfatic anotado Modelos necessários pelo GMF
Eugenia (1/10)

72
Categorias de anotações
– @gmf.diagram
– @gmf.node
– @gmf.link
– @gmf.compartment
– @gmf.affixed
– @gmf.label
Atributos
– Cada categoria de anotação suporta uma série de atributos
– Cada atributo deve ter um valor, dentro de uma lista de valores possíveis
Eugenia (2/10)

73
Eugenia (3/10)
Código: Exemplo de código Emfatic com anotações oferecidas pela Eugenia.

74
@gmf.diagram
– Especifica configurações do diagrama, tais como o tipo do elemento raiz do
modelo e a extensão do arquivo do editor gráfico
Eugenia (4/10)
Atributo Descrição Valores possíveis
diagram.extension A extensão do arquivo do diagrama Uma extensão de arquivo
model.extension A extensão do modelo do diagrama Uma extensão de arquivo
onefile Especifica que o modelo e o diagrama devem
ser salvos no mesmo arquivo
true, false

75
@gmf.node
– Indica quais elementos da sintaxe abstrata irão representar nós (vértices),
além da sua forma, cor, tamanho, rótulo, etc.
Eugenia (5/10)

label Valor mostrado como rótulo do nó Nome do atributo da classe
label.text Valor mostrado como rótulo do nó Texto a ser mostrado como rótulo
figure A figura que irá representar o nó
rectangle, ellipse, rounded
(padrão), svg, polygon ou classe Java
que implemente Figure
svg.uri
Endereço do arquivo SVG para representar a
figura do nó (quando figure="svg")
Uma extensão de arquivo

76
@gmf.link (para referência (EReference))
– Indica quais elementos da irão representar arestas, além de especificar sua
espessura, cor, estilo, tipo de pontas das setas, rótulos, etc.
Eugenia (6/10)
label ou label.text Valor mostrado como rótulo da aresta Texto a ser mostrado como rótulo
source.decoration Ilustração na origem da aresta
arrow, rhomb, filledrhomb, square,
filledsquare, closedarrow,
filledclosedarrow
target.decoration Ilustração no fim da aresta (como acima)

77
label Valor mostrado como rótulo da aresta Nome do atributo da classe
label.text Valor mostrado como rótulo da aresta Texto a ser mostrado como rótulo
source (obrigatório) Indica a origem da aresta EReference indicando a origem da aresta
target (obrigatório) Indica o destino da aresta EReference indicando o destino da aresta
source.decoration Ilustração na origem da aresta
arrow, rhomb, filledrhomb, square,
filledsquare, closedarrow,
filledclosedarrow
target.decoration Ilustração no fim da aresta (como acima)
@gmf.link (para classe (EClass))
– Indica quais elementos da irão representar arestas, além de especificar sua
espessura, cor, estilo, tipo de pontas das setas, rótulos, etc.
Eugenia (7/10)

78
@gmf.compartment
– Indica quais nós podem ser aninhados dentro de outros nós (e.g., atributos
são aninhados dentro das classes em um Diagrama de Classes da UML)
Eugenia (8/10)
collapsible Redimensionar ou não o compartimento true, false (padrão)
layout Layout do compartimento free (padrão), list

79
@gmf.affixed
– Indica quais nós devem estar anexos à borda de outros nós na sintaxe
gráfica
Eugenia (9/10)

80
@gmf.label (para atributo (EAttribute))
– Especifica rótulos adicionais para um nó na sintaxe gráfica
Eugenia (10/10)
label.text Valor mostrado como rótulo da aresta
Texto a ser mostrado como rótulo
quando o atributo não estiver definido
label.readOnly Indica se o valor do rótulo pode ser modificado true, false

81
Abowd, G. D., Dey, A. K., Brown, P. J., Davies, N., Smith, M., and Steggles, P. (1999). Towards a
better understanding of context and context-awareness. In Handheld and ubiquitous computing,
pages 304–307. Springer.
Chiprianov, V., Kermarrec, Y., Rouvrais, S., and Simonin, J. (2014). Extending enterprise
architecture modeling languages for domain specificity and collaboration: application to
telecommunication service design. Software & Systems Modeling, 13(3):963–974.
Cook, D. J. and Das, S. K. (2007). How smart are our environments? An updated look at the state of
the art. Pervasive and mobile computing, 3(2):53–73.
Crotty, M., Taylor, N., Williams, H., Frank, K., Roussaki, I., and Roddy, M. (2009). A Pervasive
Environment Based on Personal Self-improving Smart Spaces. In Gerhäuser, H., Hupp, J.,
Efstratiou, C., and Heppner, J., editors, Constructing Ambient Intelligence, volume 32 of
Communications in Computer and Information Science, pages 58–62. Springer Berlin
Heidelberg.
Dey, A. K. (2001). Understanding and using context. Personal and ubiquitous computing, 5(1):4–7.
Dolinar, K., Porekar, J., McKitterick, D., Roussaki, I., Kalatzis, N., Liampotis, N., Papaioannou, I.,
Papadopoulou, E., Burney, S. M., Frank, K., Hayden, P., and Walsh, A. (2008). PERSIST
Deliverable D3.1: Detailed Design for Personal Smart Spaces. http://www.ict-persist.eu/?q=
content/persist-deliverables-and-publications. [Online; acessado em Abril-2015].
Referências (1/4)

82
Gallacher, S. M., Papadopoulou, E., Taylor, N. K., and Williams, M. H. (2010). Putting the ‘Personal’
into Personal Smart Spaces. In Proceedings of Pervasive Personalisation Workshop, volume
2010, pages 10–17.
Kawsar, F. (2009). A document-based framework for user centric smart object systems. PhD in
Computer Science, Waseda University, Japan.
Kolovos, D. S., Paige, R. F., Kelly, T., and Polack, F. A. (2006). Requirements for domain-specific
languages. In Proceedings of the First ECOOP Workshop on Domain-Specific Program
Development.
Kolovos, D. S., García-Domínguez, A., Rose, L. M., and Paige, R. F. (2015a). Eugenia: towards
disciplined and automated development of gmf-based graphical model editors. Software &
Systems Modeling, pages 1–27.
Kortuem, G., Kawsar, F., Fitton, D., and Sundramoorthy, V. (2010). Smart objects as building blocks
for the internet of things. Internet Computing, IEEE, 14(1):44–51.
Lupiana, D., O’Driscoll, C., and Mtenzi, F. (2009). Taxonomy for ubiquitous computing environments.
In Networked Digital Technologies, 2009. NDT ’09. First International Conference on, pages
469–475.
Referências (2/4)

83
Roussaki, I., Kalatzis, N., Liampotis, N., Papaioannou, I., Pils, C., Crotty, M., AlanWalsh, Frank, K.,
Whitmore, J., McKitterick, D., Taylor, N., McBurney, S., Papadopoulou, E., Williams, H., Dolinar,
K., Porekar, J., Venezia, C., and Bucchiarone, A. (2008). PERSIST Deliverable D2.1: Scenario
Description and Requirements Specification. http://www.ict-persist.eu/?q=content/persist-
deliverables-and-publications. [Online; acessado em Abril-2015].
Schilit, B. N. and Theimer, M. M. (1994). Disseminating active map information to mobile hosts.
Network, IEEE, 8(5):22–32
Schmidt, D. C. (2006). Guest editor’s introduction: Model-driven engineering. Computer,
39(2):0025–31.
Seidewitz, E. (2003). What models mean. IEEE software, 20(5):26–32.
Siegemund, F. (2004). A context-aware communication platform for smart objects. In Pervasive
Computing, pages 69–86. Springer.
Taylor, N. (2011). Personal Smart Spaces. In Ferscha, A., editor, Pervasive Adaptation: The Next
Generation Pervasive Computing Research Agenda, pages 79–80. Institute for Pervasive
Computing, Johannes Kepler University Linz, Linz, AUS.
Van Deursen, A., Klint, P., and Visser, J. (2000). Domain-Specific Languages: An Annotated
Bibliography. Sigplan Notices, 35(6):26–36.
Referências (3/4)

84
Vieira, M. A. (2016). Modelagem de espaços inteligentes pessoais e espaços inteligentes fixos no
contexto de cenários de computação ubíqua. Master’s thesis, Universidade Federal de Goiás,
Goiânia, Goiás, Brazil.
Völter, M., Stahl, T., Bettin, J., Haase, A., and Helsen, S. (2013). Model-driven software
development: technology, engineering, management. John Wiley & Sons.
Weiser, M. and Brown, J. S. (1997). The coming age of calm technology. In Beyond calculation,
pages 75–85. Springer.
Referências (4/4)

85
→ Referência da Linguagem Emfatic
http://www.eclipse.org/epsilon/doc/articles/emfatic/
→ Tutorial Eugenia
https://www.eclipse.org/epsilon/doc/articles/eugenia-gmf-tutorial/
→ Documentação da Epsilon
http://www.eclipse.org/epsilon/doc/
→ Fórum da Epsilon
https://www.eclipse.org/forums/index.php/f/22/
→ KOLOVOS, Dimitrios S. et al. Eugenia: towards disciplined and automated
development of GMF-based graphical model editors. Software &
Systems Modeling, v. 16, n. 1, p. 229-255, 2017.
→ KOLOVOS, Dimitrios S. et al. The Epsilon Book. 2017.
Para saber mais...

86
Mãos à obra!
Agradecimentos:

87
Marcos Alves Vieira
Sérgio Teixeira de Carvalho
marcos.vieira@ifgoiano.edu.br
sergio@inf.ufg.br
17 de outubro de 2017
Engenharia Dirigida por Modelos no Desenvolvimento de
Aplicações Ubíquas:
Tecnologias, Ferramentas e Linguagens
Material de apoio:
http://bit.ly/webmedia2017

MDE Ferramentas Modelagem

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a MDE Ferramentas Modelagem

Semelhante a MDE Ferramentas Modelagem (20)

MDE Ferramentas Modelagem