dyynn aammiicc rttarrggeett uusseer...

Departamento de Engenharia Informática e de Sistemas

DDyynnaammiicc TTaarrggeett UUsseerr IInntteerrffaaccee Dissertação apresentada para a obtenção do grau de Mestre em

Informática e Sistemas

Autor

Paulo Ventura

Orientadores

Prof. Doutor Jorge Barbosa (ISEC) Prof. Doutora Ana Rosa (ISEC)

Eng.º Telmo Pereira (Meticube) Instituto Superior de Engenharia de Coimbra

Coimbra, Dezembro, 2011

Dynamic Target User Interface Agradecimentos

Paulo Jorge Agreira Ventura i

Agradecimentos

Queria começar por agradecer aos meus pais, irmãos, namorada e amigos por todas as

palavras de incentivo e apoio demonstradas em todos os momentos desta fase, especialmente

nos momentos mais dúbios.

Aos meus orientadores de estágio do DEIS/ISEC, o Prof. Doutor. Jorge Barbosa e à Prof.

Doutora Ana Rosa por todo apoio e atenção dispensados.

Gostaria também de agradecer ao meu orientador de estágio na empresa Meticube, o Eng.º

Telmo Pereira pela disponibilidade e orientações prestadas, assim como, pelas suas sugestões

que levaram a um maior enriquecimento do Projecto.

Um agradecimento também ao Eng.º Bruno Rosa por toda a ajuda prestada, pela

disponibilidade e paciência, especialmente nas questões relacionadas com o UCH.

Um muito obrigado ao Eng.º Jürgen Bund por ter proporcionado o corrente estágio e a todos

os colegas de trabalho da Meticube que sempre se mostraram disponíveis para ajudar no que

fosse preciso.

Queria também agradecer e enaltecer o ambiente de trabalho fantástico e sempre bem-

disposto da empresa durante todos estes meses de estágio.

Paulo Ventura

Dynamic Target User Interface Resumo

Paulo Jorge Agreira Ventura iii

Resumo

O presente estágio curricular insere-se no âmbito da disciplina de “Estágio”, pertencente ao

Mestrado em Informática e Sistemas na área de especialização em Desenvolvimento de

Software do Instituto Superior de Engenharia de Coimbra, tendo decorrido na empresa

Meticube Lda, em Taveiro.

O objectivo do presente estágio teve no seu cerne a criação/geração dinâmica de interfaces de

utilizador de forma a possibilitar o controlo de dispositivos como televisões, ar

condicionados, rádios, entre outros, com base no UCH – Universal Control Hub. A criação de

cada interface de utilizador é baseada na conversão (Parse) de um ficheiro designado por

Socket Description que identifica as operações e estados internos de um dispositivo (Target)

existente no UCH, por cada Target. O presente projecto encontra-se também integrado com a

framework ON.IT, o que levou ao seu desenvolvimento ser baseado em Plugins (aplicações

integradas de forma independente na framework ON.IT de forma a ampliar/estender as suas

funcionalidades), o que permite a sua integração em qualquer outro projecto que tenha por

base a framework ON.IT, como é o caso do UCH Workbench desenvolvido no âmbito do

projecto URC4ALL – Universal Remote Console For All.

Palavras-Chave

“ON.IT”, “Socket Description Elements”, “Socket Description”, “Target Adapter”, “UCH

Workbench”, “Universal Control Hub”, “Universal Remote Console”, “User Interface Socket

Description”, “User Interface Socket Layer”, “ISO/IEC 24752”

Dynamic Target User Interface Abstract

Paulo Jorge Agreira Ventura v

Abstract

The current traineeship is within the scope of the “Estágio” Course of the Software

Development Specialization of Master Informatics and Systems in the Coimbra Institute of

Engineering, having passed on the Meticube Company in Taveiro.

The purpose of this stage is the creation / dynamic generation of user interfaces in order to

allow the monitoring of devices such as televisions, air conditioners, radios, among others,

based on UCH - Universal Control Hub. The creation of each user interface is based on the

parsing of the Socket Description file. This file identifies the operations and internal states of

a device (Target) that exist in the UCH for each Target. This project is also integrated with

ON.IT framework, because its development is based on Plugins (independently integrated

applications in order to expand/extend the ON.IT functionalities), allowing integration of this

project inside any other project based on ON.IT framework, like UCH Workbench developed

under the project URC4ALL - Universal Remote Console For All.

Keywords

“ON.IT”, “Socket Description Elements”, “Socket Description”, “Target Adapter”, “UCH

Workbench”, “Universal Control Hub”, “Universal Remote Console”, “User Interface Socket

Description”, “User Interface Socket Layer”, “ISO/IEC 24752”

Dynamic Target User Interface Índice

Paulo Jorge Agreira Ventura vii

Índice

CAPÍTULO 1 INTRODUÇÃO ............................................................................................................................ 1

1.1. Âmbito do Estágio ................................................................................................................................ 2

1.2. Objectivos e Motivação ........................................................................................................................ 2

1.3. Empresa ................................................................................................................................................ 3

1.4. Estrutura do Relatório .......................................................................................................................... 4

1.4.1. Capítulo 1 – Introdução ................................................................................................................... 4

1.4.2. Capítulo 2 – Estado da Arte ............................................................................................................. 4

1.4.3. Capítulo 3 – Planeamento e Gestão do Projecto .............................................................................. 4

1.4.4. Capítulo 4 – Análise e Desenvolvimento ........................................................................................ 4

1.4.5. Capítulo 5 – Trabalho Futuro .......................................................................................................... 4

1.4.6. Capítulo 6 – Conclusões .................................................................................................................. 4

1.4.7. Anexos ............................................................................................................................................. 5

1.4.7.1. Anexo A – Documentação Técnica da framework ON.IT em Português .............................. 5

1.4.7.2. Anexo B – Documentação Técnica da framework ON.IT em Inglês ..................................... 5

1.4.7.3. Anexo C – Documentação Técnica do Projecto ..................................................................... 5

1.4.7.4. Anexo D – Plano de Testes .................................................................................................... 5

1.4.7.5. Anexo E – Resultado do Plano de Testes ............................................................................... 5

1.4.7.6. Anexo F – Modelo de Dados ................................................................................................. 5

1.4.7.7. Anexo G – Manual de Utilizador ........................................................................................... 6

1.4.7.8. Anexo H – Relatórios Quinzenais .......................................................................................... 6

1.4.7.9. Anexo I – Código Fonte do Projecto ...................................................................................... 6

1.4.7.10. Anexo J – Código Fonte da Câmara de Vídeo integrada com ON.IT e UCH ........................ 6

1.4.7.11. Anexo K – Testes Unitários ................................................................................................... 6

1.4.7.12. Anexo L – Vídeo de Marketing ............................................................................................. 6

1.5. Tecnologia URC/UCH ......................................................................................................................... 6

1.6. ON.IT ................................................................................................................................................... 8

1.7. ISO/IEC 24752 ................................................................................................................................... 10

1.8. URC4ALL .......................................................................................................................................... 10

1.9. UCH Workbench ................................................................................................................................ 11

1.10. SEFA .................................................................................................................................................. 11

1.11. Dynamic Target User Interface .......................................................................................................... 11

CAPÍTULO 2 ESTADO DA ARTE ................................................................................................................... 13

CAPÍTULO 3 PLANEAMENTO E GESTÃO DO PROJECTO .................................................................... 15

3.1. Equipa ................................................................................................................................................ 15

3.2. Metodologia ....................................................................................................................................... 16

3.3. Coordenação e reuniões ...................................................................................................................... 17


viii

3.4. Calendarização.................................................................................................................................... 17

CAPÍTULO 4 ANÁLISE E DESENVOLVIMENTO ....................................................................................... 21

4.1. Definição do problema ....................................................................................................................... 21

4.2. Estudo ON.IT...................................................................................................................................... 23

4.1.1. Arquitectura de Blocos .................................................................................................................. 24

4.1.1.1. Concrete IPluginHost (FrmMain) ......................................................................................... 25

4.1.1.2. Association Manager ............................................................................................................ 25

4.1.1.3. Plugin Sandbox (IPlugin) ..................................................................................................... 26

4.1.1.4. WatchDog Server ................................................................................................................. 27

4.1.1.5. WSLookatit2009 .................................................................................................................. 27

4.2. Estudo Tecnologia URC/UCH ........................................................................................................... 27

4.3. Estudo Standard ISO/IEC 24752 ........................................................................................................ 30

4.3.1. Set .................................................................................................................................................. 31

4.3.2. Variable .......................................................................................................................................... 31

4.3.3. Constant ......................................................................................................................................... 32

4.3.4. Command ....................................................................................................................................... 33

4.3.5. Notification .................................................................................................................................... 34

4.4. Preparação do Trabalho do Projecto ................................................................................................... 35

4.4.1. ON.IT ............................................................................................................................................. 35

4.4.2. UCH ............................................................................................................................................... 35

4.4.3. UCH Integrado no ON.IT .............................................................................................................. 35

4.5. Dynamic Target User Interface........................................................................................................... 36

4.5.1. Requisitos ...................................................................................................................................... 36

4.5.1.1. Plugin Target Discovery ....................................................................................................... 37

4.5.1.2. Plugin Dynamic Target ........................................................................................................ 37

4.5.1.3. Casos de Uso ........................................................................................................................ 39

4.5.1.4. Actores ................................................................................................................................. 39



4.5.2. Diagramas de Contexto .................................................................................................................. 43

4.5.3. Diagramas de Sequência ................................................................................................................ 43

UC 102: Criar Plugins Dynamic Target .................................................................................................. 44

UC 201: Criar Plugin Dynamic Target .................................................................................................... 45

UC 203: Parse Socket Description em componentes/user controls ......................................................... 46

UC 206: Processar actualizações de valores oriundos do UCH .............................................................. 47

4.5.4. Diagrama Classes ........................................................................................................................... 48




Paulo Jorge Agreira Ventura ix

4.5.5. Plano de Testes .............................................................................................................................. 52

4.6. Aspectos relevantes da implementação .............................................................................................. 52

4.6.1. Plugins Target Discovery e Dynamic Target ................................................................................. 52

4.6.2. Arquitectura dos Plugins ............................................................................................................... 53

4.6.3. Princípios de Representação de um Target .................................................................................... 53

4.6.4. Representação Socket Elements (Componentes) ........................................................................... 54

4.6.5. Parsing Socket Description ............................................................................................................ 54

4.6.6. Parsing Socket Description em Componentes ............................................................................... 55

4.6.7. Componentes em memória ............................................................................................................ 59

4.6.8. Arquitectura dos Componentes ...................................................................................................... 59

4.6.8.1. IMyComponent .................................................................................................................... 60

4.6.8.2. IScrollPanel .......................................................................................................................... 60

4.6.8.3. ISet ....................................................................................................................................... 60

4.6.8.4. IGenericDimension .............................................................................................................. 60

4.6.8.5. IDimensionGrid ................................................................................................................... 61

4.6.9. Serialização .................................................................................................................................... 62

4.6.10. Comunicação com o UCH ........................................................................................................ 64

4.6.11. Processamento de dependências ............................................................................................... 64

4.6.12. Ordenação dos Componentes .................................................................................................... 67

4.6.13. Modo de Edição ........................................................................................................................ 68

4.6.14. Trocar de posição do componente ............................................................................................ 71

4.6.15. Receber Valores do UCH.......................................................................................................... 71

4.6.16. Problema Cross-thread operation .............................................................................................. 72

4.6.17. Aspecto gráfico Plugins e Componentes .................................................................................. 74

4.6.18. Testes Unitários ........................................................................................................................ 81

4.6.19. Testes Funcionais ...................................................................................................................... 84

4.7. Actividades Extra ............................................................................................................................... 86

4.7.1. Relatórios Quinzenais .................................................................................................................... 86

4.7.2. Apresentações Internas .................................................................................................................. 86

4.7.3. Criação de Vídeo de Marketing ..................................................................................................... 86

CAPÍTULO 5 TRABALHO FUTURO ............................................................................................................ 87

5.1. Detectar Alterações na Socket Description ........................................................................................ 87

5.2. Integrar o UCH Cascading ................................................................................................................. 88

5.3. Integrar com Socket Description Editor ............................................................................................. 88

5.4. Alteração ao Standard ........................................................................................................................ 89

5.5. Alterar Tamanho de um Componente ................................................................................................ 89

5.6. Adicionar Novos Componentes .......................................................................................................... 90

5.7. Interface Web ..................................................................................................................................... 90


x

5.8. Associações ........................................................................................................................................ 90

CAPÍTULO 6 CONCLUSÕES ........................................................................................................................... 91

REFERÊNCIAS ................................................................................................................................................... 93

ANEXOS............................................................................................................................................................... 95

Dynamic Target User Interface Índice de Figuras

Paulo Jorge Agreira Ventura xi

Índice de Figuras

Figura 1 – Diagrama Conceptual UCH ................................................................................................................... 7

Figura 2 - ON.IT ...................................................................................................................................................... 9

Figura 3 – Metodologia Iconix .............................................................................................................................. 16

Figura 4 – Diagrama de Gantt Planeamento inicial ............................................................................................... 18

Figura 5 – Diagrama de Gantt Final ...................................................................................................................... 19

Figura 6 - Exemplo de Componentes gerados através da Socket Description ....................................................... 23

Figura 7- Diagrama Contexto ON.IT .................................................................................................................... 24

Figura 8. Arquitectura do UCH ............................................................................................................................. 28

Figura 9. Interacção/comunicação entre componentes do UCH em run-time ....................................................... 29

Figura 10 – Exemplo de um Set Element............................................................................................................... 31

Figura 11 – Exemplo de um Variable Element ..................................................................................................... 32

Figura 12 – Exemplo de um Constant Element ..................................................................................................... 32

Figura 13 – Exemplo de um Command Element ................................................................................................... 33

Figura 14 – Exemplo de um Notify Element .......................................................................................................... 34

Figura 15 - Plugin Câmara de Vídeo Axis 221 + UCH ......................................................................................... 36

Figura 16 – Actores ............................................................................................................................................... 39

Figura 17 - Diagrama dos Casos de Uso do Plugin Target Discovery .................................................................. 40

Figura 18 - Diagrama dos Casos de Uso do Plugin Dynamic Target .................................................................... 41

Figura 19 – Diagrama de Contexto Dynamic Target User Interface ..................................................................... 43

Figura 20 – Diagrama de Sequência Criar Plugins Dynamic Target ..................................................................... 44

Figura 21 – Diagrama de Sequência Criar Plugin Dynamic Target ...................................................................... 45

Figura 22 – Diagrama de Sequência Parse Socket Description em componentes/user controls ............................ 46

Figura 23 – Diagrama de Sequência Processar actualizações de valores oriundos do UCH ................................. 47

Figura 24 – Diagrama de Classes do Plugin Target Discovery ............................................................................. 49

Figura 25 – Diagrama de Classes do Plugin Dynamic Target (namespace Meticube.UCH.DynamicTarget) ....... 50

Figura 26 – Diagrama de Classes do Plugin Dynamic Target (namespace Meticube.UCH.DynamicTarget.

Target.UI.MyComponents) ................................................................................................................................... 51

Figura 27 – Parse da Socket Description em Componentes .................................................................................. 55

Dynamic Target User Interface Índice de Figuras

xii

Figura 28 – Excerto de código para efectuar o Parse para componentes ............................................................... 58

Figura 29 – Representação de componentes em árvore ......................................................................................... 59

Figura 30 – Conceito IGenericDimension ............................................................................................................. 61

Figura 31 – Conceito DimensionGrid .................................................................................................................... 61

Figura 32 – Excerto de Código de serialização estática da propriedade de um componente ................................. 62

Figura 33 – Excerto de Código para desserializar um componente ....................................................................... 63

Figura 34 – Excerto de Código para desserializar as propriedades de um componente ........................................ 63

Figura 35 – Excerto de Código que para manter estado interno de um Target no Plugin Dynamic Target .......... 65

Figura 36 – Excerto de Código que validar o input de uma variável ..................................................................... 66

Figura 37 – Validação Input Componente ............................................................................................................. 66

Figura 38 – Excerto de Código avaliar uma dependência do tipo WRITE ............................................................ 67

Figura 39 – Excerto de Código avaliar uma dependência do tipo RELEVANT.................................................... 67

Figura 40 – Organização Espacial Componentes .................................................................................................. 68

Figura 41 – Exemplo modo de edição ................................................................................................................... 69

Figura 42 – Excerto de Código para instanciação de Componentes ...................................................................... 70

Figura 43 – Excerto de Código para evitar Cross-thread operation ....................................................................... 73

Figura 44 – Target Discovery Plugin ..................................................................................................................... 74

Figura 45 – Dynamic Target para o Target Generic Target Chain AC Dummy .................................................... 75

Figura 46 – User Interface gerada no Plugin Dynamic Target para o Target Generic Target Chain AC Dummy 76

Figura 47 – User Interface em Modo de Edição .................................................................................................... 77

Figura 48 – Componente na Slot ........................................................................................................................... 78

Figura 49 – Resultados Testes Unitários ............................................................................................................... 82

Figura 50 – Excerto de um Teste Unitário ............................................................................................................. 83

Dynamic Target User Interface Índice de Tabelas

Paulo Jorge Agreira Ventura xiii

Índice de Tabelas

Tabela 1 - Equipa projecto URC4ALL .................................................................................................................. 16

Tabela 2 – Requisitos do Plugin Target Discovery ............................................................................................... 37

Tabela 3 – Requisitos do Plugin Dynamic Target ................................................................................................. 38

Tabela 4 – Actores dos Casos de Uso .................................................................................................................... 39

Tabela 5 - Casos de Uso do Plugin Target Discovery ........................................................................................... 40

Tabela 6 - Casos de Uso do Plugin Dynamic Target ............................................................................................. 42

Tabela 7 – Regras de Parse dos Socket Elements em componentes ...................................................................... 56

Tabela 8 – Componentes por defeito analisando o tipo XSD ................................................................................ 57

Tabela 9 – Lista de Componentes Disponíveis ...................................................................................................... 81

Tabela 10 – Resultado Plano de Testes ................................................................................................................. 86

Dynamic Target User Interface Termos e Acrónimos

Paulo Jorge Agreira Ventura xv

Termos e Acrónimos

Available Objects – zona da framework ON.IT onde se encontram os Plugins disponíveis para

utilização. Os Plugins apenas se encontram em execução quando se encontrem na Tree View.

Command (comando) – representa uma operação que um utilizador pode mandar executar

para realizar tarefas que não possam ser realizadas através da manipulação de simples

variáveis (alteração de um valor). Um comando utiliza-se para efectuar acções/operações,

como por exemplo, abrir um portão, acender uma lâmpada, submeter um formulário.

