Formalismos de Grafos de Interação

Formalismos de Grafos de Interação ( A Model-based Approach for developing 3D Users Interfaces - Juan Manuel Gonzalez Calleros) Disciplina:Tópicos em IHC II- Interação 3D Professor :Alberto Raposo

Tópicos Motivação - A Model-based Approach for developing 3D Users Interfaces - Research Motivation -Apresentação da Dissertação Model Driven Development MDD Research Goals Trabalhos relacionados ao paradigma MDD e aplicativos 3D. Referências

Dentre os diversos trabalhos apresentados na primeira fase (surveys), foi destacada a dissertação de Juan Manuel González Calleros (2006) que apresenta a utilização do paradigma de programação orientado à Modelo, na construção de 3DUI.

Research motivation Métodos existentes: Raramente provêem o desenvolvimento do design ; Estão mais focadas na implementação. Ausência de uma ferramenta de software, toolkit, para o desenvolvimento de 3DUI. Diferentes toolkits exitem para criar 2DUI, em contrapartida não há nada para a criação de 3DUI.

Apresentação da dissertação Complexidade; Extensão do tema / tempo disponível; Divisão em três blocos: - Capítulos I (Introduction) e II(State of Art); - Capítulos III( 3DUI Taxonomy) e IV(Model-Based development of 3DUI);e - Capítulos V (Case Studies), VI (Validation) e VII( Conclusion).

Engenharia de Software é consenso o ganho com: - Uso de modelos para projetar sistemas - Uso de padrões desde a análise até a implementação Descrições de uma solução com diferentes níveis de abstração.

Desenvolvimento Orientado ao Modelo (Model Driven Development - MDD) Todo o desenvolvimento a partir de modelos Departamento de Informática Programas gerados automaticamente a partir dos modelos Modelos são menos sensíveis à tecnologia e as suas evoluções Ampla utilização por várias organizações

Definições principais: MDA : é um framework de padrões estabelecido pela OMG (Object Management Group) para a modelagem de software. Um novo caminho para se especificar e construir sistemas baseados na UML, com suporte completo ao ciclo de vida de software: análise, projeto, implementação, distribuição, manutenção, evolução e integração com sistemas legados. Modelo : é a representação de uma parte de uma função, estrutura ou ambiente de um sistema.

Model Driven Architecture (MDA) MDD não é algo recente, mas ganhou notoriedade após o OMG lançar a especificação MDA, em 2001. Define conjunto de padrões que suportam MDD: Unified Modeling Language (UML) Meta-Object Facility (MOF) XML Metadata Interchange (XMI) Common Warehouse Meta-model (CWM)

Ciclo de vida de um processo tradicional Departamento de Informática

Para possibilitar a geração de um modelo específico para uma plataforma é utilizada a transformação, que funciona como uma caixa preta, transformando um modelo PIM em um modelo PSM. As ferramentas de transformação são especificadas para as plataformas desejadas através da utilização de OCL (Object Constraint Language) que garante a formalidade das regras através da UML.

ArcStyler 4.0 O ArcStyler 4.0 foi desenvolvido pela empresa Interactive Objects Software GmbH, sediada em Freiburg na Alemanha. Possui suporte às principais tecnologias de mercado possibilitando a modelagem de aplicações independentes de plataforma e posteriormente a geração dos códigos fontes específicos para uma plataforma. Entre as tecnologias suportadas para geração do PSM a partir do modelo PIM estão: J2EE Java 2 Enterprise Edition, exigindo o JDK 1.3 ou JDK 1.4 EJB Enterprise Java Beans Servlet 2.2 ou 2.3 Web Services exigindo Jakarta Tomcat 4.0 C# exigindo o.net Framework 1.0 ou superior, IDL CORBA.

OptimalJ 3.0 O OptimalJ 3.0 foi desenvolvido pela empresa Compuware Corporation. Destaca-se principalmente pela forte aplicação de padrões para J2EE (Java 2 Enterprise Edition) utilizando todos os conceitos de independência de plataforma que o MDA aborda. Dentre suas principais características se destacam os seguintes usos: Modelo de Domínio para Classes (Domain Class Model) utilizando os padrões da UML para modelagem de classes; Modelo de Domínio para Serviços (Domain Service Model) para modelagem de serviços; Modelo para Persistência de Dados (DAO,EJB) e ferramentas de integração com outras plataformas entre as quais estão CORBA, JCA(Java Connector Architecture) e Web services, entre outras.