Command Parameter (parâmetro de um comando) – representa um valor usado na invocação

de um Command. A titulo de exemplo, imaginando um conjunto de lâmpadas e um comando

que efectue a acção “acender lâmpada”, teria de se especificar qual a lâmpada a ligar, neste

caso, ao invocar o comando tem de existir um parâmetro de entrada que identifique a lâmpada

que se quer ligar.

Componente – consiste num User Control, definido para poder representar graficamente um

elemento da Socket Description, e para efectuar operações sobre esse elemento (por exemplo,

representar um comando e permitir a invocação desse comando através do ambiente gráfico).

Constant – representa um valor fixo ou uma constante definida na Socket Description.

Control (Controlo) – representa um controlo em C# Windows Forms.

Controller (Controlador) – ferramenta que disponibiliza uma interface de forma a controlar

um dispositivo (Target).

Dependências – representam expressões XPath 2.0 que representam condições particulares,

que necessitam de ser avaliadas em determinadas situações. Representam condições para que

determinada acção/operação possa ser executada.

Exemplo: considerando uma televisão, apenas faz sentido ter uma opção (comando) para

mudar de canal, quando a televisão estiver ligada (estado ON), na definição de um comando

(Command) pode-se definir uma dependência que avalie o estado da televisão e que apenas

permita que o botão esteja activo quando o seu estado for ON. Estas condições podem ser

representadas por expressões XPath, que serão processadas para avaliar o resultado.

Desserializar – consiste no processo inverso ao da serialização. Este processo utiliza-se de

forma a carregar para memória (na forma de objectos) os componentes serializados. No


xvi

presente contexto, consiste no processamento de dados XML (contendo as definições dos

vários componentes de um Target), de forma a carregar os componentes para memória e

representa-los graficamente, mantendo os componentes tal como existiram num estado

anterior.

Dimensão – representa um Socket Element com representação semelhante a uma tabela ou um

array.

Exemplo: considerando uma habitação, poder-se-ia definir um Socket Element do tipo

Command, de forma a abrir uma porta, podendo invocar e aceder ao estado do elemento da

seguinte forma: “/Abrir[portaEntrada]” ou “/Abrir[garagem]”, conseguindo assim, com um só

elemento controlar e saber o estado da porta de entrada e da garagem. Caso o Command fosse

definido para ter duas dimensões poder-se-ia definir por exemplo

“/Abrir[portaEntrada][piso1]” ou “/Abrir[garagem][piso0]”.

DLL – abreviatura para dynamic-link library.

Enumeração – representa uma lista de valores válidos aplicada ao tipo de dados de um

elemento dentro da Socket Description, de forma a restringir os valores que pode conter.

Exemplo: definir para uma variável os valores ON, OFF e Standby de forma a representar o

estado de uma televisão.

Notify (Notificação) – representa uma notificação de um Target, o normal funcionamento do

mesmo é afectado. Um elemento deste tipo pode representar por exemplo, um alerta

(notificação) de incêndio.

ON.IT – framework de desenvolvimento poderosa que permite o rápido desenvolvimento de

um sistema de gestão centralizado. Consiste numa ferramenta que permite a fácil integração

de qualquer tipo de equipamentos e sistemas numa única aplicação através da utilização de

Plugins (programas de software standalone que permitem estender as capacidades de outro,

neste caso estendem as capacidades do ON.IT).

P.e. – Abreviatura de “por exemplo”.

Parsing – consoante o contexto pode ter um de dois significados:

1. Forma de analisar e extrair informação de um ficheiro XML e converte-lo numa estrutura de

dados em memória chamada de Socket Instance.

2. Forma de analisar e extrair informação de uma Socket Instance e converte-la em componentes.


Paulo Jorge Agreira Ventura xvii

Path (caminho) – forma de endereçar os Socket Elements dentro da Socket Instance, assim

como endereçar os componentes dentro do Plugin Dynamic Target.

Plugin – Mini-aplicação standalone sem restrições e com capacidades virtualmente ilimitadas

que funciona dentro da framework ON.IT, possui o propósito de estender/ampliar as

funcionalidades disponibilizadas pela framework.

SD – Abreviatura para Socket Description.

Serializar – Consiste numa técnica de persistência de objectos/dados, sendo utilizada no

presente contexto para guardar os componentes de um Target na forma de XML, visto que os

componentes apenas se encontravam armazenados numa estrutura de dados em memória. Esta

técnica permite posteriormente utilizar a desserialização, de modo a “recriar” os componentes

na forma em que existiam anteriormente, isto porque no XML é guardada informação sobre

os componentes, como por exemplo, o seu tamanho e localização.

Set – representa um grupo de Socket Elements, incluindo outros Set.

Slot – Representa a área dentro do ON.IT para onde podem ser arrastados os Plugins em

execução de forma a terem uma representação central, normalmente usada para o utilizador

ter imediatamente a percepção (sem seleccionar o Plugin) do estado de uma ou mais

funcionalidades de um Plugin.

Socket Description – abreviatura para User Interface Socket Description. Representa um

ficheiro XML estruturado de acordo com a norma ISO 24752-2, contém as operações,

funcionalidades e estados que um dispositivo ou serviço (Target) pode conter, nomeadamente

as definições das suas variáveis, comandos e outros Socket Elements. Será este ficheiro a base

para a representação gráfica (User Interface) de um Target.

Socket Element – pode representar o tipo variável (Variable), comando (Command), grupo

(Set), notificação (Notify) e constante (Constant), como definido na norma ISO 24752-2.

Socket Instance – representação em memória da User Interface Socket, armazena toda a

informação extraída de uma Socket Description, assim como possui os métodos necessários

para a manipular.

State (estado) – representa o estado de execução de um Command (comando), este pode

conter os seguintes estados: initial, rejected, inProgress, done, succeeded, failed.


xviii

Target – designação de um serviço ou dispositivo a controlar. Pode consistir num simples

dispositivo, como por exemplo um interruptor, um termóstato, um dispositivo de registo de

energia (Smart Meter), assim como dispositivos complexos como aparelhos domésticos,

dispositivos audiovisuais, dispositivos electrónicos, dispositivos Web-based (twitter,

skype…), assim como quaisquer outros serviços que possam ser controlados remotamente.

Tree View – zona da framework ON.IT que contém os Plugins em execução. Cada item na

zona Tree View representa um Plugin em execução.

UCH – abreviatura para Universal Control Hub.

URC – abreviatura para Universal Remote Console.

User Control – representa um controlo (Control) personalizado. Combina numa unidade

lógica vários controlos, como por exemplo múltiplas caixas de texto. Desta forma, usando

apenas um User Control consegue-se representar vários controlos num só. Um componente

representa um User Control que pode ter vários User Control dentro de si.

User Interface (interface de utilizador) – consiste no GUI (Graphical User Interface) da

aplicação. Consiste nos componentes gráficos da aplicação, como botões e caixas de texto. O

aglomerado destes componentes representa a interface de utilizador.

Variable – representa um valor variável presente no Target.

XPath (XML Path Language) – linguagem de expressão usada para endereçar parcelas de um

documento XML ou para processar valores (strings, números ou booleanos) baseando-se no

conteúdo de um documento XML.

XML Schema – descreve a estrutura interna a que um documento XML tem de obedecer.

XSD – abreviatura para XML Schema Definition file.

Dynamic Target User Interface

Paulo Jorge Agreira Ventura 1

Capítulo 1

Introdução

O presente documento tem como finalidade a apresentação do trabalho realizado ao longo do

estágio curricular decorrido na empresa Meticube. O objectivo principal do estágio consistiu

no desenvolvimento do projecto Dynamic Target User Interface. Este projecto visa a

integração da framework ON.IT (que permite o rápido desenvolvimento de aplicações e de

um sistema de gestão centralizado) com a framework/tecnologia UCH – Universal Control

Hub (que possibilita o controlo de um qualquer dispositivo ou serviço, sendo exemplo de um

dispositivo uma televisão e de um serviço o Skype). Esta integração consiste no

desenvolvimento de Plugins (aplicações standalone que permitem estender as

funcionalidades/capacidades do ON.IT), de forma a ser possível controlar um qualquer

dispositivo (p.e. uma televisão) através do UCH, sendo este controlo efectuado recorrendo a

uma interface de utilizador gerada dinamicamente para o dispositivo em causa. Além de

permitir o controlo do dispositivo, esta interface de utilizador tem também de permitir a

representação dos seus estados internos (p.e. o estado ligado/desligado).

Desta forma, com o presente documento serão fornecidos os detalhes referentes às

tecnologias, frameworks e standards utilizados durante o desenvolvimento do projecto.

O facto de o projecto ser baseado na framework ON.IT permite utilizar a aplicação (Plugins

desenvolvidos) de uma forma transparente, simples e rápida em qualquer outro projecto que

tenha como base a framework ON.IT.

Como a tecnologia UCH é relativamente recente ainda existem poucas ferramentas para

interagir com ela, apesar de o UCH actualmente ter vindo a ganhar cada vez mais adeptos a

nível europeu e mundial, sendo exemplos da sua utilização os projectos Brainable[1]

e

i2home[2]

. O projecto Dynamic Target User Interface pode dar um grande contributo na UCH

Workbench (projecto em desenvolvimento que agrega um conjunto de ferramentas para

“desenvolver” para UCH), visto que permite a criação automática de uma interface de

utilizador para controlar um Target (dispositivo), podendo também contribuir com uma

grande ajuda no que diz respeito aos testes dos Targets e Socket Descriptions criadas, pois


2

apenas existe um gerador dinâmico de interfaces, mas muito básico e que na maioria dos

casos tem que ser personalizado manualmente (programaticamente).

Em projectos para clientes finais, como o projecto SEFA (projecto que pretende medir,

monitorizar e efectuar o controlo básico de equipamentos eléctricos num ambiente domestico)

esta geração dinâmica de interfaces de utilizador permite uma maior flexibilidade de

utilização e personalização de um Target (dispositivo) por parte de um utilizador final, sem

este ter de conhecer os standards envolventes.

1.1. Âmbito do Estágio

O presente estágio foi realizado no âmbito das disciplinas de Estágio, decorrentes no último

ano do Mestrado em Informática e Sistemas, na Especialização de Desenvolvimento de

Software, no Instituto Superior de Engenharia de Coimbra, ISEC.

O estágio decorreu entre 22 de Novembro de 2010 e 15 de Julho de 2011, na empresa

Meticube (http://www.meticube.com), localizada no centro de empresas de Taveiro.

O estagiário teve como seus orientadores o Prof. Doutor Jorge Barbosa e a Prof. Doutora Ana

Rosa pelo Departamento de Informática e Sistemas do ISEC e o Eng.º Telmo Pereira pela

Meticube.

1.2. Objectivos e Motivação

Inicialmente o presente estágio encontrava-se no âmbito do projecto SEFA - Smart Energy

For All, tinha como finalidade a expansão de um protótipo, de forma a ser possível controlar

um Smart Meter[19]

através de um UCH em conjunto com uma framework proprietária

designada por ON.IT, com o intuito de permitir uma gestão flexível e inteligente do consumo

de energia, dentro de uma infra-estrutura, como uma casa ou um hotel.

Face às necessidades da empresa o objectivo do estágio foi alterado e em vez de o objectivo

ser o controlo de um único dispositivo (Target), no âmbito do estágio o Smart Meter. Assim,

o projecto evoluiu para algo mais abstracto, escalável e flexível: a produção de um módulo de

software que permitisse controlar não apenas um Smart Meter, mas um qualquer Target sobre

o qual o UCH tenha controlo. Assim, o estágio passou a inserir-se também no âmbito do

projecto URC4ALL, onde se está a desenvolver uma WorkBench que agrupa um conjunto de

http://www.meticube.com/



funcionalidades indispensáveis no apoio a tarefas de monitorização, configuração, deployment

e a developers para o UCH. A integração de ambos os projectos é trivial, isto porque, ambos

os projectos têm na sua base a framework ON.IT, o que significa que são retro-compatíveis.

De salientar ainda o relevo do estágio curricular em ambos os projectos, pois é possível

controlar o Smart Meter (quando controlado pelo UCH), como qualquer outro dispositivo

(Target).

Sucintamente, o trabalho de estágio foi desenvolvido com base nas frameworks ON.IT e

UCH, um Plugin o que permitiu a criação dinâmica de uma interface de utilizador (User

Interface) para cada dispositivo (p.e. uma televisão), que disponibilize mecanismos que

permitam controlar independentemente cada Target, assim como representar os seus estados.

1.3. Empresa

A empresa Meticube foi fundada em 2002, no Centro de empresas de Taveiro, em Coimbra.

A empresa dedica-se ao desenvolvimento de software, sendo orientada ao desenvolvimento de

sistemas TI fiáveis, inovadores e integrados. Tendo iniciado a sua actividade nos sectores dos

caminhos-de-ferro, tornando-se num “fornecedor de TI” de referência nesta área, tendo criado

alguns sistemas críticos, como a gestão do limite de velocidade, controlos de acesso,

supervisão de passagens de nível e gestão de tráfego.

Mais recentemente, a empresa tem apostado no desenvolvimento de produtos, soluções e

tecnologias inovadoras (como o UCH), para mercados dinâmicos e em crescimento como as

Telecomunicações, Energia, Saúde e Hotelaria.

Alguns clientes e parceiros da empresa são:

CP - Comboios de Portugal EPE

REFER - Rede Ferroviária Nacional EPE

Metro-Mondego SA

TriDiVisions Lda

dotUI

Fraunhofer

Siemens


4

1.4. Estrutura do Relatório

1.4.1. Capítulo 1 – Introdução

No capítulo 1 efectua-se uma introdução ao estágio, assim como se abordam aspectos

relativos ao âmbito do Estágio/Projecto, objectivos e motivação, dá-se a conhecer a empresa e

faz-se referência à estrutura do relatório. Aborda-se também tópicos

preparatórios/introdutórios sobre as tecnologias e alguns projectos relacionados com o

estágio.

1.4.2. Capítulo 2 – Estado da Arte

No capítulo 2 faz-se o levantamento do estado da arte, identificando-se trabalhos similares, e

os pontos convergentes e divergentes destes trabalhos com o trabalho actual.

1.4.3. Capítulo 3 – Planeamento e Gestão do Projecto

O capítulo 3 refere-se ao planeamento e gestão de projecto, definição da equipa de projecto,

metodologia seguida durante o projecto, coordenação de reuniões e a calendarização do

mesmo.

1.4.4. Capítulo 4 – Análise e Desenvolvimento

O capítulo 4 refere-se ao trabalho em si, como estudos preliminares, início do projecto,

respectiva modulação e aspectos importantes da implementação.

1.4.5. Capítulo 5 – Trabalho Futuro

No capítulo 5 abordam-se ideias e melhorias, que podem contribuir para melhorar e

complementar o trabalho já realizado.

1.4.6. Capítulo 6 – Conclusões

O capítulo 6 representa o último capítulo do relatório fazendo-se aqui um resumo sobre o

trabalho desenvolvido.



Como complemento introduziram-se alguns anexos, que apesar de representarem informação

relevante do estágio, não se encontram incluídos no presente documento devido à sua

extensão ou devido ao seu formato (exemplo do Vídeo de Marketing). Ao longo do

documento serão efectuadas várias referências aos respectivos anexos, podendo também ser

consultados em formato digital, no CD que acompanha o relatório de estágio. A próxima

secção contém uma pequena descrição destes anexos.

1.4.7. Anexos

1.4.7.1. Anexo A – Documentação Técnica da framework ON.IT em Português

O Anexo A contém toda a documentação técnica sobre a framework ON.IT em Português

realizada pelo estagiário, nomeadamente a arquitectura de blocos, lógica e dinâmica.

1.4.7.2. Anexo B – Documentação Técnica da framework ON.IT em Inglês

O Anexo B contém toda a documentação técnica da framework ON.IT em Inglês realizada

pelo estagiário, nomeadamente a arquitectura de blocos, lógica e dinâmica

1.4.7.3. Anexo C – Documentação Técnica do Projecto

O Anexo C contém toda a documentação técnica do projecto Dynamic Target User Interface,

nomeadamente a identificação de requisitos, a modelação UML, diagramas de casos de uso,

arquitectura de blocos (diagramas de contexto), arquitectura dinâmica (diagramas de

sequência), arquitectura lógica (diagramas de classes) e aspectos relevantes da

implementação.

1.4.7.4. Anexo D – Plano de Testes

O Anexo D contém o plano de testes do projecto Dynamic Target User Interface.

1.4.7.5. Anexo E – Resultado do Plano de Testes

O Anexo E contém o resultado do plano de testes do projecto Dynamic Target User Interface.

1.4.7.6. Anexo F – Modelo de Dados

O Anexo F contém o modelo de dados do projecto Dynamic Target User Interface,

nomeadamente todos os diagramas de Classes e respectivas descrições das classes, métodos,

atributos e propriedades.


6

1.4.7.7. Anexo G – Manual de Utilizador

O Anexo G contém o manual de utilizador do projecto Dynamic Target User Interface.

1.4.7.8. Anexo H – Relatórios Quinzenais

O Anexo H contém todos os relatórios quinzenais criados pelo estagiário.

1.4.7.9. Anexo I – Código Fonte do Projecto

O Anexo I contém todo o código fonte relativo ao projecto Dynamic Target User Interface.

1.4.7.10. Anexo J – Código Fonte da Câmara de Vídeo integrada com ON.IT e UCH

O Anexo J contém todo o código fonte da Plugin que controla uma câmara de vídeo através

da integração das tecnologias ON.IT e UCH.

1.4.7.11. Anexo K – Testes Unitários

O Anexo K contém os testes unitários relativos desenvolvidos no decorrer do projecto.

1.4.7.12. Anexo L – Vídeo de Marketing

O Anexo L contém um vídeo de promoção e demonstração do projecto desenvolvido.

1.5. Tecnologia URC/UCH

A tecnologia URC/UCH é baseada numa nova série de normas e standards de indústria entre

eles o standard ISO/IEC 24752 (Universal Remote Console), que visa tornar dispositivos

acessíveis a pessoas com incapacidades cognitivas e a pessoas idosas definindo novas

interfaces de utilizador, por exemplo, redefinindo os botões de um comando de televisão ou

combinando vários comandos (de televisão, rádio) de forma a ficarem mais “acessíveis” e

adaptados às necessidades dos seus utilizadores. O objectivo destas novas interfaces de

utilizador passa pela ajuda em realizar várias tarefas, como por exemplo mudar o canal de

televisão, para pessoas que têm dificuldades em o fazer. Um outro objectivo desta tecnologia

passa pela centralização/redução/simplificação de funcionalidades, quando existirem, por

exemplo vários controlos remotos. Hoje em dia existe um vasto número de comandos para

controlar televisões, rádios, ar condicionados, ora torna-se muito complicado ter tantos

comandos, possuindo cada um deles, um grande número de funcionalidades, sendo esta tarefa

difícil de executar principalmente para pessoas com algum tipo de limitação. A simplificação

da interacção com todos os dispositivos torna-se então uma grande mais-valia para estas



pessoas, sendo que para solucionar o problema foi criado o UCH, na medida em que

possibilita a redefinição das interfaces de utilizador já existentes, adaptando-as às suas

necessidades.

Apesar destas interfaces de utilizador terem sido inicialmente pensadas para utilizadores com

algum tipo de limitações, o cenário de utilização desta tecnologia torna-se muito mais

abrangente e acessível a qualquer tipo de utilizador.

Na Figura 1 visualiza-se um diagrama conceptual do UCH. Ao centro tem-se o UCH que

funciona como uma camada intermédia (middleware) que abstrai os controladores dos

Targets, ou seja, abstrai a interface de utilizador do dispositivo a controlar, ignorando as

especificações técnicas de cada dispositivo (sendo toda essa abstracção processada pelo

UCH). Do lado esquerdo, tem-se os controladores, exemplo de um telemóvel, computador,

linguagem natural (voz), uma página Web e do lado direito da imagem os Targets

(dispositivos) a controlar, como por exemplo, um ar condicionado, uma televisão, um rádio,

o Twitter ou qualquer outro dispositivo/serviço.

Figura 1 – Diagrama Conceptual UCH


8

1.6. ON.IT

O ON.IT surgiu entre 2006 e 2008, sendo na altura apelidado de Look@it, quando a Meticube

constituiu e endogeneizou efectivamente um Núcleo de IDI, através de um projecto NITEC

(Criação de Núcleos I&DT no Sector Empresarial) financiado pela Agencia de Inovação

(AdI). Deste projecto resultaram conhecimentos significativos que permitiram o

desenvolvimento de uma plataforma de Monitorização e Controlo inovadora, o Look@it.

Esta plataforma originou uma framework de desenvolvimento poderosa que permite o rápido

desenvolvimento de um sistema de gestão centralizado, constituindo assim, uma ferramenta

robusta que permite uma fácil integração de qualquer tipo de equipamentos e sistemas numa

única aplicação.

Esta framework baseia-se no conceito de Plugins, consistindo cada Plugin num programa de

software que permite estender as funcionalidades de outro, denominado de host (neste caso o

ON.IT), possibilitando desta forma um desenvolvimento rápido, flexível e personalizável,

conseguindo integrar um grande número e tipo de sistemas de terceiros (third-party systems),

aplicações e serviços. Cada Plugin dentro da framework ON.IT funciona como uma mini-

aplicação standalone sem restrições e com capacidades virtualmente ilimitadas.

O projecto SICCA (Sistema de Controlo dos Canais de Acesso) representa um caso de

sucesso desta framework. Este sistema integra-se na arquitectura global do Sistema de

Informação de Suporte à Bilhética sem Contacto da CP-Lisboa, tendo como objectivo

principal o controlo dos acessos às estações.

De frisar que esta framework será a base do projecto URC4ALL, da qual o produto

desenvolvido também fará parte.

A documentação desta framework encontra-se no Anexo A em Português e no Anexo B em

Inglês, tendo sido desenvolvida pelo estagiário.



Figura 2 - ON.IT

Legenda/Descrição das funcionalidades:

1- Tree View – Zona que contém os Plugins em execução. Cada item na zona Tree View

representa um Plugin em execução.

2- Available Objects – Zona que contém os Plugins disponíveis na framework. Para os utilizar

(coloca-los em execução) basta arrasta-los para a Tree View.

3- Control Panel (Painel de Controlo) – Quando se selecciona um Plugin em execução na Tree

View é apresentado o painel de controlo do mesmo nesta zona.

4- Slot – Toda esta zona representa a Slot do ON.IT. Pode-se arrastar um Plugin da Tree View

para a Slot de forma a representar o Plugin na Slot, como na imagem.


10

1.7. ISO/IEC 24752

O standard ISO/IEC 24752 surgiu no âmbito do projecto i2Home[2]

, no qual participaram 9

entidades de 5 países diferentes, num projecto totalmente europeu, onde participaram

investigadores da Alemanha, Espanha, Portugal, República Checa e Suécia, tinha como

finalidade proporcionar aos portadores de necessidades especiais e idosos o controlo à

distância de diversos equipamentos e serviços electrónicos do lar, utilizando os seus

telemóveis e outros dispositivos.

O presente standard encontra-se dividido em 5 partes:

Framework (ISO/IEC 24752-1:2008)[4]

– Providencia uma visão geral dos componentes da

URC framework e do seu funcionamento.

User interface Socket Description (ISO/IEC 24752-2:2008)[5]

– Define o “User Interface

Socket”, onde se especifica o conceito de Socket Description. Representa uma User Interface

abstracta através da qual um Target (dispositivo/serviço) expõe as suas funcionalidades para

uma unidade de controlo. É definido na forma de uma linguagem XML que representa User

Interface Socket.

Presentation Template (ISO/IEC 24752-3:2008)[6]

– Define uma linguagem XML de forma a

descrever uma linguagem User Interface flexível que poderá ser utilizada como “descrição da

implementação da interface de utilizador” para uma User Interface Socket especifica.

Target Description (ISO/IEC 24752-4:2008)[7]

– Define a descrição de um Target e a

respectiva linguagem XML. A descrição de um Target contém apontadores para os Resources

e Sockets de um Target, com o objectivo de construir uma User Interface que se “ajuste” ao

Socket.

Resource Description (ISO/IEC 24752-5:2008)[8]

– Define como os recursos de uma User

Interface são descritos em termos de "Atomic Resources", "Resource Sheets", "Resource

Directories", e "Resource Services".

1.8. URC4ALL

O projecto URC4ALL encontra-se no âmbito de um programa nacional QREN, constitui um

sistema optimizado para o desenvolvimento, instalação e operação de aplicações e sistemas

centrados no utilizador final, de acordo com conceitos User Centric Design e User Interfaces

for Everyone promovido e iniciado por projectos Europeus de I&DT i2home[2]

e VITAL[3]

.

O objectivo principal do URC4ALL consiste em complementar a tecnologia URC/UCH,

desenvolvendo uma Workbench (UCH Workbench) que permita interagir, simplificar e

promover esta tecnologia. Desta forma, este projecto tem como objectivo agregar num único

ambiente, todo o conjunto de funcionalidades e ferramentas orientadas ao desenvolvimento,



integração, instalação e operação de aplicações baseadas nos standards ISO/IEC 24752 para

Universal Remote Consoles.

1.9. UCH Workbench

O UCH Workbench, como referido anteriormente surgiu no âmbito do projecto URC4All, no

qual se pretende dotar a tecnologia URC/UCH de ferramentas que permitam uma fácil e

simples interacção com esta tecnologia. O desenvolvimento para esta tecnologia actualmente

ainda é muito moroso, pois não existem ferramentas que auxiliem esta tarefa de uma forma

visual e simples, existindo ainda a dificuldade de ser necessário possuir conhecimentos sobre

os standards envolventes.

Neste sentido, o UCH Workbench tenta preencher algumas destas lacunas, promovendo o

fácil e rápido desenvolvimento para esta tecnologia.

1.10. SEFA

O conceito do projecto SEFA pode resumir-se ao desenvolvimento de um produto doméstico

e semi-industrial de forma a medir, monitorizar, e efectuar controlo básico sobre

equipamentos eléctricos. Pretendendo ainda contribuir para uma utilização mais eficiente da

energia educando os consumidores, criando a percepção da dimensão do consumo energético

na sua habitação, quer dos equipamentos habitualmente considerados como grandes

consumidores (como por exemplo as máquinas de lavar/secar, ar condicionados, frigoríficos e

arcas congeladoras, etc.), bem como dos consumidores “invisíveis” (aparelhos em stand-by,

computadores, televisões e outros aparelhos que o consumidor pensa terem consumos

negligenciáveis, etc.). Através do SEFA pretende-se monitorizar detalhadamente o consumo

de energia eléctrica na habitação na qual o sistema se encontra instalado, e a criação de perfis

de consumo para cada aparelho/dispositivo eléctrico, ao longo do tempo.

1.11. Dynamic Target User Interface

O projecto Dynamic Target User Interface a desenvolver no âmbito do presente estágio visa o

desenvolvimento de uma aplicação que permita estender as funcionalidades de um qualquer

projecto baseado em ON.IT de forma a conseguir gerar automaticamente uma interface de

utilizador para qualquer Target (dispositivo). Esta interface irá permitir visualizar os estados


12

de um Target, assim como controlá-lo utilizando o UCH. Esta aplicação deve também ser

personalizável pelo utilizador na medida em que ele pode interagir com os componentes

(trocar de componente ou mudar a sua localização).



Capítulo 2

Estado da Arte

O projecto Dynamic Target User Interface a desenvolver durante o estágio curricular incide

sobre a criação dinâmica de uma interface de utilizador (User Interface) para cada dispositivo

(Target) controlado por um UCH, de forma a conseguir controlar um Target assim como,

obter e representar o seu estado (p.e. estado ligado/desligado).

Actualmente, apenas existe uma ferramenta similar ao projecto de estágio, o Webclient

JavaScript Library[9]

, sendo baseado no protocolo URC-HTTP[20]

, fornecendo um Web Client

que tem por base JavaScript e HTML. Esta aplicação é responsável por construir interfaces de

utilizador automaticamente em HTML (na forma de tabelas), preenchidas com valores

oriundos do UCH, permitindo a interacção com qualquer Target através de um “simples”

browser.

Os utilizadores finais desta aplicação são:

Target Developers (os criadores de Targets), de forma a poderem testar os seus produtos,

auto-gerando a sua User Interface.

Designers, para construírem um design personalizado para cada Target usando templates

HTML (User Interfaces)

O Web Client tem como desvantagem, no seu modo de geração automático, gerar interfaces

muito simplistas, pois existem casos em que não consegue fornecer os mecanismos

necessários para interagir com um Target (por exemplo, a representação de um Comando).

Este facto pode ser ultrapassado criando um template HTML específico para cada Target. As

desvantagens associadas a esta personalização da interface de utilizador residem no facto de

serem necessários conhecimentos de programação, conhecimentos da norma ISO/IEC 24752,

assim como, todo o tempo despendido na criação destes templates HTML, que representam

uma tarefa morosa, e no seu índice muito baixo de reutilização de código. Este nível de

personalização é focado nos “programadores” e não nos utilizadores finais, pois como já foi

referido, qualquer alteração da interface de utilizador envolve conhecimentos de linguagens

de programação e da norma ISO/IEC 24752.


14

Importa ainda frisar, que o Web Client não suporta/não considera de raiz as dependências dos

elementos da Socket Description (por exemplo, se uma variável deve ser visível para o

utilizador).

Tendo em mente as desvantagens anteriores evidencia-se o facto do projecto Dynamic Target

User Interface, permitir a criação dinâmica e automática de uma interface de utilizador para

qualquer Target. Permite também, uma rápida e intuitiva personalização da interface de

utilizador gerada, através de um processo simples, baseado numa interface gráfica que abstrai

o utilizador de conhecer os standards envolventes.



Capítulo 3

Planeamento e Gestão do Projecto

3.1. Equipa

O presente estágio esteve incorporado no âmbito do projecto URC4ALL, embora de uma

forma não oficial, visto que o produto desenvolvido será integrado e distribuído na UCH

Workbench. Devido a este facto, o estagiário foi integrado no seio seguinte equipa:

Nome Cargo Descrição

Paulo Ventura Estagiário Desenvolvimento do módulo

Dynamic Target User Interface.

Micael Ramos Estagiário Desenvolvimento do módulo UCH

Cascading.

Pedro Sá Estagiário Desenvolvimento do módulo Socket

Description Editor.

Bruno Rosa Engenheiro de Software

Sénior

Developer

Coordenador técnico do projecto

URC4ALL e líder da equipa de

projecto.

Nelson Alves Engenheiro de Software

Developer

Telmo Pereira Engenheiro de Software

Sénior

Orientador do corrente estágio.

Hugo Felgar Engenheiro de Software

Developer

Nuno Cruz Innovation Manager

Responsável pelo Sistema

de Gestão da Investigação

Desenvolvimento e

Inovação

Gestor de Projecto.


16

Jürgen Bund Meticube CEO Coordenador geral do projecto

URC4ALL e do projecto SEFA.

Tabela 1 - Equipa projecto URC4ALL

3.2. Metodologia

O presente Dynamic Target User Interface seguiu uma metodologia interna de empresa que

tem por base o Iconix[12]

. Tendo sido esta metodologia desenvolvida pela ICONIX Software

Engineering e consiste num processo de desenvolvimento de software baseado em RUP e XP.

O ICONIX não é um processo tão burocrático como o RUP, pois não gera tanta

documentação mas é também um processo simples como o XP. Apesar disto, foca-se bastante

na Análise e Projecto (Design), destacando-se como um poderoso processo de

desenvolvimento de software.

Figura 3 – Metodologia Iconix

(imagem retirada de http://iconixprocess.com/iconix-process/)

http://iconixprocess.com/iconix-process/



A utilização desta metodologia por parte do estagiário efectuou-se nas seguintes etapas:

Requisitos, efectuando-se nesta fase o levantamento de requisitos sendo a base para a etapa

seguinte.

Modelo de Casos de Uso, nesta fase efectuou-se a identificação e modelação dos casos de uso

da aplicação.

Diagramas de Sequência, nesta fase foi elaborado um diagrama de sequência para cada caso

de uso.

Diagramas de Classes, nesta fase foram elaborados os diagramas de classes da aplicação.

Plano de Testes, nesta fase foi criado um plano de testes a realizar de forma a garantir que a

aplicação se encontrava de acordo com os requisitos, casos de uso e diagramas de sequência.

Implementação e testes unitários, nesta fase realizou-se a implementação da aplicação, e

durante o seu desenvolvimento foram realizados alguns testes unitários. Procedeu-se também

à revisão dos diagramas das fases anteriores.

Testes de aceitação, esta fase desenrolou-se após a fase de implementação se encontrar

concluída, onde foram efectuados testes funcionais de forma a verificar a qualidade da

aplicação.

3.3. Coordenação e reuniões

Ao longo do estágio foram realizadas algumas reuniões, a maior parte de coordenação com

orientador de estágio na empresa, assim como também foram realizadas reuniões mais

formais de forma a efectuar um ponto de situação do estágio, participando nestas reuniões

outros elementos da empresa.

Quinzenalmente era também elaborado um relatório com as tarefas desempenhadas,

encontrando-se no Anexo H.

3.4. Calendarização

A calendarização foi definida pelo estagiário, a sua representação pode ser visualizada através

da Figura 4 e da Figura 5.


18

Figura 4 – Diagrama de Gantt Planeamento inicial



Figura 5 – Diagrama de Gantt Final



Capítulo 4

Análise e Desenvolvimento

4.1. Definição do problema

Como mencionado anteriormente, existe apenas uma única ferramenta/aplicação integrada

com o UCH, denominada Web Client[9]

, que permite a criação de uma User Interface

automática de forma a poder interagir com um Target, e assim obter os seus estados, alterar as

suas variáveis, efectuar operações sobre o mesmo (invocar Comandos) e receber os seus

alertas (notificações). Esta ferramenta tem muitas limitações, como o facto de não

disponibilizar de raiz todos os mecanismos necessários para interagir com um Target (p.e.

permitir invocar um comando) e a sua difícil/morosa personalização, que envolve

conhecimentos de programação e conhecimentos do standard do URC (ISO/IEC 24752).

Com o Web Client[9]

para personalizar um Target tornava-se imprescindível uma grande

intervenção humana, uma vez que seria necessário pensar/desenhar uma User Interface

adequada, analisando a Socket Description do Target e manualmente utilizando um editor de

texto ou um qualquer editor de HTML e JavaScript de forma a construir uma “aplicação” que

permitisse o controlo sobre o Target. Todo este processo implica possuir conhecimentos

“programáticos” sobre as tecnologias HTML e JavaScript, inclusive o estudo e conhecimento

sempre presente dos standards do URC (ISO/IEC 24752). Este processo torna-se necessário,

porque a ferramenta existente, no seu modo de geração automático de uma User Interface (ou

seja, não adaptada/personalizada ao Target) gera inicialmente uma User Interface

minimalista, focada nos “programadores” da tecnologia URC/UCH, de modo aos mesmos

poderem efectuar testes sobre os Targets desenvolvidos, e assim averiguar se o seu

funcionamento é o esperado. Este processo não se adequa ao utilizador final, e nem fornece ao

utilizador final uma forma intuitiva de interagir com um Target, a menos que seja definido um

design personalizado para o Target, como referido anteriormente.

Desta forma, o presente projecto visa o Parsing da Socket Description para vários

componentes/controlos, ou seja, cada Socket Element da Socket Description, será

“convertido” para um controlo/componente que represente graficamente um Socket Element,

permitindo assim ao utilizador interagir com o Target, possibilitando também a obtenção do


22

estado interno do Target através desse componente. Com a utilização de componentes é

possível converter um Socket Element do tipo Command, responsável por abrir o portão de

uma garagem, para um controlo/componente que represente um botão, que quando

pressionado, abra o portão da garagem.

Assim sendo, é possível construir automaticamente uma User Interface, pronta para o cliente

final utilizar. Obviamente a forma como esta User Interface será gerada depende da semântica

da Socket Description (forma como a Socket Description foi elaborada), pois não é possível

prever, por exemplo que um elemento do tipo Command, é utilizado para abrir um portão, ou

se serviria para qualquer outra tarefa, esta intuição/percepção/inteligência exigiria por

exemplo uma alteração ao standard de forma a permitir identificar qual o propósito de

determinados elementos da Socket Description.

Dados estes motivos, em certos casos, pode não ser possível determinar qual o melhor

componente para determinado Socket Element, ou, por outro lado, o utilizador pode

simplesmente querer utilizar outro componente, pelo que a utilização de componentes

proporciona, uma fácil e intuitiva substituição dos mesmos, desde que compatíveis com o

mesmo Socket Element.

De ressalvar ainda o facto do produto a desenvolver ter de conseguir abstrair o utilizador de

conhecer o standard do URC (ISO/IEC 24752), interagindo apenas com elementos visuais,

adaptando a User Interface ao seu gosto. Este produto deve validar os inputs introduzidos nos

componentes, em função do seu Data Type[10]

e XML Schema[11]

. Deve também efectuar uma

análise das dependências de um Socket Element, de forma a identificar se um elemento deve

ser visível, invisível, ou se deve permitir a alteração dos seus dados.

Figura 6, podemos observar um exemplo do parsing efectuado sobre uma Socket Description

em componentes, neste exemplo concreto, a Socket Description refere-se a uma câmara de

vídeo. Através da imagem, podemos observar que os componentes se encontram preenchidos

com dados, sendo estes dados oriundos do UCH. Na figura podemos também constatar que

existem alguns componentes “desactivados”, caso do VideoStreamUri. Esta situação deve-se

ao processamento das dependências do Socket Element do componente, que determinou que o

componente não deveria permitir alterações aos seus dados. O próprio facto de um

componente se encontrar “visível” deve-se a um processamento de dependências.



Figura 6 - Exemplo de Componentes gerados através da Socket Description

4.2. Estudo ON.IT

Uma das primeiras tarefas do presente estágio incluiu a ambientação, estudo e

documentação da framework ON.IT.

Visto o nível de documentação de framework ser muito reduzido e devido ao interesse

demonstrado por parte de vários clientes da Meticube em desenvolver para esta

plataforma foi necessário proceder à sua documentação. Sendo a documentação também

muito importante a nível interno.

A próxima secção contém a descrição do nível mais elevado do diagrama de blocos da

arquitectura do ON.IT, elaborada pelo estagiário, ficando o resto da arquitectura no Anexo

A em Português e no Anexo B em Inglês. Na Figura 2, pode-se visualizar um print-screen

do ON.IT em “execução”.


24

4.1.1. Arquitectura de Blocos

No diagrama de contexto representado na Figura 7, mostra-se uma visão geral de toda a

framework ON.IT. Através deste nível de abstracção identificam-se os principais

componentes da framework.

Figura 7- Diagrama Contexto ON.IT

Existem dois tipos de componentes descritos: os componentes internos à framework, e os

componentes externos. Os componentes internos fazem parte directamente do core da

framework, e os componentes externos apesar de estarem fora do seu core são parte integrante

da framework, porque se encontram interligados com o core.

Pelo diagrama infere-se a existência de três componentes principais internos à framework:

Concrete IPluginHost (Form Main)

Association Manager

Plugin Sandbox

Em relação aos componentes externos identificam-se dois componentes:

WatchDog Server

WSLookatit2009 (web service)



4.1.1.1. Concrete IPluginHost (FrmMain)

O componente Concrete IPluginHost representa a maior parte da framework ON.IT.

O nome atribuído ao componente advém do facto do mesmo ser uma implementação da

interface IPluginHost. Para melhor se evidenciar, a implementação da interface IPluginHost

num caso concreto, pode ser chamada de Form Main.

Visto que este componente implementa a interface IPluginHost, é responsável por controlar e

gerir o comportamento dos Plugins, assim como gerir e apresentar o interface de utilizador,

apesar desta última utilidade ser secundária quando comparada com o controlo de toda a

framework.

Interessa ainda frisar o facto do Concrete IPluginHost possuir um gestor de associações

(Association Manager), que permite associar um ou mais Plugins, assim como o componente

Plugin Sandbox que representa todos os Plugins. O gestor de associações e o Plugin Sandbox,

encontram-se devidamente documentados nos dois próximos tópicos.

4.1.1.2. Association Manager

O componente Association Manager é responsável por gerir associações.

Como uma associação consiste na interligação entre dois ou mais Plugins, o Association

Manager é responsável por fazer a gestão dessas associações.

O processo de gestão de associações detém a responsabilidade de executar todas as

associações existentes.

Cada associação pertence a um dos dois tipos:

Associações de Acções (Actions Associations)

Associações de Pipes (Pipes Associations)

Uma associação representa uma conexão entre dois Plugins, que podem ser do tipo Action ou

do tipo Pipe, uma conexão quando criada define um Plugin origem e um Plugin destino.


26

a) Associação do tipo Acção (ActionAssociation)

Uma Associação do tipo Action consiste na execução de uma Acção (Action) num Plugin

destino quando uma Condição (Condition) é verificada num Plugin origem.

Por exemplo: considerando que existem dois Plugins, o primeiro para controlar uma câmara

de vídeo (CamaraPlugin) e um segundo para controlar uma Lâmpada (LampadaPlugin),

pode-se criar uma Associação entre o CamaraPlugin e o LampadaPlugin, definindo por

exemplo, que a lâmpada (LampadaPlugin) deve ser ligada (Action) quando a câmara

(CamaraPlugin) detectar movimento (Condition).

b) Associação do tipo Pipe (PipeAssociation)