Codagen Architect 3.2 O Codagen Architect 3.2 foi desenvolvido pela empresa Codagen Technologies Corp. em 1999, no Canadá. É membro da OMG possuindo parcerias com as principais empresas de software de mercado como Microsoft, IBM, Borland entre outras, nos esforços de implementação do MDA. Essencialmente é uma ferramenta de transformação divida em três módulos: Codagem Architect Implement, Codagem Architect Launch from XMI e Codagem Architect Specify. Estes módulos não possuem ambiente de modelagem, mas sim, ferramentas que importam os metamodelos das principais ferramentas de modelagem do mercado, através do uso XMI e a partir disso possibilita a geração dos PSM s para C++, J2EE e.net( C#, VB.NET, ADO.NET, ASP.NET).

O ciclo de vida do processo de MDA MDA define PIM, PSM e código e como eles estão relacionados. - Representam diferentes níveis de abstração. Passo mais complexo: PIM ==> PSMs

MDA x Processo tradicional Processo tradicional: transformação de modelos para códigos são feitas manualmente -Existem ferramentas que geram código a partir de modelos, mas geralmente geram apenas templates Em MDA todas as transformações são executadas por ferramentas

MDA x Processo tradicional (Vantagens) Produtividade embora o uso da arquitetura MDA implique na geração das regras de transformação entre os modelos PIM, PSM e de código, essa geração deve ser realizada apenas uma vez, para cada plataforma. Uma vez definidas as regras, as transformações se tornam automáticas, e apenas o modelo conceitual (PIM) deveria ser atualizado, enquanto que os demais modelos, inclusive a implementação, seriam automaticamente atualizados, reduzindo o tempo de desenvolvimento e aumentando a qualidade do artefato final. Portabilidade uma vez que o PIM é, por definição, independente de plataforma, o mesmo PIM pode ser transformado automaticamente para vários PSMs, específicos para as diferentes plataformas.

MDA x Processo tradicional (Vantagens) Interoperabilidade a interoperabilidade em MDA é alcançada através de bridges, que realizam a comunicação entre PSMs e códigos de diferentes plataformas. Para obter interoperabilidade as ferramentas de transformação devem gerar não só os PSMs, mas também as bridges entre eles. Manutenção e Documentação todo o trabalho de manutenção não é mais feito no código, mas sim no nível mais alto de abstração (o modelo PIM). Desta forma, a manutenção é facilitada e a documentação constantemente atualizada. E, no caso da manutenção ser realizada diretamente no PSM, deve ser possível atualizar automaticamente o PIM e manter os modelos consistentes.

MDA x Processo tradicional (Vantagens) O foco do desenvolvedor está no PIM; Apesar de ser necessário definir transformações, esta só é feita uma vez; Desenvolvedor não precisa se preocupar com detalhes de implementação; Menos código para ser escrito; Grande parte do código é gerada.

MDA x Processo tradicional O que há de novo? - Automação de PIM para PSM Exemplos: - Transformar um projeto em alto nível gerar um modelo de banco de dados. - A partir do mesmo modelo gerar um modelo de componentes COM ou um modelo de componentes EJB.

Exemplo Transformando um modelo PIM em UML para um modelo PSM para Java - Atributos públicos e privados Transformar atributos públicos em operações get-e-set. PIM: Todos os atributos são públicos,significando que o objeto tem uma propriedade específica, e que esta propriedade muda de valor ao longo do tempo.

Exemplo 1: atributos públicos e privados No PSM, uso de atributos públicos é considerado um projeto ruim. Melhor encapsular os atributos públicos. Todo os atributos são privados Todo acesso ao cliente é controlado por operações bem definidas

PIM e PSM provêem o nível certo de abstração para diferentes tipos de desenvolvedores e outros parceiros no desenvolvimento de software. Regras de transformação: - Para cada classe nomeada classname existe uma classe nomeada classname - Para cada atributo attributename : Type da classe classname do PIM criar na classe classname Um atributo privado com mesmo nome: attributename : Type Operação pública nomeada com o nome do atributo e prefixo get e retorno igual ao tipo do atributo: getattributename() :Type Operação pública nomeada com o nome do atributo e prefixo set, com o atributo como parâmetro e sem valor de retorno: setattributename( att: Type) É possível especificar regra reversa.

Exemplo 2: Associações -Transformar associações em algo que mapeie diretamente para a linguagem de programação.

Regras - Para cada final de associação existe um atributo privado com o mesmo nome que a classe oposta. - O tipo do atributo é a classe do final da associação se a múltiplicidade é 0 ou 1, ou o tipo é um Set se a multiplicidade é maior do que 1. - O atributo criado terá operações get e set correspondentes, seguindo as mesmas regras que os outros atributos. - Para associações com direção definidas, executar as regras acima apenas para aquelas com setas apontando.

Model Driven Architecture (MDA) - Envolve um grande número de ferramentas e tecnologias. - Diferentes tarefas: Elaboração de modelo Simulação de modelo Validação de modelo Geração de código...

Model Driven Architecture (MDA) - Várias questões em aberto em relação as ferramentas e tecnologias que suportam MDA. - Não está totalmente maduro, para obter benefícios na sua totalidade, todas as transformações entre modelos devem ser automatizadas, o que o atual estado da tecnologia ainda não permite plenamente.

Model Driven Architecture (MDA) -Ferramentas disponíveis atualmente não suportam toda a especificação MDA. -Entretanto, MDA é flexível a ponto de permitir que uma ferramenta transforme um PIM diretamente em código, sem produzir um PSM.

Requisitos Modelagem Empregando MDA - Modelo deve estar conectado ao software sendo desenvolvido - Modelagem incremental - Código gerado deve ser rápido e compacto - Possibilidade de unificar modelos - Possibilidade de comparar modelos Departamento de Informática - Integração de novos sistemas com sistemas legados

Prover ao desenvolvedor a oportunidade de descrever uma 3DUI em uma linguagem baseada em XML, UsiXML. Ajudar o desenvolvedor à criar uma 3DUI em um editor gráfico ou usando como ponto de partida uma descrição de um arquivo UsiXML. Prover ao desenvolvedor um conjunto de widgets pré-definidas que o ajude a criar a UI. Testar a usabilidade e a acessibilidade de realidades virtuais, em diferentes contextos, contra a validação empírica de diretrizes e regras de design.

Related work 3D UIs generation Departamento de Informática Programmatic approach: OpenGL, Direct3D, C++, MCNL, VRML, X3D, Toolkit programming: Maya, Max3D, Crazy Eddie's GUI System, Anark, Alice Render engines: Microsoft task gallery, infinite 3D Cube, Sphere XP, looking glass, Clara browser, 3DNA Model based: ontoweb (VR-Wise), ConGenIVE (VRIXML), InTML, Contigra

Related work Programmatic Approach, VRML

Características Departamento de Informática VRML é uma linguagem independente de plataforma Permite animação, movimentos de corpos e iteração entre usuários Atualmente é o padrão para desenvolvimento de aplicações RV na rede

Sobre a linguagem VRML é baseada no Open Inventor Departamento de Informática Objetos podem receber atributos como cor, textura e mapeamento, transparência, brilho, deformação, translações e rotações. A linguagem VRML têm a capacidade de representar mundos e objetos tridimensionais formados através de primitivas geométricas

Vantagens Departamento de Informática Permite que um mundo virtual possa ser construído por objetos pré definidos em arquivos separados VRML é interpretada

Related work Toolkit Approach, Anark

Características Departamento de Informática Indicado para criação de conteúdos interativos 3D. É possível adicionar animações. Utiliza Lua como linguagem de script.

Related work Render Engines, 3DNA

Características Departamento de Informática 3DNA Desktop tem como idéia central melhorar a forma de trabalho nos ambientes Windows e na Web. Possibilita formas mais fáceis de organização de arquivos, pastas e atalhos através de paredes e gavetas. Permite a navegação simultânea em diversos websites.

Related work Model-based approach, CoGenIVE-VRIXML Departamento de Informática <GroupItem > <UISlider paramid ="10"> <Value min ="0" max="255"/> <Tickstyle orientation =" horizontal position =" both " frequency ="16"/> </ UISlider > <Position > <X>1.0 </X><Y>1.5 </Y> </ Position > </ GroupItem >

Características Departamento de Informática Utiliza a orientação à modelos. Comporta vários periféricos de input/output. Mapeia o proceso de engenharia reversa, ou seja, qualquer modificação na FUI é também feita nos respectivos modelos abstratos.

Conclusões Departamento de Informática Programming approach: -Permite a implementação direta da FUI. Em termos de critério de qualidade, varia em relação ao grau de consumo de recursos( tempo, dinheiro, linhas de código, etc) e a facilidade de uso. -As linguagens utilizadas são extremamente relacionadas à metodologia e aos conceitos de representação. -Não há um critério de mensuração a ser considerado. -Os resultados são dependentes da experiência do programador ou do contexto de dsenvolvimento. -Não existe um canal de comunicação entre o desenvolvedor e o usuário final. -Programação em si não comporta a engenharia de construção de uma 3DUI.

Conclusões Toolkit approach: -Permite a implementação direta da FUI. Neste caso, utiliza um conjunto pré-definido de objetos que ajudam o desenvolvedor na sua tarefa de programação. -Em alguns casos, um toolkit pode ser parte do processo de engenharia.

Conclusões Rendering engines: -Permitem a visualização das linguagens de programação 3D. -É apenas um requisito complementar, mas não faz parte do processo da engenharia de uma 3DUI.

FIM Capítulos I (Introduction) e II(State of Art);