Uma Associação do tipo Pipe representa um fluxo de dados entre Plugins. Como um Pipe

representa um fluxo de dados entre Plugins um dos Plugins tem de funcionar como receptor

de dados (input) e o outro como emissor (output).

Um Plugin pode ter até três tipos de conectores, que determinam se um Plugin pode receber

(In), enviar (Out) ou receber e enviar dados (InOut).

Os Plugins que possuam conectores do tipo In funcionam como receptores de dados (input),

por sua vez os Plugins com conectores do tipo Out funcionam como emissor de dados

(output), existindo também um conector especial chamado de InOut, que possui a

particularidade de funcionar como receptor de dados, transformar os dados recebidos e

posteriormente enviar os dados para outro Plugin.

Por exemplo: Considerando um Plugin do tipo Câmara de Vídeo (CamaraPlugin) e um

Plugin de e-mail (EmailPlugin), pode-se criar uma associação do tipo Pipe entre o

CamaraPlugin e o EmailPlugin de forma e enviar uma imagem ou conjunto de imagens para

o EmailPlugin tratando este Plugin de enviar um e-mail com essas imagens).

4.1.1.3. Plugin Sandbox (IPlugin)

O Plugin Sandbox consiste numa representação virtual de todo o aglomerado de Plugins.

Um Plugin na sua forma mais básica consiste na implementação da interface IPlugin que

permite à framework executar e controlar os Plugins.



4.1.1.4. WatchDog Server

O WatchDog Server representa um componente externo à framework ON.IT.

O componente garante que os serviços disponibilizados pela framework se tornem tolerantes a

falhas com um elevado grau de disponibilidade. Se por algum motivo o ON.IT não se

encontre em execução, o WatchDog encarrega-se de voltar a colocá-lo em execução.

4.1.1.5. WSLookatit2009

A framework comunica também com um componente externo, o Web Service

WSLookatit2009.

O componente descrito contém um conjunto de Web Services que têm como função a

manipulação da base de dados, de forma a adicionar, editar, remover registos da mesma.

A utilização de Web Services torna a framework mais flexível, o que providencia

interoperabilidade de sistemas para além de permitir um desacoplamento de serviços, que por

sua vez origina uma redução da complexidade do sistema.

4.2. Estudo Tecnologia URC/UCH

Uma das tarefas necessárias para a implementação do corrente projecto foi o entendimento do

modo de funcionamento da tecnologia URC/UCH.

Esta tecnologia é baseada no standard ISO/IEC 24752 para “Universal Remote Consoles”,

sendo a tecnologia UCH a implementação “prática” do standard.

O UCH consiste num middleware que permite a abstracção dos protocolos de comunicação

entre os Controladores (Controllers) e os dispositivos/serviços a controlar (Targets). Exemplo

de controladores são os dispositivos e/ou User Interfaces que controlam um Target através do

UCH, tais como, telemóveis, browsers, aplicações, entre outros. São exemplos, entre outros,

de Target uma câmara de vídeo, um portão de uma garagem, ou o Twitter. Sucintamente,

pode-se dizer que o UCH tem como finalidade fazer a “ponte” ente os Controllers e os

Targets.


28

Figura 8. Arquitectura do UCH

(Imagem retirada de [13])

Relativamente à arquitectura do UCH, podemos observar pela Figura 8 que se destacam três

camadas:

User Interface Protocol Layer (UI Protocol Layer)

User Interface Socket Layer (UI Socket Layer)

Target Adapter Layer

A camada User Interface Protocol Layer, responsável pela negociação e comunicação com os

Controllers (controladores). Esta comunicação é efectuada através de um protocolo

específico, como por exemplo, o protocolo HTTP. A importância desta camada reside no

facto de conseguir abstrair a Socket Layer de protocolos e tecnologias específicas utilizadas

para comunicar com os dispositivos de controlo (Controllers). A comunicação é efectuada

utilizando módulos designados por User Interface Protocol Modules (UIPM) que são

responsáveis pelos protocolos de comunicação, traduzindo o protocolo nativo do Controlador

para a API especifica do UCH.

A camada User Interface Socket Layer, representa a camada central do UCH. Esta camada

abstrai-se das características específicas dos protocolos de comunicação utilizados para

comunicar com os Controllers e com os Targets, sendo esta abstracção apenas possível

devido às duas outras camadas do UCH, que contêm componentes onde são especificados os



protocolos de comunicação utilizados. Estes componentes “traduzem” as mensagens de um

protocolo específico para a API específica do UCH. A abstracção do protocolo de

comunicação com o Target permite a diferentes controladores (Controllers) utilizarem o

mesmo Socket. Esta camada é também responsável por gerir as várias Socket Instances

criadas a partir das Socket Descriptions em run-time pelo UCH, funcionando estas Socket

Descriptions como uma “ponte” entre os Controllers e os Targets.

De ressalvar que as Socket Instances criadas pelo UCH criaram uma componente activa capaz

de fornecer uma interface que faz a ligação com a camada User Interface Protocol e com a

camada Target Adapter.

A camada Target Adapter, responsável pela descoberta (procura de Targets), negociação e

comunicação com os Targets. A comunicação com estes Targets é efectuada através de um

protocolo específico. Esta camada abstrai a Socket Layer das características específicas dos

protocolos de comunicação.

Figura 9. Interacção/comunicação entre componentes do UCH em run-time

(Imagem retirada de [14])

Esta camada é constituída por dois módulos Target Discovery Modules (TDMs) e os Target

Adapter Modules (TAs). Os TDMs são responsáveis pela descoberta de novos Targets de

forma ao UCH poder controlá-los. Os TAs são responsáveis pela comunicação com os

dispositivos (Targets) através dos seus protocolos nativos e com a camada Socket Layer

através do módulo Target Manager.


30

4.3. Estudo Standard ISO/IEC 24752

O estudo e análise do standard ISO/IEC 24752, consistiu numa das tarefas realizadas no

estágio.

Como referido anteriormente, o presente standard encontra-se dividido em cincos partes,

sendo a segunda parte do standard, o principal foco deste estágio, por se referir à estrutura da

User Interface Socket Description (Socket Description). Esta parte do standard é

especialmente importante para o estágio por incidir sobre a representação gráfica de uma

qualquer Socket Description, que permita obter o estado interno e que permita controlar um

Target.

Uma Socket Description pode ser sumarizada em algo abstracto que permite descrever e

identificar as funcionalidades, operações e o estado interno de um dispositivo / serviço

designado por Target.

Visto a segunda parte do standard ser o foco do estágio serão efectuadas referências aos

pontos mais importantes do standard (User Interface Socket Description). A User Interface

Socket representa um conceito abstracto que descreve as funcionalidades e estado de um

dispositivo ou serviço (Target). O propósito da segunda parte do standard consiste na

definição de uma linguagem baseada em XML de forma a descrever uma User Interface

Socket. O propósito desta User Interface Socket é expor informação relevante sobre um

Target de forma ao utilizador perceber o seu estado e operar sobre ele. Esta operação inclui

apresentação de dados ao utilizador, variáveis que podem ser manipuladas pelo mesmo,

comandos que o utilizador por invocar/activar, e excepções sobre as quais o utilizador será

notificado. A especificação da User Interface Socket é aplicável à construção e personalização

de interfaces de utilizador.

Desta forma, nas próximas secções serão identificados todos os elementos do standard que

constituem uma Socket Description e os seus aspectos mais importantes. De frisar que as User

Interfaces dinâmicas geradas no presente projecto de estágio serão baseadas no Parsing

(Conversão) de uma Socket Description.



4.3.1. Set

O Socket Element Set representa uma estrutura interna hierárquica de um User Interface

Socket. Este elemento funciona como um grupo, que agrega outros Socket Elements, inclusive

outros Set.

O exemplo identificado na Figura 10 representa um Set Element “camera” contém duas

variáveis “VideoStreamUri” e “Resolution” e um comando “MoveLeft”. Estas duas variáveis

“armazenam” informação relativa da câmara como o seu endereço de Live Stream e a sua

resolução, o comando permite mover a câmara para a esquerda.

<set id="camera”>

<variable id=” VideoStreamUri” type=”xsd:string” />

<variable id=” Resolution” type=” resolutionType” />

<command id=”MoveLeft” type=”uis:basicCommand” />

</set>

Figura 10 – Exemplo de um Set Element

4.3.2. Variable

O elemento Socket Element representa as variáveis utilizadas para expor o estado de um

Target. Será nestas variáveis que se encontra toda a informação dinâmica que um utilizador

pode visualizar e manipular (caso as dependências associadas à variável assim o permita).

A Figura 11 é ilustrativa deste tipo de elementos. Neste caso concreto esta “variável”

armazena uma “string” contendo o endereço de Live Stream de uma câmara de vídeo.


32

<variable id="VideoStreamUri" type="xsd:string">

<dc:description xml:lang="en">

Camera's video stream URI

</dc:description>

<dependency>

<relevant>true()</relevant>

<write>false()</write>

</dependency>

</variable>

Figura 11 – Exemplo de um Variable Element

4.3.3. Constant

O Socket Element Constant representa um “valor” que não pode ser alterado.

A Figura 12 representa um elemento deste tipo, neste exemplo tem utilidade para armazenar o

número de série de um dispositivo. Faz todo o sentido utilizar este tipo de elemento neste caso

concreto, pelo facto do número de série de um dispositivo ser sempre o mesmo e nunca

permitir alterações ao seu valor.

<constant id="modelVersion" type="xsd:string">

23232322-HU

<dc:description>

A target model version

</dc:description>

<dependency>


</dependency>

</constant>

Figura 12 – Exemplo de um Constant Element



4.3.4. Command

O Socket Element Command (comando), representa uma operação, acção sobre um Target, ou

seja, uma acção que não pode ser efectuada pela simples troca do valor de uma variável, como

por exemplo, abrir um portão.

Um Comando pode ser de 3 tipos:

uis:voidCommand – Invoca o comando e não retorna nada

uis:basicCommand – Invoca um comando e pode retornar valores

uis:timedCommand – Invoca um comando que demore algum tempo de processamento. Este

tipo de comando vai “enviando” o estado da operação/processamento, por exemplo: 50%,

60%.

Importa referir que os comandos podem ter associados a si parâmetros de entrada e saída. Por

exemplo para efectuar uma operação de autenticação de um utilizador no Facebook é

necessário introduzir o nome de utilizador e password. Se esta operação fosse convertida num

comando de autenticação (Login), o utilizador e password eram os seus parâmetros de entrada

e o resultado da operação (autenticação com sucesso/insucesso) seriam o seu output.

A Figura 13 mostra o exemplo de um comando, neste caso particular este comando quando

invocado com sucesso permite ligar uma televisão, este comando tem ainda a particularidade

de poder ser executado apenas quando a televisão estiver desligada (encontrando-se esta

restrição definida na tag “<write>”).

<command id="powerOn" type="uis:basicCommand">

<dc:description>Power on the TV. Operation allowed if the TV is

powered off.</dc:description>

<dependency>


<write>not(value('powerStatus'))</write>

</dependency>

</command>

Figura 13 – Exemplo de um Command Element


34

4.3.5. Notification

O Socket Element Notification, representa uma notificação/alarme. Uma notificação,

representa uma operação especial cuja normal actividade é suspensa por estados excepcionais.

Exemplo de um alarme de incêndio, ou um alarme de consumo excessivo de energia.

De referir que uma notificação pode ser de uma de três categorias:

Info – representa uma informação

Alert – representa um alerta

Error – representa um erro

Uma notificação tem dois estados:

Active – notificação activa

Inactive – notificação inactiva

A Figura 14 representa uma notificação do tipo Info, esta notificação é “lançada” quando a

conexão com uma câmara de vídeo é perdida, esta notificação tem ainda a particularidade de

ter que ser confirmada (explicitAck definido como activo).

<notify id="LostConnectivityAlarm" category="info" includesRes="true">

<dc:description>

Raised when connection to the camera is lost

</dc:description>

<dependency>

<explicitAck>true()</explicitAck>

</dependency>

</notify>

Figura 14 – Exemplo de um Notify Element



4.4. Preparação do Trabalho do Projecto

Para um melhor entrosamento e entendimento dos conceitos o estagiário teve de executar

algumas tarefas de preparação, como o estudo das normas e frameworks, assim como produzir

alguma documentação e software de forma a consolidar o estudo feito.

4.4.1. ON.IT

Em relação ao ON.IT, o estagiário teve de produzir a sua documentação tanto em Português

como em Inglês (Anexos A e B respectivamente). E teve de elaborar um Plugin genérico de

forma a melhor compreender os conceitos associados aos Plugins e ON.IT, assim como

também para poder entender como elaborar os Plugins do presente projecto.

4.4.2. UCH

A nível do UCH, o estagiário teve de proceder à criação de uma Socket Description dotada da

capacidade de controlar um rádio através de um simulador. Esta “actividade” permitiu uma

compreensão prática sobre como elaborar uma Socket Description e perceber como ela se

relaciona/interage com o UCH. Esta tarefa revelou-se também útil a nível da implementação

dos testes funcionais, visto que existem (na empresa) relativamente poucas Socket

Descriptions, pelo que alguns casos concretos da Socket Description/XML SCHEMA[11]

poderiam não ser testados. Para ultrapassar esta limitação foi necessário simular/criar uma

Socket Description de forma a contemplar estes casos.

4.4.3. UCH Integrado no ON.IT

Uma vez que o objectivo do projecto passou por integrar o ON.IT com o UCH de forma a

criar um Plugin genérico que permitisse a criação dinâmica de interfaces de utilizador,

procedeu-se previamente ao desenvolvimento de um Plugin com uma interface “estática/feita

por medida” para controlar uma câmara de vídeo (Target) através do UCH.

Como resultado desta tarefa foi criado um Plugin que permitiu controlar o Target referente a

uma câmara de vídeo através dos controlos/componentes existentes no Painel de Controlo do

ON.IT que comunicassem/interagissem/controlassem o respectivo Target através do UCH

como se pode ver na Figura 15 em que se representa na Slot do ON.IT o streaming de vídeo

da câmara.


36

Figura 15 - Plugin Câmara de Vídeo Axis 221 + UCH

4.5. Dynamic Target User Interface

Nesta secção será apresentado o resultado da especificação e modelação do Dynamic Target

User Interface.

De frisar como já referido, o facto do projecto se encontrar dividido em dois Plugins:

Plugin Target Discovery – responsável pela detecção dos Targets através do UCH e a sua

posterior criação de Plugins do tipo Dynamic Target.

Plugin Dynamic Target – responsável pela criação dinâmica de uma User Interface que

permita controlar um Target.

4.5.1. Requisitos

Dentro das tarefas atrás referidas tendo em vista o levantamento de requisitos destacam-se as

seguintes:

Estudo ON.IT (secção 4.1);

Estudo do standard ISO/IEC 24752 (secção 4.3);

Estudo tecnologia UCH (secção 4.2);

Elaboração de documentação e software preparatório para o desenvolvimento/ início do

projecto (secção 4.4);



4.5.1.1. Plugin Target Discovery

ID Descrição Tipo (Funcional /

Não Funcional)

REQ 1 Deve permitir a listagem dos Targets de um UCH. Funcional

REQ 2 Deve ser possível criar um Plugin Dynamic Target por cada

Target seleccionado adicionando-o à TREE do ON.IT como seu

“filho”.

Funcional

REQ 3 O Target Discovery deve permitir detectar os seus “filhos”

Dynamic Target Plugin na TREE do ON.IT.

Funcional

REQ 4 Deve permitir a alteração do IP e Porto do UCH, sendo essas

alterações propagadas também aos seus “filhos” Dynamic

Target Plugin.

Funcional

Tabela 2 – Requisitos do Plugin Target Discovery

4.5.1.2. Plugin Dynamic Target

ID Descrição Tipo (Funcional /

Não Funcional)

REQ 5 Deve permitir a outros Plugins criarem/adicionarem um

Dynamic Target para um dado Target baseado no seu TargetID,

UCH IP e UCH Port.

Funcional

REQ 6 Deve permitir gerar automaticamente uma representação gráfica

(User Interface) na forma de “componentes/user controls” para

qualquer Target através da sua Socket Description no Painel de

Controlo (Control Panel) do ON.IT. Parse da Socket

Description em componentes.

Não Funcional

REQ 7 Cada Socket Element de um dado Target deve ter associado um

componente.

Não Funcional

REQ 8 Deve ser possível obter os dados/valores/estados de um Target

através do UCH.

Funcional

REQ 9 Deve ser possível através dos componentes interagir com o

respectivo Target, de forma a ser possível efectuar alterações de

Funcional


38

variáveis, invocar comandos e enviar acknowledgments.

REQ 10 Deve ser possível detectar quando se está “desconectado” de

um Target.

Funcional

REQ 11 Deve ser possível receber as actualizações de um Target através

do UCH, como alterações de variáveis e estados.

Funcional

REQ 12 Deve ser possível verificar/aplicar as restrições de visibilidade e

de alteração dos dados/estados a um componente/Socket

Element.

Funcional

REQ 13 Deve ser possível alterar um componente por outro compatível. Funcional

REQ 14 Deve ser possível mover espacialmente um componente. Funcional

REQ 15 Deve ser possível alterar a posição (ordem) do Componente. Funcional

REQ 16 Deve ser possível alterar as definições do UCH (IP e PORT) e

Nome do Plugin.

Funcional

REQ 17 Deve ser possível “enviar/representar” componentes na Slot do

ON.IT.

Funcional

REQ 18 Deve ser possível “remover” componentes da Slot do ON.IT. Funcional

REQ 19 Deve ser possível guardar as alterações efectuadas sobre os

componentes (localização, tipo componente, user interface

gerada…).

Funcional

REQ 20 Deve ser possível alterar a “Label” de um componente. Funcional

REQ 21 Deve ser possível validar o “input” dos componentes

introduzidos pelo utilizador.

Funcional

REQ 22 Deve ser possível organizar os componentes pela sua ordem e

visibilidade.

Funcional

REQ 23 Carregar a User Interface do Target previamente guardada. Funcional

REQ 24 Deve ser possível aplicar diferentes formas de representar os

componentes de acordo com a sua restrição de visibilidade e de

modificação.

Funcional

Tabela 3 – Requisitos do Plugin Dynamic Target



4.5.1.3. Casos de Uso

A presente secção contém os actores e casos de uso identificados, de uma forma muito

sucinta. A restante documentação relativa aos casos de uso do projecto encontra-se no Anexo

C, na secção Casos de Uso.

4.5.1.4. Actores

Os actores do presente projecto encontram-se representados na próxima figura:

Figura 16 – Actores

Actor Descrição

User Representa um utilizador do Sistema.

TargetDiscovery Plugin Representa uma instância do Plugin Target Discovery.

DynamicTarget Plugin Representa uma instância do Plugin Dynamic Target.

UrcHttpClient Representa a biblioteca que permite a comunicação/interacção com

o UCH.

Tabela 4 – Actores dos Casos de Uso

uc Actors

User DynamicTarget PluginTargetDiscov ery Plugin UrcHttpClient


40


Figura 17 - Diagrama dos Casos de Uso do Plugin Target Discovery

ID do Caso de

Uso Nome do Caso de Uso

UC 101 Listar Targets

UC 102 Criar Plugins Dynamic Target

UC 103 Detectar Plugins descendentes do tipo Dynamic Target Plugin

UC 104 Alterar Definições do Plugin Target Discovery

Tabela 5 - Casos de Uso do Plugin Target Discovery

uc Target Discov ery Model

UC 204: Alterar Definições

do Plugin Target Discov ery

UC 201: Criar Plugin

Dynamic Target

UC 101: Listar Targets

User

UC 102: Criar Plugins

Dynamic Target

UC 103: Detectar

Plugins descententes

do tipo Dynamic Target

Plugin

UC 104: Alterar

Definições do Plugin

Target Discov ery«include»

«include»

«include»




Figura 18 - Diagrama dos Casos de Uso do Plugin Dynamic Target

uc Dynamic Target Model

System Boundary

User

(from Actors)

TargetDiscov ery Plugin

(from Actors)

UC 201: Criar Plugin

Dynamic Target

UC 202: Criar/Gerar User

Interface do Target

UC 210: Env iar v alores

para o UCH

UC 205: Obter Valores do

UCH

UC 203: Parse Socket

Description em

componentes/user

controls

UrcHttpClient

(from Actors)

UC 206: Processar

actualizações de

v alores oriundos do

UCH

UC 220: Processar

alterações do estado da

conexão

UC 207: Colocar v alor no

componente correcto

UC 208: Aplicar restrições de

v isibilidade e alteração aos

componentes

UC 217: Substituir

componente por outro

compatív el

UC 213: Mov er

Componente

UC 212: Alterar a ordem

de um componente

UC 204: Alterar Definições

do Plugin Target Discov ery

UC 218: Guardar todas

as alterações

UC 216: Alterar Label de

um componente

UC 211: Validar input

dos componentes

UC 215: Alterar modo de

apresentação das

restrições

UC 219: Alterar v alor de

um componente

UC 209: Carregar User

Interface guardada

IMyComponent

(from Actors)

DynamicTarget Plugin

(from Actors)

UC 214: Slot

Adicionar/Remov er

componentes

«include»

«include»

«include»

«include»

«include»

«include»

«include»


42

ID do Caso de

Uso Nome do Caso de Uso

UC 201 Criar Plugin Dynamic Target

UC 202 Criar/Gerar User Interface do Target

UC 203 Parse Socket Description em componentes/user controls

UC 204 Alterar Definições do Plugin Target Discovery

UC 205 Obter Valores do UCH

UC206 Processar actualizações de valores oriundos do UCH

UC 207 Colocar valor no componente correcto

UC 208 Aplicar restrições de visibilidade e alteração aos componentes

UC 209 Carregar User Interface guardada

UC 210 Enviar valores para o UCH

UC 211 Validar input dos componentes

UC 212 Alterar a ordem de um componente

UC 213 Mover Componente

UC 214 Slot Adicionar/Remover componentes

UC 215 Alterar modo de apresentação das restrições

UC 216 Alterar Label de um componente

UC 217 Substituir componente por outro compatível

UC 218 Guardar todas as alterações

UC 219 Alterar valor de um componente

UC 220 Processar alterações do estado da conexão

Tabela 6 - Casos de Uso do Plugin Dynamic Target



4.5.2. Diagramas de Contexto

A Figura 19 representa o diagrama de contexto do Dynamic Target User Interface, destacam-se os dois

Plugins Target Discovery Plugin e o Dynamic Target Plugin e a sua integração com a framework

ON.IT e a framework UCH.

Figura 19 – Diagrama de Contexto Dynamic Target User Interface

4.5.3. Diagramas de Sequência

Na presente secção serão apresentados alguns dos diagramas de sequência desenvolvidos.

Dado o seu grande número não é possível representar a totalidade dos diagramas nesta secção,

podendo a consulta dos restantes diagramas ser efectuada na secção Arquitectura Dinâmica do

Anexo C.

Foram seleccionados os diagramas que representam a forma de criar um Plugin Dynamic

Target assim como o diagrama responsável por efectuar o Parse da Socket Description em

componentes (User Controls) e o diagrama que representa como uma actualização oriunda do

UCH é processada.

UC 102: Criar Plugins Dynamic Target

Figura 20 – Diagrama de Sequência Criar Plugins Dynamic Target

sd UC 102: Create DynamicTarget Plugins

User

(from Actors)

Target Discovery

Administration

Window :

Administration

(from Interfaces & Classes)

Target List :

CheckedListBoxControl


Editor

DynamicTarget

Plugin :Editor


loop

[New Selected Targets]

Open()

Select New Targets()

CreateTreeTarget(string name, string uch_ip, int uch_port, string targetID,int parentPluginId)

AddToTree(PluginPath, name, uch_ip, uch_port, targetID, this._host,parentPluginId);


UC 201: Criar Plugin Dynamic Target

Figura 21 – Diagrama de Sequência Criar Plugin Dynamic Target

sd UC 201: Create Dynamic Target Plugin

TargetDiscovery Plugin

(from Actors)

Editor

DynamicTarget

Plugin :Editor


DynamicTargetProperties

:

DynamicTargetProperties


ControlPanel :

ControlPanel

serialize :

SerializeDynamicTarget

Generate the dynamic Target User Interface

Serialize the Generated Components

Serialize all DynamicTarget Properties

Save the New DynamicTarget Plugin in "Database" and adds the new

DynamicTarget Plugin as child of the parent Target Discovery Plugin

AddToTree(string pluginPath, string name, string

uch_ip, int uch_port, string targetID, IPluginHost

host,int parentPluginId) CreateDynamicTargetPlugin()

Set Properties Values()

Start(targetID, uch_ip, uch_port, true);

SerializeDynamicTargetComponents()

Serialize()

AddXmlProperties(string pluginPath, string xml,

IPluginHost host, int objectID, IView2D iView,

UC 203: Parse Socket Description em componentes/user controls

Figura 22 – Diagrama de Sequência Parse Socket Description em componentes/user controls

sd UC 203: Parse Socket Decription into components/user controls

DynamicTarget Plugin

(from Actors)

MasterComponents :

MasterComponents

ComponentGenerator :

ComponentGenerator

ControlPanel :ControlPanel AbstractSocketElement

loop

[Recursive Generation]

ParseSocketDescriptionIntoComponents()

CreatePanel("/",UCHManager, SocketInstance);

CreatePanel("SlotForm",UCHManager,SocketInstance);

ParseSocketElementsToComponents(List<AbstractSocketElement> socketElementsList, string path)

GenerateComponent(string path, UCHManager uchManager, SocketInstance si)

:IMyComponent

Set MasterComponents(baseComponent, slotPanel)

SetActiveView(IMyComponent)

SetSlotPanel(IMyComponent)


UC 206: Processar actualizações de valores oriundos do UCH

Figura 23 – Diagrama de Sequência Processar actualizações de valores oriundos do UCH

sd UC 206: Process Receiv ed Updat...

UrcHttpClient

(from Actors)

myUCHManager :

myUCHManager

UrcHttpClient fire an Event with Update Values from UCH

loop

[PathValue Exists]

ValuesReceived(ReadOnlyCollection<PathValue> values)

DefineValuesInMySocketLayer(PathValue pv)

PutValuesOnComponents(IMyComponent baseComponent , PathValue pv,bool recordKeyNotFound )

SetComponentsState(ControlPanel ActiveView);


48

4.5.4. Diagrama Classes

Esta secção visa a apresentação dos Diagramas de Classes elaborados, mas devido à sua

enorme quantidade, serão apenas apesentados os diagramas referentes ao Plugin Target

Discovery, ao Plugin Dynamic Target, mais concretamente ao seu namespace “base” e ao

namespace que contém a estrutura de dados que permite criar programaticamente um

componente genérico podendo posteriormente o componente ser utilizado para representar um

Socket Element na forma desse componente. Os restantes diagramas de classe encontram-se

no Anexo F referente ao Modelo de Dados (Data Model), existindo também uma pequena

secção referente ao Diagrama de Classes no Anexo C referente ao Relatório Técnico.




Figura 24 – Diagrama de Classes do Plugin Target Discovery


50


Figura 25 – Diagrama de Classes do Plugin Dynamic Target (namespace Meticube.UCH.DynamicTarget)



Figura 26 – Diagrama de Classes do Plugin Dynamic Target (namespace Meticube.UCH.DynamicTarget.

Target.UI.MyComponents)


52

4.5.5. Plano de Testes

O plano de testes a executar encontra-se definido no Anexo D. Este plano de testes visa

garantir que o sistema tem o comportamento esperado e que cumpre todos os requisitos

definidos.

4.6. Aspectos relevantes da implementação

Aqui abordam-se os aspectos considerados mais relevantes para uma melhor compreensão do

trabalho realizado, assim como se fundamentam as decisões tomadas durante o decorrer do

projecto Dynamic Target User Interface.

4.6.1. Plugins Target Discovery e Dynamic Target

No início do desenvolvimento do projecto foi necessário decidir como abordar a temática da

criação de uma User Interface de um Target. Para não se misturar os conceitos e fornecer uma

usabilidade intuitiva ao utilizador, e também para fornecer um meio de organizar os Targets

pelos vários tipos de UCH decidiu-se criar dois Plugins:

Plugin Target Discovery – Procura e lista os Targets do UCH e os seus descendentes do tipo

Dynamic Target na Tree View do ON.IT;

Plugin Dynamic Target – Representa um Target especifico do ON.IT e fornece mecanismos

(componentes) que o permitem controlar através do UCH, componentes esses gerados

dinamicamente;

Desta forma, consegue-se separar os Plugins que detectam os Targets de um UCH dos

Plugins que representam Targets específicos, podendo até representar os vários Targets de

diferentes UCH, podendo organiza-los consoante o UCH em causa, devido ao facto de um

Plugin Target Discovery estar sempre associado a um UCH e representar os Targets criados

na forma de Plugin Dynamic Target como seus filhos.



4.6.2. Arquitectura dos Plugins

Devido ao facto do projecto ter de ser desenvolvido na forma de Plugin para ON.IT, este teve

de seguir uma estrutura de modo funcionar de dentro da framework ON.IT.

Plugin Target Discovery

Este facto, para o Plugin Target Discovery levou à implementação da interface IEditor. A

implementação desta interface pelo Form Administration, leva a que seja possível abrir uma

janela de edição do Plugin, que deverá ser apresentada quando o mesmo é arrastado da zona

“Available Objects” para a zona “Tree View” ou quando se edita o Plugin.

Plugin Dynamic Target

Como o Plugin Dynamic Target deve ter uma janela de administração, de forma a editar as

suas propriedades, assim como o Plugin deve ser visível na Slot do ON.IT, tiveram de ser

implementadas as respectivas interfaces do ON.IT que permitissem efectuar essas

acções/funcionalidades, nomeadamente:

A interface IEditor para a janela de administração, e a interface IPlugin para a representação

do Plugin na Slot.

A framework ON.IT para apresentar a janela de administração de um Plugin ou a Slot,

procura no Assembly[23]

(dll) dos Plugins por estas interfaces e invoca-as dinamicamente utilizando

a Reflection do C#[14]

.

4.6.3. Princípios de Representação de um Target

Para representar um Target decidiu-se utilizar a sua Socket Description devido ao facto deste

representar os estados internos, variáveis e operações de um Target, constituindo um

elemento obrigatório de um Target. Este facto garante a compatibilidade do Plugin com

qualquer Target.


54

4.6.4. Representação Socket Elements (Componentes)

De forma a ser possível representar um Target optei por efectuar a representação de cada

Socket Element na forma de componentes (User Control), desta forma, por cada Socket

Element existente irá existir um componente. Cada componente representará visualmente um

Socket Element o que irá permitir efectuar operações sobre esse Socket Element (p.e.

representar e/ou alterar o seu valor, caso seja um Socket Element do tipo variável). De forma a

identificar cada componente e de forma a ser possível “chegar” até ele, o componente tem

associado o respectivo Path (caminho) do Socket Element (p.e. “/set1/var”). O facto de cada

elemento ser representado por um User Control acarreta vantagens a nível da facilidade de

modificação do componente pelo programador, que num ápice pode redefinir o aspecto

gráfico do componente utilizando Designer do Visual Studio[16]

.

4.6.5. Parsing Socket Description

Para representar os Socket Elements de uma Socket Description é necessário primeiramente

determinar quais são os seus Socket Elements, pelo que é necessário processar o ficheiro da

Socket Description e carrega-lo para um estrutura de dados, através da qual seja possível

extrair toda a informação necessária dos Socket Elements para construir os componentes. Este

processamento do ficheiro designa-se por Parse (conversão) da Socket Description para uma

estrutura de dados em memória, designada por Socket Instance. Para efectuar este parsing

optei por utilizar o mesmo sistema de Parsing definido no UCH, porque este é um processo

estável, maduro e extremamente testado, o que irá trazer um maior grau de confiança no

Parsing da Socket Description. A utilização desta Socket Instance promove também a

reutilização de código, visto ser trabalho desnecessário estar a recriar uma funcionalidade que

já se encontra implementada e que já deu provas do seu valor. É importante garantir que se

tem uma Socket Instance correctamente preenchida, pois esta é a base para a representação de

um Target e consequentemente dos seus componentes associados. A sugestão de utilizar o

mesmo sistema que o UCH foi bem aceite, pelo que a equipa do UCH prontamente forneceu o

respectivo código fonte associado. Foi necessário adaptar o código fonte de forma a conseguir

introduzi-lo no projecto, fazendo as devidas adaptações e complementando-o com funções de

conversão de Socket Elements para componentes.



4.6.6. Parsing Socket Description em Componentes

Numa primeira fase foi necessário descarregar a Socket Description do UCH e processá-la de

forma a preencher a Socket Instance, após este cenário, torna-se necessário determinar quais

os Socket Elements existentes e quais os componentes a utilizar, a este processo chama-se de

parsing da Socket Description em componentes. Todo este processo encontra-se representado

na Figura 27. Primeiro efectua-se um pedido ao UCH de forma a este devolver o ficheiro

XML que representa a Socket Description, sendo posteriormente efectuado o Parse da Socket

Description para uma estrutura de dados em memória (Socket Instance). Utilizando um

método recursivo são percorridos todos os elementos da Socket Instance sendo efectuada a

conversão (Parsing) desse elemento para um componente.

Figura 27 – Parse da Socket Description em Componentes

Desta forma o Parse dos Socket Elements seguem as regras definidas na Tabela 7 de forma a

seleccionarem os componentes a criar.


56

Socket

Element Condição do Socket Element Componente Por Defeito

Variable

Elemento com dimensão e do tipo

xsd:string

MyGenericDimension

Elemento com dimensão sem ser do

tipo xsd:string

MyGrid

Senão possuir dimensão e não

possuir XML Schema Restrictions[22]

Analisa o tipo do Componente e faz o

Parse avaliando o tipo XSD do Socket

Element tendo por base a Tabela 8.

Senão tiver dimensão e possuir XML

Schema Restrictions[22]

Se for enumeração tenta criar os

componentes pela seguinte ordem:

1. MyTrackBar

2. MyCombobox

Senão for enumeração:

1. MyTextBox

Set

Elemento com dimensão MyGenericDimension

Se for um índice da dimensão MyPanel

Se não tiver definido dimensão MySet

Command

Se for dimensão MyGenericDimension

Senão for dimensão e o comando

tiver parâmetros de entrada e saída

que não sejam referências (idRef)

MyCommandWithParameters

Senão for dimensão e não tiver

parâmetros (desde que não sejam

referências)

MyButton

Notify

Se for dimensão MyGenericDimension

Senão for dimensão MyNotify

Constant

- MyLabel

Tabela 7 – Regras de Parse dos Socket Elements em componentes



A Tabela 8 identifica os componentes que devem ser gerados tendo em consideração o tipo

XSD do Socket Element.

Tipo XSD Componente

por defeito Tipo XSD Componente por defeito

xsd:unsignedInt MySpin xsd:float MySpin

xsd:unsignedInt MySpin xsd:dateTime MyTextBoxDateTimeMask

xsd:unsignedLong MySpin xsd:date Date

xsd:unsignedShort MySpin xsd:time MyTextBoxDateTimeMask

xsd:unsignedByte MySpin xsd:duration MyTextBoxDateTimeMask

xsd:byte MySpin xsd:gYearMonth MyTextBoxDateTimeMask

xsd:short MySpin xsd:gYear MyTextBoxDateTimeMask

xsd:int MySpin xsd:gMonth MyTextBoxDateTimeMask

xsd:long MySpin xsd:gMonthDay MyTextBoxDateTimeMask

xsd:decimal MySpin xsd:gDay MyTextBoxDateTimeMask

xsd:integer MySpin xsd:anyURI MyTextBox

xsd:nonNegativeInteger MySpin xsd:hexBinary MyTextBox

xsd:positiveInteger MySpin xsd:normalizedStr

ing

MyTextBox

xsd:nonPositiveInteger MySpin xsd:string MyTextBox

xsd:double MySpin xsd:boolean MyCheckBox

Tabela 8 – Componentes por defeito analisando o tipo XSD

De forma a efectuar o parsing dos Socket Elements para componentes é necessário aceder ao

nó base da Socket Instance. A Socket Instance, como referido anteriormente, representa a

Socket Description através de uma estrutura de dados em memória. A distribuição dos

elementos (Socket Elements) pode ser vista, de como de uma árvore se trata-se, desta forma,

inicia-se a leitura do topo da árvore (nó base) e vai-se descendo a árvore. Quando se vai

descendo (efectuando a leitura da árvore) surgem nós que podem conter filhos, e quando esse


58

facto acontece, inicia-se a leitura desses nós até às suas folhas, ou seja, até não possuírem

mais descendentes, voltando posteriormente ao nó anterior e continuando a descer na árvore,

até todos os nós (Socket Elements) serem processados. A Figura 28 contém excertos da função

que efectua o Parse da Socket Description/Socket Instance para componentes. O argumento

de entrada da função socketElementsList, representa a lista de nós a ler. Para cada nó é

“seleccionado” o Socket Element correspondente, e posteriormente é gerado o componente

através desse elemento com a função GenerateComponent. O componente é adicionado ao seu

componente pai pelo método AddMyComponent. Para processar os nós filhos, como o caso do

SetElement, chama-se a mesma função (ParseSocketElementsToComponents) de uma forma

recursiva, colocando os seus descendentes como parâmetros de entrada.

private void ParseSocketElementsToComponents(List<AbstractSocketElement> socketElementsList,

string path)

{

for (int i = 0; i < socketElementsList.Count; i++)

{

AbstractSocketElement aSocketElement = socketElementsList.ElementAt(i);

(...)

IMyComponent newComponent = aSocketElement.GenerateComponent(path + "/" +

aSocketElement.Id, _uchAndSI.MyUCHManager, this._uchAndSI.SocketInstance);

(...)

if (baseComponent.CanAddComponentInside)

{

baseComponent.AddMyComponent(newComponent, null);

}

(...)

if (aSocketElement is SetElement)

{

SetElement set = (SetElement)aSocketElement;

ParseSocketElementsToComponents(set.SetElements, path + "/" +

aSocketElement.Id);

}

}}

Figura 28 – Excerto de código para efectuar o Parse para componentes



4.6.7. Componentes em memória

Os componentes em memória são guardados como se fossem uma árvore, como se pode ver

na Figura 29. Sendo que cada componente pode ter vários componentes filhos e assim

sucessivamente.

A pesquisa de cada componente é efectuada de forma recursiva.

Figura 29 – Representação de componentes em árvore

4.6.8. Arquitectura dos Componentes

A arquitectura dos componentes foi desenhada de forma a permitir facilmente criar novos

componentes que representem Socket Elements. Desta forma, torna-se possível

personalizar/criar facilmente os componentes disponíveis no Plugin Dynamic Target o que

torna o Plugin ainda mais flexível e escalável, a nível dos componentes que pode

disponibilizar ao utilizador.

Para o efeito definiu-se a interface[21]

IMyComponent. A implementação desta interface

representa cada componente, no entanto foi também necessário criar outras interfaces de

forma a acrescentar funcionalidades/operações especiais aos componentes, pelo que estas

novas interfaces têm de ser usadas em conjunto com a interface IMyComponent. Tem-se um

exemplo concreto da necessidade de acrescentar funcionalidades aos componentes na

representação de dimensões/índices de um Socket Element dentro de um componente,

existindo para o efeito as interfaces IGenericDimension (secção 4.6.8.4) e IDimensionGrid


60

(secção 4.6.8.5). Existem ainda as interfaces IScrollPanel (secção 4.6.8.2) e ISet (secção

4.6.8.3). Todas as interfaces encontram-se devidamente explicadas nas respectivas secções.

4.6.8.1. IMyComponent

A interface[21]

IMyComponent define a base/esqueleto de um componente, sendo que todos os

componentes têm que implementar esta interface. O facto de um componente ser representado

por um User Control permite separar a parte gráfica/visual de um componente da sua parte da

lógica. Desta forma a criação de um componente é muito simples bastando seguir os moldes

dos componentes anteriores.

4.6.8.2. IScrollPanel

A interface[21]

IScrollPanel representa um componente que contém barras de scroll (barras de

deslocação). A utilização desta interface é utilizada para representar o elemento Set, que

aglomera um conjunto de componentes filhos, permitindo assim a sua fácil colocação no

Painel de Controlo do ON.IT. É exemplo deste componente o MyPanel.

4.6.8.3. ISet

A interface[21] ISet representa um componente que é utilizado para fazer a ligação (link) para

outro componente. Exemplo do componente MySet.

4.6.8.4. IGenericDimension

A interface[21]

IGenericDimension quando aplicada a um componente identifica que este irá

conter no seu “interior” as representações das outras dimensões/índices, irá conter portanto

vários componentes por cada dimensão.

Exemplo: Supondo que se tem os seguintes elementos: “/set[1]/var” e “/set[2]/var”

Existirá um componente com o endereço “/Set” que será do tipo IGenericDimension e dentro

deste componente existirão os componentes “/set[1]” e “/set[2]” e cada um deles com o

respectivo componente “var”, como se pode ver na Figura 30. A nível de código temos um

exemplo da utilização deste componente no User Control MyGenericDimension.



Figura 30 – Conceito IGenericDimension

4.6.8.5. IDimensionGrid

A interface[21]

IDimensionGrid quando aplicada a um componente representa as várias

dimensões desse componente numa Grid (tabela), portanto num único componente e não em

vários componentes. Exemplo do User Control MyGrid.

Na Figura 31, podemos visualizar uma representação prática deste componente (MyGrid) e

podemos observar que apenas existe um componente, o elemento “/set”, sendo este

representado na forma de tabela (grid) apresentando o valor das dimensões na respectiva

célula. Na figura da esquerda para a direita, primeiro tem-se a representação de um

componente “/set” com uma dimensão, depois com a representação de duas dimensões e

posteriormente a representação do componente com três dimensões (sendo esta representação

seguida em casos em que o elemento tenha mais de três dimensões).

Figura 31 – Conceito DimensionGrid


62

4.6.9. Serialização

Inicialmente a serialização, que consiste na operação de guardar componentes em XML como

forma de persistência de dados, tinha sido definida utilizando um método totalmente genérico,

utilizando a reflexão[14]

do C# que permite identificar as propriedades, atributos e funções de

uma classe num Assembly[23]

mas esta serialização demorava muito tempo de execução (cerca

de 25-40 segundos a serializar e cerca de 20 segundos a desserializar 75 componentes).

Optou-se portanto por serializar de forma mais específica e concreta definindo estaticamente

quais as propriedades a serializar.

A serialização é efectuada componente a componente, percorrendo cada um dos seus nós

(componentes e seus componentes filhos). Cada componente é serializado na forma de XML.

Primeiro, serializando as suas propriedades estaticamente como representado na Figura 32,

sendo este método executado recursivamente para todos os componentes e guardado nas

propriedades (Extended Properties) do Plugin Dynamic Target.

(...)

writer.WriteStartElement("Adaptation");

writer.WriteString(component.Adaptation.ToString());

(...)

Figura 32 – Excerto de Código de serialização estática da propriedade de um componente

A desserialização consiste no processo inverso ao da serialização, ou seja, transformação dos

dados dos componentes previamente guardados na forma de XML, de forma a carregar para

memória os componentes serializados, mantendo assim os componentes tal e qual como

existiam anteriormente. Para efectuar esta desserialização dos componentes é necessário obter

o XML que contém a serialização dos componentes. O Navigator é semelhante a um ponteiro

e que aponta para um nó. Para navegarmos através do XML percorre-se uma árvore XPath

apontando o Navigator para o nó a ser processado. Quando o nó identifica o início de um

componente é criada uma instância do mesmo através do método Activator sendo

posteriormente inicializado o componente através do método Start, e posteriormente são

preenchidas as propriedades do componente com o definido no XML através da função

SetProperty. A Figura 36 contém um excerto do código para efectuar a desserialização do

componente.



(...)

Type myComponentType = Type.GetType(myComponentTypeName);

myComponent = (IMyComponent)Activator.CreateInstance(myComponentType);

myComponent.Start(componentPath, _refToControlPanel.UCHManager,

_refToControlPanel.Socket_Instance);

(...)

if (string.Compare(nav.Name, "ComponentsInside", StringComparison.Ordinal) != 0)

{

SetProperty(myComponent, nav.Clone());

}

(...)

Figura 33 – Excerto de Código para desserializar um componente

Para efectuar a desserialização as propriedades de um componente é efectuada a leitura dos

nós filhos (contém as definições dos tipos para cada propriedade), esses nós filhos são

passados para um XML Deserialize que trata de desserializar os dados. Tendo os dados

extraídos temos que os colocar nos respectivos componentes, este processo é efectuado

através de reflexão[14]

obtendo a propriedade do componente através da variável pi e

definindo-a pelo método SetValue.

private void SetProperty(IMyComponent myComponent, XPathNavigator nav)

{

(...)

XmlReader propertyDefinitions = nav.ReadSubtree();

object propertyValue = deserializer.Deserialize(propertyDefinitions);

(...)

PropertyInfo pi = myComponent.GetType().GetProperty(myComponentProperty.Name);

pi.SetValue(myComponent, propertyValue, null);

(...)

}

Figura 34 – Excerto de Código para desserializar as propriedades de um componente


64

4.6.10. Comunicação com o UCH

A iteração/comunicação com o UCH é efectuada através de um módulo independente

desenvolvido pelo estagiário. Este módulo define métodos que permitem a comunicação com

o UCH, como aceder ao canal de updates (utilizado para receber as alterações de estados de

um Target através do UCH), a possibilidade de enviar pedidos ao UCH para definir o valor de

uma variável, pedidos para invocar comandos entre outros.

Foi necessário desenvolver este módulo de suporte devido ao facto de terem sido

desenvolvidos dois Plugins, o que levou à criação deste módulo auxiliar, de forma a não

duplicar código e a fornecer um suporte nas comunicações com o UCH. Este módulo poderá

ser mesmo útil em novos projectos que envolvam o UCH, visto que reúne um conjunto de

funcionalidades genéricas para interagir com o UCH, como por exemplo invocar um comando

de um Target no UCH.

Este módulo assenta sobre uma biblioteca de comunicação com o UCH desenvolvida pela

Meticube, sendo esta biblioteca responsável por fornecer os métodos que permitem aceder ao

UCH (p.e. método de ligação (connect) com o UCH).

4.6.11. Processamento de dependências

Para a apresentação correcta dos componentes é necessário processar as suas dependências

em run-time. Estas dependências permitem avaliar se um componente deve ser ou não

visualizado, se é possível interagir com ele, ou mesmo se é possível alterar o seu valor.

Representam portanto condições especiais que necessitam de ser verificadas/validadas de

forma a permitir ou não efectuar algumas acções sobre um Target.

Para efectuar este processamento de dependências é necessário guardar o estado interno do

Target, isto é, guardar as variáveis, os estados dos comandos, estados das notificações entre

outros. Este processo é necessário porque a biblioteca de ligação ao UCH não permite

obter/calcular os valores de processamento de dependências, pelo que uma solução teve que

ser encontrada. Esta solução consistiu em armazenar internamente o estado de cada Target de

forma a evitar sobrecarregar o UCH com pedidos de obtenção de dados desnecessários e a

utilizar estes dados internos para efectuar um processamento de dependências. Este

processamento de dependências foi implementado de forma a reaproveitar os métodos de

armazenamento de dados e de processamento de dependências existentes na Socket Instance.



A Figura 35 contém um excerto de código utilizado para guardar um estado interno de um

Target dentro da Socket Instance do Plugin Dynamic Target.

private void DefineValuesInMySocketLayer(PathValue pv)

{

(...)

i2home.UCH.Utils.PathValue pathvalue = new

i2home.UCH.Utils.PathValue(pv.Path, pv.Value);

this._refToPanelForm.Socket_Instance.UpdateSocketState(pathvalue);

(...)

}

Figura 35 – Excerto de Código que para manter estado interno de um Target no Plugin Dynamic Target

Exemplo de dependência

<relevant>not(value('signedIn'))</ relevant>

Uma dependência pode ser encarada como uma restrição, consistindo numa expressão que

pode referir/avaliar outros elementos da Socket Description mediante o seu valor.

A expressão desta dependência consiste no “not(value('signedIn'))” sendo o “signedIn” uma

variável (Variable Element) do tipo booleano. Como significado desta expressão temos que o

elemento associado a esta restrição apenas deve ser visível se o valor da variável “signedIn”

for falso.

a) Validação dos Inputs dos componentes

Consoante o definido nas várias restrições, quer a nível das dependências definidas no

standard do URC quer a nível de XML (p.e. uma variável ser dever ser do tipo enumeração,

ou uma variável não permitir certo tipo de dados). Para processar este tipo de entradas

invoca-se o método ChangeRequest() sobre a Socket Instance que irá validar se dado input de

uma variável é valido, fornecendo para o efeito o caminho da para o Socket Element

referenciado pelo seu Path, e posteriormente irá processar todas as dependências do elemento

de forma a verificar se dada entrada de dados é valida.


66

(...)

validValue =

_myComponentProperties.SocketElement.ChangeRequest(_myComponentProperties.Path,

value);

(...)

Figura 36 – Excerto de Código que validar o input de uma variável

A Figura 37 representa um caso em que o conteúdo inserido no componente não é valido, isto

porque foi introduzido no componente o valor “op1d” e na Socket Description está definido

que o elemento “deviceState” representa uma enumeração com os valores “op1” e “op2”, pelo

que o processamento desta dependência deve apresentar um aviso visual devido ao facto do

conteúdo do componente ser inválido.

Figura 37 – Validação Input Componente

b) Validação de interacções/alterações

Uma das dependências existentes é utilizada para avaliar se um componente deve permitir

alterações aos seus dados em run-time, se deve permitir executar um comando. Esta

dependência na Socket Description encontra-se identificada nos Socket Elements com as Tags:

<Write>...</Write>

O resultado da avaliação deste tipo de dependências identifica se um componente deve estar

activo ou inactivo.

A Figura 38 contém o método responsável pelo processamento da dependência, este método

recebe qual o tipo de dependência a avaliar (neste caso uma dependência do tipo WRITE) e o

caminho para o seu Socket Element. Portanto, este processamento inicia-se identificando qual



o Socket Element a processar, através do seu caminho (path), que por sua vez irá identificar a

dependência do tipo WRITE do elemento e por fim reunindo e processando toda a informação

necessária para validar/processar a dependência.

(...)

result =

(bool)this._refToPanelForm.Socket_Instance.GetDependencyEvaluation(Definitions.DEPENDENCY_WRITE,

path);

(...)

Figura 38 – Excerto de Código avaliar uma dependência do tipo WRITE

c) Validação da visibilidade

Uma outra dependência que importa validar consiste em verificar se um componente deve ser

visível ao utilizador. Na Socket Description esta dependência encontra-se identificada nos

elementos com as Tags:

<relevant>...</ relevant>

O resultado da avaliação deste tipo de dependências identifica se um componente deve estar

activo ou inactivo.

A Figura 39 contém um pequeno excerto de código responsável pela validação da

dependência do tipo RELEVANT, o processo é o mesmo que o identificado na alínea

anterior.

(...)

result = (bool)this._refToPanelForm.Socket_Instance.GetDependencyEvaluation(Definitions.

DEPENDENCY_RELEVANT, path);

(...)

Figura 39 – Excerto de Código avaliar uma dependência do tipo RELEVANT

4.6.12. Ordenação dos Componentes

Os componentes gerados têm de ser colocados num painel e a sua localização espacial tem de

ser definida. Sendo assim, foram definidos métodos recursivos para gerar as localizações

espaciais dos componentes, assim os componentes são colocados num “painel” por ordem de

leitura dos “nós” caracterizados por Socket Elements. Os componentes inicialmente são

colocados verticalmente de forma equidistante. Existe ainda uma outra forma de ordenação

dos componentes, em modo de execução, que ignora a localização por omissão dos


68

componentes e reorganiza-os, isto apenas para os componentes que se encontrem visíveis no

painel, sendo assim, os componentes são colocados pela sua ordem de visibilidade.

Na Figura 40, podemos observar os dois modos de disposição dos componentes no “painel”, a

Vista do Utilizador 1 e a Vista do Utilizador 2. Na Vista 1, o utilizador visualiza os

componentes na sua localização original (como na “Distribuição de Componentes”) e na Vista

2 a posição original dos componentes é ignorada, sendo definidas novas localizações para os

componentes, seguindo uma abordagem top-down (verticalmente de cima para baixo),

mantendo-se equidistantes verticalmente, ignorando (não representando) os componentes

“invisíveis”.

Figura 40 – Organização Espacial Componentes

4.6.13. Modo de Edição

De modo a proporcionar uma experiência de utilizador mais intuitiva e simples, e de forma a

ser mais perceptível pelo utilizador quais as opções que pode exercer sobre um componente,

decidiu-se criar um “modo de edição” dos componentes, representado pela Figura 41. Assim

sempre que o “modo de edição” é activo, serão apresentadas as suas opções de configuração

como podemos ver identificado na figura.



Podem ser disponibilizadas as seguintes opções:

Enviar/Mover para a Slot

Alterar o componente

Mover o componente

Figura 41 – Exemplo modo de edição

a. Enviar/Mover para a Slot

Enviar um componente para a Slot consiste em representar um componente do painel de

controlo também na Slot. Como um componente no painel de controlo pode ter sofrido

alterações (p.e. nome diferente), para “copiar” um componente para a Slot, utilizou-se as

funções de serialização. Serializando o componente e depois desserializando-o garante-se que

o componente é igual ao original. Visto que programaticamente não é possível copiar um

User Control, esta solução garante sempre que o componente é igual ao original, evitando

estar a criar mais uma classe de cópia que teria de ser diferente de componente para

componente. Este modo de copiar componentes é especialmente útil quando nos encontramos

no âmbito das “dimensões” visto que também copia os componentes gerados em run-time

devido à adição também em run-time de dimensões.

b. Trocar um componente por um compatível

Visto que um componente representa um Socket Element, quando pretendemos trocar um

componente por outro, o que realmente se pretende é arranjar um componente que consiga

também representar o mesmo Socket Element. Por este motivo, quando seleccionamos a

opção alterar componente é apresentada uma lista de componentes compatíveis. A lista de

componentes compatíveis é gerada da seguinte forma:

1. Procurando dentro do Assembly[23] (dll do Plugin Dynamic Target) os tipos (“classes”) que

implementem a interface IMyComponent (todos os componentes para serem considerados

componentes, têm obrigatoriamente de implementar esta interface).

2. Utilizando a Reflection do C# é instanciado esse tipo (“classe”).


70

3. Após invocar o método Start() inicia-se o Parse da Socket Description para o respectivo

componente, se o Parse falhar, significa que o componente não é compatível para o

Socket Element, se tudo correr bem o componente é adicionado à lista de componentes

compatíveis. A Figura 42 contém o excerto de código responsável por este processo.

foreach (Type t in Assembly.GetCallingAssembly().GetTypes()) {

if (t.GetInterface("IMyComponent") != null && t.IsInterface == false)

{

(...)

IMyComponent myComponent =

(IMyComponent)Activator.CreateInstance(t);

myComponent.Start(path, uchManager, si);

if (myComponent != null)

allowedComponents.Add(myComponent);

} (...)

}

Figura 42 – Excerto de Código para instanciação de Componentes

Quando ocorrer a substituição do componente original pelo novo componente, é preciso ter

cuidado, pois muito provavelmente terá dimensões diferentes do componente original, pelo

que é necessário manter a mesma distância entre componentes que existia originalmente. Este

procedimento é o mesmo procedimento seguido quando se substituiu um componente (secção

4.6.14).

c. Mover componente

Para mover (deslocar) um componente foi introduzido uma opção que permite deslocar o

componente tendo em conta o offset (deslocamento) do rato com a posição do componente

actual. A implementação da deslocação dos componentes teve de ser cuidadosa, para não se

sobreporem componentes. Para o efeito é verificado se um componente sobrepõe outro,

acendendo a todos os descendentes do componente pai do componente em deslocação. Mas

esta verificação não é tão simples como parece visto que as posições dos componentes são

alteradas automaticamente consoante o offset (deslocamento) das barras de scroll (barras de

deslocamento) do Painel de Controlo, pelo que esta verificação tem sempre que considerar a



posição dos componentes mais o offset das barras de deslocamento, caso contrário estaríamos

a comparar posições erradas.

4.6.14. Trocar de posição do componente

Visto que o utilizador pode querer mudar a ordem pela qual os componentes devem aparecer

no painel de controlo, foi dada a possibilidade ao utilizador de definir esta ordem, em vez de

mover um componente de cada vez.

O aspecto mais importante desta implementação baseia-se no cálculo das distâncias originais

entre cada componente. Quando dois componentes trocam a sua ordem é mantida a distância

que o componente original mantinha com o componente anterior. Este aspecto é crucial

porque os componentes podem ter dimensões diferentes, e pode-se estar a trocar um

componente maior por um mais pequeno, ou vice-versa, pelo que tem que se garantir que

todos os componentes se encontram correctamente colocados no painel de controlo e à mesma

distância que cada posição de cada um deles mantinha.

4.6.15. Receber Valores do UCH

De forma a receber os dados (valores) oriundos do UCH, quer por via do canal de updates

(p.e. quando um ou mais valores do Target são alterados, como a alteração do valor de uma

variável sem ter sido modificada pelo Plugin Dynamic Target), quer para obter os valores de

um dado Socket Element. Estes valores têm de ser colocados nos respectivos componentes,

desta forma, foi criada uma função destinada a processar todos os valores oriundos do UCH.

Cada um dos valores recebidos é sempre referente a um Socket Element e vem identificado

com uma operação (Set, Add ou Remove), sendo que cada uma destas operações identifica o

que “efectuar” com o valor recebido.

a. Set

A operação Set define que dado valor deve ser colocado no respectivo componente

identificado pelo seu caminho (path). Portanto, quando um valor é recebido através do UCH,

primeiro identifica-se o componente em causa através do seu caminho utilizando um função

recursiva de procura de componentes, que deve remover as dimensões de estado (p.e. definir o

valor de um comando pode vir acompanhado com a definição do seu estado) e posteriormente

definindo no componente o valor recebido.


72

b. Add

Quando uma operação do tipo Add é recebida significa que uma nova dimensão irá ser

adicionada ao componente referenciado pelo seu caminho. Considerando que se recebe uma

operação de Add para o caminho “/set[1]/group[a]/var” com o valor “5”. Para processar este

caminho (path) tem de se seguir o seguinte processo:

1. Remover as dimensões do componente, ficando com o caminho “/set/group/var”

2. Determinam-se todos os componentes pais, neste caso, “/set[1]” e “/set[1]/group[a]” e

“/set/group/var”

3. Itera-se em cada componente pai

3.1. Se o Socket Element “/set[1]” for do tipo IDimensionGrid

a) Todas as dimensões são apresentadas num único componente (p.e. numa tabela) e

então é chamada o método para definir o valor “5” no componente, este método

internamente tratará de adicionar as dimensões necessárias ao componente (neste

caso, adicionando linhas e colunas que identificassem as dimensões como de uma

tabela se tratasse).

3.2. Se o caminho/componente “/set[1]” não for IDimensionGrid e o componente não existir

a) Cria o novo componente e adiciona-o ao componente que contém todas as

dimensões “/set”, sendo adicionadas os índices à lista do componente

3.3. Volta-se a repetir o ponto 3.1. substituindo pelo componente pai seguinte (para a sugunda

iteraccao o “/set[1]/group[a]” e para terceira iteraccao “/set[1]/group[a]/var”) e volta-se a

repetir a iteração até acabarem os componentes pais

3.4. Quando as iterações terminarem é definido o valor “5” no ultimo componente

c. Remove (dimensões)

Quando uma operação do tipo Remove é recebida, significa que é necessário eliminar

determinada dimensão, dito de outra forma, significa que temos que eliminar um componente

que tinha sido gerado anteriormente (através da operação Add). Esta prática implica procurar

recursivamente todos os componentes que representem esta dimensão.

4.6.16. Problema Cross-thread operation

Durante o desenvolvimento do Plugin Dynamic Target, sempre que o UCH efectuava o envio

das actualizações dos elementos do Target pelo canal de updates (p.e. actualização do valor

de uma variável), era necessário definir os novos valores dos Socket Elements nos respectivos

componentes. Mas esta operação falhava sempre com o seguinte erro: “General Exception:

System.InvalidOperationException: Cross-thread operation not valid: Control … accessed

from a thread other than the thread it was created on”. Este erro devia-se ao facto dos updates



do UCH serem recebidos através de um evento[17]

e sempre que um evento é invocado, este é

executado numa thread diferente, desta forma, quando se tenta mudar o valor de um

componente pelo UCH (recebendo um valor pelo canal de updates), está-se a tentar mudar o

valor através de uma thread diferente daquela que criou o componente. A solução encontrada

encontra-se representada na Figura 43. Este processo passa por verificar se o componente

precisa de um Invoke, verificando esta condição através do InvokeRequired (verificar se as

operações sobre o componente vão ser efectuadas sobre a mesma thread ou através de uma

thread diferente). Se a troca do valor for efectuada pela mesma thread, então altera-se o

normalmente o valor chamando a função para o efeito, caso contrário terá de se invocar o

método através de um delegate anónimo[18]

representado pelo método ComponentInvoke().

Este processo para alterar o valor dos componentes ou efectuar qualquer outra operação sobre

os componentes é necessário sempre que se tente efectuar operações sobre o componente em

threads diferentes daquelas que o criaram, desta forma para solucionar o problema segue-se a

abordagem definida na Figura 43.

if (component.ComponentInvokeRequired)

{

component.ComponentInvoke(new ThreadStart(delegate

{

component.ChangeFromUCH(value, path);

}));

}

else

{

component.ChangeFromUCH(value, path);

}

Figura 43 – Excerto de Código para evitar Cross-thread operation


74

4.6.17. Aspecto gráfico Plugins e Componentes

Nesta secção serão apresentadas algumas imagens de forma a melhor se compreender os

conceitos descritos. A Figura 44, apresenta a Janela de Administração do Plugin Target

Discovery, onde podemos observar o IP e Porta do UCH, assim como os Targets existentes

no UCH.

Figura 44 – Target Discovery Plugin



Na Figura 45 observa-se na Tree View do ON.IT (seta verde) o Plugin Dynamic Target

referente ao Target Generic Target Chain AC Dummy e no Painel de Controlo do ON.IT (seta

do lado direito) observa-se a interface de utilizador (User Interface) gerada dinamicamente de

forma representar os estados do Target, assim como fornecer os mecanismos para interagir

com o Target através do UCH.

Figura 45 – Dynamic Target para o Target Generic Target Chain AC Dummy


76

A Figura 46 representa parte de uma interface de utilizador gerada dinamicamente para o

Target “Generic Target Chain AC Dummy”. Cada componente gerado representa

graficamente um Socket Element da Socket Description. Através de cada componente é

possível interagir com um Target, de forma a controla-lo, assim como é possível observar o

seu estado interno (p.e. visualizar a temperatura ambiente) e receber “actualizações” do estado

do mesmo caso existam.

De frisar ainda a Barra superior do Painel de Controlo, identificando da esquerda para a

direita os Botões:

Opções/Modo Edição – os componentes apresentam opções sobre eles, como modificar Label

do componente, alterar componente, deslocar componente, mostrar componente na Slot.

Organização dos Componentes – Através desta opção é definida como as restrições de

Modificação e Visibilidade devem ser aplicadas aos componentes.

Mudar Ordem Componentes – Altera a ordem dos componentes

Configurações – permite configurar algumas das opções do Plugin, como por exemplo se deve

validar o input dos componentes.

Figura 46 – User Interface gerada no Plugin Dynamic Target para o Target Generic Target Chain AC Dummy



Na Figura 47, visualiza-se o Painel de Controlo referente a um Plugin Dynamic Target e

observa-se que os componentes do Plugin se encontram no modo de edição, pois cada

componente do Painel de Controlo possui as opções realçadas pela seta da figura. Estas

opções permitem mover o componente para a Slot do ON.IT, alterar o componente por outro

tipo (p.e. trocar componente MyTextBox pelo componente MyTextBoxMultiLine), trocar o

nome da Label do componente ( p.e. trocar o texto de Label “deviceMode” por “Label Device

Mode Alterada” e por fim a opção mover o componente que o permite a movimentação

espacial do componente utilizando o rato.

Figura 47 – User Interface em Modo de Edição


78

Na Figura 48 pode-se observar um componente na Slot (representado pela seta), pode-se

observar que o componente existente no Painel de Controlo aparece agora também na Slot do

ON.IT.

Figura 48 – Componente na Slot

A Tabela 9 apresenta uma listagem com a respectiva representação dos componentes criados

para representar os Socket Elements da Socket Description. As imagens dos componentes e o

seu conteúdo (valor) são utilizadas apenas para dar uma ideia dos componentes gerados, pois

as imagens foram retiradas de Targets concretos e a representação de cada componente pode

variar de Target para Target e de componente para componente.

Componente Imagem Notas

MyButton

Representa Command Element sem

parâmetros de entrada e/ou saída.

MyCheckBox

Representa um Socket Element do

tipo Variable, sendo do tipo

Booleano.



MyComboBox

Por norma representa um Socket

Element do tipo Variable em que o

seu XML Simple Type[10] [11]

seja

uma enumeração.

MyCommandWi

thParameters

Na figura pode-se observar 3

componentes utilizados como input

(entrada) para a execução de um

comando (Command).

Este tipo de componente representa

os parâmetros de entrada e de saída

necessários para a execução do

comando.

MyDate

Quando seleccionado apresenta um

calendário na forma de popup que

permite escolher a data e hora.

MyGenericDime

nsion

Pela figura observa-se que este

elemento da Socket Description

apenas contém 1 dimensão (Key 0

na figura) e pode-se observar os

respectivos componentes gerados

mediante o definido na Socket

Description do Target.

Este elemento implementa a

interface IGenericDimension.


80

MyGrid

Este componente implementa a

interface IDimensionGrid, portanto

refere-se à representação de um

componente apenas com dimensões

do tipo string.

MyLabel

Apresenta conteúdo estático

definido na Socket Description

como elemento Constant, no

presente caso o “const”.

MyNotify

A figura apresenta uma notificação.

No caso da figura representa uma

notificação do tipo Alert (alerta).

MyPanel

Não possui imagem associada porque o MyPanel agrega todos os

componentes, e apenas esses componentes são visíveis. Este componente

implementa a interface IScrollPanel.

MySet

Este componente implementa a

interface ISet e funciona como

o Link para um conjunto de

componentes representado pelo

componente MyPanel.

MySpin

MyTextBox

MyTextBoxDate

TimeMask

Apresenta uma “mascara” de

forma ao utilizador introduzir



os elemento do tipo data como

o pretendido.

MyTextBoxMult

iLine

MyTrackBar

Tabela 9 – Lista de Componentes Disponíveis

4.6.18. Testes Unitários

Durante o desenvolvimento do projecto foram desenvolvidos testes unitários que ajudaram e

muito a resolver problemas que iam surgindo no código existente pela adição de novas linhas

de código, quer por alterações a código já existente. Um bom exemplo desta ajuda encontra-se

nas funções recursivas de ordenação dos componentes, pois são funções complexas e uma

pequena alteração pode colocar os componentes no local errado, podendo o erro ser de difícil

detecção/rápida identificação.

Para a realização de testes unitários utilizou-se a ferramenta de testes unitários do Visual

Studio 2010. Para testar os dois Plugins foram criados um conjunto de testes unitários que

visam testar o bom funcionamento dos Plugins desenvolvidos, comparando o resultado obtido

com o resultado esperado. Desta forma foi possível testar os métodos exaustivamente e

comparar se algum dos testes falhava, e quando falham procedia-se à sua correcção.

Na Figura 49 são apresentados os resultados dos testes unitários e se pode observar todos os

testes passaram com sucesso.


82

Figura 49 – Resultados Testes Unitários



A Figura 50 contém um teste unitário do método de remover de um componente Pai.

[TestMethod]

public void RemoveComponent()

{

ControlPanel cp = _scenario.ControlPanel;

int countChild=cp.MasterComponents.BaseComponent.ComponentsInside.Count;

IMyComponent parent = cp.MasterComponents.BaseComponent;

IMyComponent componentToRemove =

cp.MasterComponents.BaseComponent.ComponentsInside.Values.ElementAt(0);

ComponentUtils.RemoveComponent(parent, componentToRemove);

if (parent.ComponentsInside.ContainsValue(componentToRemove) == true)

{

Assert.Fail("The component still exist in the parent

ComponentsInside");

}

else

if (((Control)parent).Controls.Contains((Control)componentToRemove) ==

true){

Assert.Fail("The component still contains the control in the

parent");

}

else

if (parent.ComponentsInside.Count != countChild-1)

{

Assert.Fail("The component must have exacly less one element");

}

}

Figura 50 – Excerto de um Teste Unitário


84

4.6.19. Testes Funcionais

Esta fase de testes segue o Plano de Testes definido na secção 4.5.5, sendo o resultado

apresentado na Tabela 10, e encontrando-se toda a informação sobre o resultado do plano de

testes no Anexo E.

Estes testes são de elevada importância pois verificam se a aplicação cumpre os requisitos e se

estes estão de acordo com o esperado, contribuindo assim verificar a qualidade do

produto/projecto.

Testes de

Aceitação Descrição Estado Comentários

AT101 Listar Targets. Passou

AT102 Criar Plugins Dynamic Target por cada Target

seleccionado

Passou

AT103 Filhos do Painel do Plugin Target Discovery devem

estar seleccionados na Lista de Targets.

Passou

AT104 Adicionar um novo Dynamic Target Plugin a um

Plugin Target Discovery existente.

Passou

AT105 Alterar definições do UCH do Plugin Target

Discovery.

Passou

AT201 Verificar a User Interface gerada dinamicamente

para um Target.

Passou

AT202 Verificar a User Interface guardada (serializada). Passou

AT203 Verificar dados dos componentes. Passou

AT204 Verificar restrições de visibilidade e de modificação

dos valores dos componentes.

Passou

AT205 Verificar interacção/comunicação com o UCH Passou

AT206 Mover/Deslocar Componente Passou

AT207 Mover componente para a Slot; Passou



AT208 Remover componente da Slot; Passou

AT209 Alterar Label de um componente Passou

AT210 Componentes compatíveis; Passou

AT211 Substituir Componente por outro compatível. Passou

AT212 Adapta a forma de apresentar os componentes de

acordo com a sua visibilidade e restrições (Consider

restrictions and adjust components locations).

Passou

AT213 Activar “modo de edição/opções” quando opção

“Consider restrictions and adjust components

locations” se encontra activa.

Passou

AT214 Verificar forma de apresentar os componentes

adaptando de acordo com as suas restrições

(Consider restrictions and hide invisible).

Passou


adaptando de acordo com as suas restrições

(Consider invisible components as readonly).

Passou


adaptando de acordo com as suas restrições (Don’t

consider visible and readonly restrictions).

Passou

AT217 Modificar a ordem do componente. Passou

AT218 Verificar janela de administração (Dynamic Target

Plugin).

Passou

AT219 Alterar Propriedades/ definições do Plugin Dynamic

Target

Passou

AT220 Apresentar informação de que se encontra

desconectado do Target.

Passou O UCH demora cerca de

três minutos a notificar o

Plugin quando um Target

é

descartado/desconectado;


86

AT221 Salvar alterações Passou

Tabela 10 – Resultado Plano de Testes

4.7. Actividades Extra

Durante o decorrer do estágio foram realizadas algumas tarefas de monitorização e avaliação

do trabalho desenvolvido que não se encontram directamente associadas ao estágio.

4.7.1. Relatórios Quinzenais

Quinzenalmente eram apresentados relatórios sobre as tarefas desenvolvidas nessas duas

semanas ao gestor de projecto de forma ao mesmo poder monitorizar o nosso progresso,

podendo esses relatórios serem consultados no Anexo H.

4.7.2. Apresentações Internas

No decorrer do estágio foram realizadas duas apresentações internas de forma a apresentar as

tarefas e progresso efectuado. Estas apresentações estavam abertas a todos os colaboradores

da empresa, mas tinham foco no CEO da Meticube e na restante equipa do projecto

URC4ALL, numa última fase para apresentar ao Departamento Comercial e Marketing o

projecto Dynamic Target User Interface.

4.7.3. Criação de Vídeo de Marketing

Através de uma das reuniões internas da empresa surgiu a ideia da criação de um Vídeo de

Marketing (Anexo L). O objectivo deste vídeo seria o de divulgar e promover o produto

desenvolvido, desta forma, conseguir-se-ia promover o projecto desenvolvido, como as suas

tecnologias envolventes, como UCH e ON.IT. Além de ser uma excelente forma de

demonstrar as funcionalidades e potencialidades do projecto.



Capítulo 5

Trabalho Futuro

O projecto Dynamic Target User Interface desenvolvido ao longo do corrente estágio permite

a descoberta de Targets (dispositivos), assim como, permite a criação automática de uma

interface de utilizador que permita controlar um dado Target/dispositivo através do UCH.

Como a criação de uma interface de utilizador é um processo totalmente dinâmico com base

num documento XML chamado de Socket Description, o sistema não consegue inferir qual a

utilidade do Target e/ou estados do Target, desta forma é normal que ao longo do tempo

sejam identificadas novas necessidades e/ou melhoramentos.

De seguida apresentam-se algumas propostas/ideias de trabalho futuro, de forma a evoluir o

trabalho já realizado.

5.1. Detectar Alterações na Socket Description

Detectar as alterações sobre a Socket Description sobre um Plugin Dynamic Target que

represente esse Target, com uma interface de utilizador já definida.

No presente projecto decidiu-se não proceder à detecção de alterações na Socket Description

de um Target, pois a detecção de alterações de uma Socket Description é algo que tem

imensas implicações, quer na forma de detecção das alterações quer na forma como as

alterações seriam implementadas. A detecção de alterações sobre a Socket Description

representaria uma tarefa morosa que demoraria muitos meses, pois a sua detecção podia ir

desde um simples espaço à alteração de um elemento, à alteração de uma variável, à troca de

posição dos elementos, à alteração apenas das suas descrições e à alteração a qualquer outro

pormenor.

Esta funcionalidade numa fase posterior ao projecto faz todo o sentido ser implementada,

apesar de ser uma característica que enriqueceria o projecto actualmente, a implementação

desta funcionalidade levaria muitos meses a desenvolver, pelo que iria levar à não

implementação de algumas funcionalidades mais importantes. Desta forma, foi decidido que

na existência de alterações da Socket Description, estas teriam de ser comunicadas e uma

nova interface de utilizador teria de ser gerada de raiz.


88

5.2. Integrar o UCH Cascading

O presente projecto detecta os Targets/dispositivos de um dado UCH, seria interessante

integrar o presente projecto com o projecto UCH Cascading (fruto de um estágio curricular

que decorreu ao mesmo tempo que o presente projecto).

O UCH Cascading tem por base a criação de um UCH MASTER (UCH principal) que detecte

outros UCHs e os agrupe no UCH MASTER de forma a poder controlar todos os

Targets/dispositivos existentes nos vários UCHs diferentes. Supondo que existe um UCH 1

com os Targets televisão e rádio e um UCH 2 com os Targets câmara de vídeo e Switch, o

UCH Cascading iria agrupar num UCH MASTER todos os Targets dos diferentes UCHs

(televisão, rádio, câmara de vídeo e Switch), desta forma seria possível controlar e detectar

ainda mais Targets existentes noutros UCH.

A integração do UCH Cascading com o Dynamic Target User Interface teria a vantagem de

conseguir detectar e controlar Targets/dispositivos de outros UCHs de uma forma

transparente para o utilizador, assim como, permitir o controlo de todos os dispositivos

associados aos vários UCHs. Este facto iria permitir trazer uma enorme flexibilidade de

controlo dos dispositivos em qualquer ambiente onde já existissem UCHs em funcionamento

e por permitir uma gestão unificada de todos os dispositivos num só controlador (ON.IT) de

forma genérica.

Desta forma sugere-se que sejam unidos esforços para integrar o Plugin Target Discovery

(responsável pela descoberta de Targets de um UCH) com o UCH Cascading pelos motivos

anteriormente referidos.

5.3. Integrar com Socket Description Editor

Ao mesmo tempo que o presente estágio estava a ser desenvolvido um outro projecto, também

no âmbito de um estágio curricular, com o nome de Socket Description Editor. Este projecto

consistia na criação de uma Socket Description para um dado Target através de um IDE

(ambiente gráfico de desenvolvimento), pelo que seria interessante à medida que se construída

uma Socket Description criar também a sua interface de utilizador utilizando o Plugin

Dynamic Target.



Este facto traria a vantagem de se poder construir uma interface de utilizador à medida que se

ia desenvolvendo uma Socket Description, mas para ser possível criar esta funcionalidade

primeiramente teria de ser possível detectar alterações na Socket Description, como referido

na secção 5.1. A interface de utilizador gerada deveria ser guardada num ficheiro XML de

forma ser facilmente portável. Possivelmente, neste caso concreto, seria aconselhável criar um

editor mais avançado da interface de utilizador, de forma a dar ao programador a flexibilidade

de decidir como, quando e quais os componentes a criar à medida que eles vão sendo

desenvolvidos/disponibilizados na Socket Description.

5.4. Alteração ao Standard

O Standard ISO/IEC 24752-2 foi desenvolvido mediante um elevado nível de abstracção, pelo

que não é possível através de uma Socket Description, uma máquina detectar, por exemplo,

que uma variável corresponde ao estado ON/OFF de uma televisão e não de um telemóvel, ou

que não se refere ao estado “mute” (sem som). Seria vantajoso adicionar ao standard, por

exemplo, meta-tags, que de alguma forma pudessem ajudar a identificar qual o propósito de

uma Socket Description e dos seus Socket Elements (p.e. variável).

Estas meta-tags iriam trazer mais complexidade à norma, mas certamente iriam torna-la mais

versátil de forma a poderem ser usados sistemas inteligentes ou motores de inferência que

pudessem processar/identificar qual o propósito da Socket Description como um todo e qual o

propósito de cada Socket Element dentro da Socket Description.

Esta informação seria útil na criação de interfaces de utilizador dinâmicas. No caso concreto

do Plugin Dynamic Target seria bastante útil na altura do parsing da Socket Description em

componentes, porque poderia decidir que o melhor componente para um dado elemento era

um ComboBox e não uma TrackBar (ver secção 4.6.17, Tabela 9).

5.5. Alterar Tamanho de um Componente

Poderia ser útil poder personalizar o tamanho de um componente, podendo assim dar ao

utilizador a possibilidade de personalizar o tamanho de um componente na medida que bem

entender.


90

5.6. Adicionar Novos Componentes

No decorrer do projecto foram desenvolvidos componentes que visam a representação de

elementos da Socket Description, de forma a ser possível interagir/controlar um Target

através do UCH. Com o decorrer do tempo pode ser necessário desenvolver novos

componentes para além dos já existentes para efectuar representações gráficas diferentes dos

Socket Elements já existentes. Por cada novo componente adicionado fornece-se ao utilizador

uma maior variedade de escolha nos componentes que pode utilizar.

5.7. Interface Web

Como a framework ON.IT disponibiliza um acesso via browser à mesma poderia ser

interessante implementar o acesso aos Plugins definidos no projecto através de uma interface

Web utilizando um browser, desta forma deixaria de ser necessário aceder directamente à

aplicação local, sendo os Targets controlados através de um browser utilizando uma

representação “Web” com base em nas linguagens HTML e JAVASCRIPT. Esta abordagem

daria a possibilidade de controlo Web por parte de um enorme número de utilizadores, mas

também poderia trazer alguns problemas de segurança ou mesmo questões de privacidade

porque muitos dos UCHs podem estar a ser usados por pessoas com problemas físicos/idosos.

5.8. Associações

Como a framework ON.IT possibilita associar Plugins (ver secção 4.1.1.2), pode ser útil para

o Plugin Target Discovery e Dynamic Target disponibilizar a criação dessas associações.

Exemplos práticos:

Exemplo 1 - Caso seja disponibilizado um novo Target através do UCH, pode ser criada uma

associação que defina quando um novo Target for detectado, seja criado um novo Plugin

Dynamic Target para o controlar.

Exemplo 2 – Considerando dois Plugins Dynamic Target (um para controlar uma lâmpada,

outro para controlar um detector de movimentos), permitisse criar uma associação entre os

dois Plugins, de forma a, acender a lâmpada através do Plugin da lâmpada quando uma

notificação de movimento chegasse ao Plugin Dynamic Target de detecção de movimento.



Capítulo 6

Conclusões

O presente estágio decorreu na empresa Meticube no primeiro semestre e segundo semestre,

no período compreendido entre 22 de Novembro de 2010 e 15 de Julho de 2011.

A parte inicial do estágio incidiu principalmente sobre tarefas preparatórias ao início do

projecto. Essas tarefas incluíram a familiarização com a framework ON.IT, que levou à

criação da sua documentação técnica visto que esta framework não possuía qualquer tipo de

documentação relevante. O estudo da framework ON.IT foi particularmente relevante de

forma a identificar o modo de criação de um Plugin e o seu modo de

funcionamento/interacção com a framework, sendo este estudo particularmente importante

para o desenvolvimento dos Plugins Target Discovery e Dynamic Target. Duas outras tarefas

preliminares ao início do projecto incluíram o estudo da tecnologia URC/UCH e o estudo

Standard ISO/IEC 24752, com especial foco na segunda parte do standard referente à

definição de Socket Description. Numa outra fase mais prática das tarefas de preparação, já

com os conhecimentos sobre o ON.IT, tecnologia URC/UCH e Standard ISO/IEC 24752

desenvolveu-se um Plugin para a framework ON.IT que através do UCH possibilitasse o

controlo de um Target/dispositivo de uma câmara de vídeo, consistindo este Plugin numa

concretização “estática” do trabalho a realizar, pois construiu-se um Plugin com uma interface

de utilizador específica que controlasse um Target específico.

Dotado de todos os conhecimentos anteriores tornou-se possível iniciar a modelação do

sistema a desenvolver, iniciando-se o levantamento de requisitos, elaboração de diagramas de

contexto, diagramas de caso de uso, diagrama de sequência e diagramas de classes.

Concluídas estas tarefas iniciou-se a fase de implementação/codificação do sistema de forma

a serem cumpridos todos os requisitos identificados, em paralelo com esta fase foram também

desenvolvidos os respectivos testes unitários que iam sendo executados de forma a averiguar

se o sistema funcionava de acordo com o esperado. Concluída a fase de implementação

efectuou-se uma bateria de testes com o objectivo de averiguar, se o sistema funcionava de

acordo com o esperado, nesta etapa foi seguido o Plano de Testes definido e o seu resultado

colocado no Relatório de Testes de Aceitação, assim como voltaram a ser executados os testes


92

unitários. Importa ainda ressalvar a dificuldade em implementar testes, pois como a criação

das interfaces de utilizador para os Targets é totalmente dinâmica e existem relativamente

poucos Targets a testar em cenário real, tornando-se difícil garantir que a conversão das

Socket Descriptions em componentes se encontra a funcionar correctamente para todos os

casos, apesar de todos os testes efectuados não terem apresentado qualquer defeito. Existem

também elementos definidos no Standard que não se encontram definidos em nenhuma das

Socket Descriptions existentes, pelo que se teve de proceder à sua simulação, o que

eventualmente pode não se aproximar de um cenário real.

O respectivo estágio terminou com a elaboração da documentação interna do projecto e início

do presente relatório.

Como resultado do presente estágio, a nível pessoal revelou-se bastante benéfica pois

aproximou o estagiário de um “ambiente de trabalho real” o que permitiu adquirir uma

experiência profissional muito positiva, que certamente será muito útil quando o estagiário

iniciar a sua actividade no mercado de trabalho. O presente estágio revelou-se também muito

proveitoso no que diz respeito ao alargamento do leque de conhecimentos do mesmo, devido

ao facto da utilização e estudo de novas tecnologias e ferramentas sobre as quais o estagiário

possuía poucos ou nenhuns conhecimentos. O facto de o projecto ser distribuído em conjunto

com a UCH WorkBench e entrar numa fase de testes muito brevemente levou a uma

responsabilidade acrescida por parte estagiário, visto que as funcionalidades tinham de se

encontrar correctamente implementadas, de forma a garantir uma boa imagem do projecto e

da Empresa.

Dynamic Target User Interface Referências


Referências

[1] Brainable, http://www.brainable.org/

[2] i2home, http://www.i2home.org/

[3] VITAL, http://www.ist-vital.org/

[4] ISO/IEC 24752-1:2008 – Framework

[5] ISO/IEC 24752-2:2008 - User Interface Socket Description

[6] ISO/IEC 24752-3:2008 - Presentation Template

[7] ISO/IEC 24752-4:2008 - Target Description

[8] ISO/IEC 24752-5:2008 - Resource Description

[9] Webclient JavaScript Library, http://myurc.org/tools/Webclient/index.php

[10] Types, http://www.w3schools.com/Schema/

[11] XML Schema Part 1: Structures Second Edition,

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

[12] Iconix Process, http://iconixprocess.com/iconix-process/

[13] An Open Standardized Platform for Dual Reality,

http://www.dfki.de/LAMDa/accepted/LAMDa11.pdf

[14] Universal Remote Console Consortium, http://myurc.org/

[15] Reflection (C# Programming Guide), http://msdn.microsoft.com/en-

us/library/ms173183(v=vs.80).aspx)

[16] Windows Forms Designer, http://msdn.microsoft.com/en-

us/library/e06hs424(v=VS.80).aspx

[17] Events (C# Programming Guide), http://msdn.microsoft.com/en-

us/library/awbftdfh.aspx

[18] Anonymous Methods (C# Programming Guide), http://msdn.microsoft.com/en-

us/library/0yw3tz5k(v=vs.80).aspx

Dynamic Target User Interface Referências

94

[19] Smart meter, http://en.wikipedia.org/wiki/Smart_meter

[20] URC-HTTP Protocol Specification, http://myurc.org/TR/urc-http-protocol/

[21] Interface (C# Reference), http://msdn.microsoft.com/pt-

br/library/87d83y5b.aspx

[22] XML Schema restriction Element,

http://www.w3schools.com/schema/el_restriction.asp

[23] Assemblies and the Global Assembly Cache (C# Programming Guide)

http://msdn.microsoft.com/en-us/library/ms173099(v=vs.80).aspx

Dynamic Target User Interface Anexos


Anexos

Esta secção contém todos os anexos referenciados no presente documento. Os anexos

encontram-se incluídos no CD, entregue juntamente com o relatório de estágio. Para cada

anexo é apresentada a sua localização no CD.

Anexo A

Ficheiro

Documentação Técnica da framework ON.IT em Português

ANEXO A - mtcb_on.it_architecture_v1.0_pt.pdf

Anexo B

Ficheiro

Documentação Técnica da framework ON.IT em Inglês

ANEXO B - mtcb_on.it_architecture_v1.0_uk.pdf

Anexo C

Ficheiro

Documentação Técnica do Projecto

ANEXO C - mtcb-relatorio-tecnico-Dynamic_Target_User_Interface.pdf

Anexo D

Ficheiro

Plano de Testes

ANEXO D - mtcb-AT-Dynamic_Target_User_Interface.pdf

Anexo E

Ficheiro

Resultado do Plano de Testes

ANEXO E - mtcb-ATR-Dynamic_Target_User_Interface.pdf

Anexo F

Ficheiro

Modelo de Dados

ANEXO F - mtcb-DATAMODEL-Dynamic_Target_User_Interface.pdf

Anexo G

Ficheiro

Manual de Utilizador

ANEXO G - mtcb-Manual_de_Utilizador-Dynamic_Target_User_Interface.pdf

Anexo H

Ficheiro

Relatórios Quinzenais

ANEXO H - mtcb-relatorios_quinzenais.pdf

Anexo I

Pasta

Código Fonte do Projecto

Encontra-se na pasta: Anexo I - Código Fonte

Anexo J

Pasta

Código Fonte da Câmara de Vídeo integrada com ON.IT e UCH

Encontra-se na pasta: Anexo J - Camara de video + UCH + ON.IT

Anexo K

Pasta

Testes Unitários

Encontra-se na pasta: Anexo K - Testes Unitários

Anexo L

Pasta

Vídeo de Marketing

Encontra-se na pasta: Anexo L - Vídeo de Marketing

dyynn aammiicc rttarrggeett uusseer...

Documents