Projecto da Disciplina de Projecto 3º Ano NTC
pesquisar neste blog
posts recentes

Entrega final, wooo-hooooo!

Testes de Interacção dos Docentes e Usabilidade da Mesa

Entrega Versão Beta

testes versao beta

Actualização das funcionalidades DeCATouch

Lista de bugs protótipo (código, funcionalidades, layout)

Módulos a desenvolver na versão beta

Testes de Interacção dos Docentes

Protótipo de Alta Fidelidade agora com lente

Entrega de Protótipo de Alta Fidelidade

arquivos

Julho 2010

Junho 2010

Maio 2010

Abril 2010

Março 2010

Fevereiro 2010

Sexta-feira, 12 de Março de 2010
Estudos de Requisitos Funcionais e Viabilidade Técnica

Para a elaboração dos estudos de requisitos funcionais e viabilidade técnica recorreu-se, em primeiro lugar, à construção de duas tabelas [PDF tabelas] que sistematizam as opções em cada um dos estudos e cuja leitura não deve ser realizada em separado do texto abaixo.

 

1.Requisitos funcionais

 

O projecto Decatouch divide-se em duas áreas: backoffice e front-end, sendo a primeira destinada à inserção e administração de conteúdos para serem disponibilizados na segunda, que consiste numa plataforma multitoque que servirá de “montra” ao Departamento de Comunicação e Arte da Universidade de Aveiro.

 

1.1 - Backoffice - Esta área de backoffice (web-based) tem três tipos de utilizadores (professor, aluno e adiministrador) requerendo todos eles registo e login (sendo que este registo apenas será necessário caso não seja possível usar uma conta de utilizador universal da Universidade de Aveiro). O administrador, para além do registo e login, apenas poderá proceder à remoção de trabalhos da base de dados. Por sua vez, o aluno pode, para além das funções de registo e login já enunciadas, introduzir trabalhos da sua autoria, assim como proceder à sua edição, tornar activos ou inactivos essses mesmos trabalhos e aprovar os comentários que lhes sejam feitos. O professor registado, em adição às funcionalidades referidas para o utilizador aluno, pode tornar activos e inactivos não só os trabalhos por si realizados como os dos alunos das suas disciplinas como também tem a responsabilidade de validar os trabalhos por eles submetidos.

Optou-se por esta divisão de funcionalidades para não permitir o uso indevido do serviço, ou seja, impedir que sejam colocados conteúdos por parte dos alunos que não sejam relevantes para a temática do projecto.

Elegeu-se esta forma de gestão de conteúdos (em deterimento de outras opções, como por exemplo via Wireless, Bluetooth, pen USB a partir da própria mesa) por ser mais rápida e fácil de implentar devido às dimensões de tecnologias que o grupo não domina e que pretende vir a integrar no projecto.

Os trabalhos introduzidos serão catalogados por curso (NTC/Design/Música), uma vez que o projecto pretende abranger todos os cursos do Departamento, por tipo (imagem, web, vídeo, música e interactivo – com formulário respectivo conforme o tipo de ficheiros a enviar) e ano lectivo.

 

1.2 - Front-end - A área de front-end vai servir, no fundo, para disponibilizar os trabalhos inseridos na área funcional previamente descrita. Nesta plataforma multitoque poder-se-ão filtrar os trabalhos mediante a catalogação feita na base de dados (curso – ntc, design, música –, tipo – imagem, web, vídeo, música e interactivo – e ano lectivo) e visualizar cada um deles em pontos diferentes do interface, permitindo o uso simultâneo por vários utilizadores. Em cada um destes trabalhos será possível inserir comentários, com o auxílio de um teclado virtual. Para além disso terá disponível uma navegação pelo campus universitário efectuado com o auxílio da biblioteca MapsTouch para uso com o googlemaps.

No que concerne à visualização e interacção com os trabalhos poderá, em qualquer tipo de trabalho, proceder-se aos escalamento, reposicionamento e rotação dos mesmos. No entanto, cada tipo de trabalho terá funcionalidades de visualização específicas, sendo que, no caso do vídeo exibir-se-á um player vídeo, na eventualidade de ser um trabalho de música, um player de áudio, na possibilidade de ser um site web surgirá um screenshot acompanhado de um formulário para envio do link referente ao mesmo para um mail definido pelo utilizador através do previamente referido teclado virtual, e finalmente se o trabalho visualizado for do tipo interactivo (em que só serão permitidas aplicações de flash) aparecerá, mais uma vez, o teclado virtual que permitirá a navegação na aplicação referida, no caso desta ser realizada com o rato, estamos convictos de que as acções de multitoque substituirão o uso do mesmo.

Em suma, em relação à plataforma front-end, pode dizer-se que se tomaram estas funcionalidades como opções por nos parecerem ser relevantes para o âmbito do projecto. Tiveram-se em conta outras funcionalidades que não chegaram às opções finais, nomeadamente a inclusão de uma visita guiada pelo DeCA com fotografias de 360º. Pareceu-nos que estas iriam, não só distraír o utilizador do foco central do projecto, como também que seriam tarefas em que a nossa atenção se iria diluir em deterimento das funcionalidades tidas como prioritárias no projecto.

 

2.Viabilidade técnica

 

2.1.1 – Backoffice (aplicações) - No que diz respeito aos requisitos funcionais identificados para a área de back-office, em que necessitaremos de um Sistema de Gestão de Base de Dados que irá possibilitar o controlo quer ao nível dos utilizadores como ao nível dos conteúdos por eles introduzidos, apresentamos as três soluções estudadas. A primeira delas, a escolhida pelo grupo por conter linguagens abertas e por o grupo se sentir mais à vontade com a sua utilização como o PHP e MySQL, conta ainda com a vantagem de poder recorrer a um conjunto de software de baixo custo (pois entre os programas apresentados - Dreamweaver, EMS SQL Manager for MySQL 2010, XAMPP, MySQL Workbench e Notepad ++ - apenas os dois primeiros não são de acesso gratuito). Por outro lado, apresenta como desvantagens o facto de o código ficar disponível no servidor, permitindo a sua consulta e o facto dessas linguagens não serem compiladas.

A segunda opção, que seria recorrer à linguagem ASP (recorrendo a Visual Studio, Dreamweaver e Access), traria como desvantagens o facto de se ter de recorrer a linguagens proprietárias (necessitando de servidor da Microsoft), a que se acrescenta a questão do preço mais elevado a pagar pelos softwares de edição. Para além destes pontos que consideramos negativos, o grupo teria a necessidade de passar por mais um processo de aprendizagem (para além daqueles que já terá derivado à especificidade do projecto) uma vez que não domina as linguagens em questão. Em contrapartida, o recurso a esta solução traria a vantagem da utilização de variáveis de aplicação, disponíveis para o uso do servidor.

A terceira solução apresentada, recorreria à aplicação Flash Media Server (FMS) que apresenta, basicamente, os mesmos problemas da solução anteriormente enunciada: linguagens de proprietário (neste caso da Adobe), softwares de custo elevado e a necessidade por parte do grupo em aprender novas linguagens, apresentando, pelo contrário, a vantagem de ser uma linguagem compilada.

 

2.1.2 - Backoffice (frameworks) - A nível de frameworks, iremos utilizar, nesta área de back-office, jQuery que se apresenta com as vantagens de ser cross-browser, de necessitar de pouco processamento e de possuir boa documentação sendo o único senão encontrado pelo grupo, o facto do suporte ser efectuado apenas pela comunidade.

 

2.1.3 - Backoffice (hardware) - A nível de hardware apresentamos, igualmente, três opções que estão directamente relacionadas com as três soluções apresentadas a nível de aplicações, no que diz respeito à componente de back-office do nosso projecto. Assim, e uma vez que a nossa escolha recaiu na linguagem PHP, a componente de hardware será assegurada por um servidor Linux com suporte para PHP. Acrescenta-se a esta característica a possibilidade deste tipo de servidor suportar outras tecnologias e ainda o facto das linguagens serem Open Source, a que acresce o baixo custo desta solução. Como aspecto negativo desta solução poderemos apontar o facto de, sendo ela Open Source, o suporte é apenas efectuado pela comunidade.

A segunda opção, que serviria a solução com recurso à linguagem ASP, iria usar um servidor Windows com suporte para ASP que teria na fiabilidade, segurança e robustez a sua grande vantagem. No entanto, relativamente à opção por nós eleita, esta representaria um custo mais elevado e um investimento da nossa parte na aprendizagem de novas linguagens.

Por fim, a solução que poderia recorrer a um Flash Media Server teria como vantagem o desempenho que se poderia obter, mas, pelo contrário, haveria um custo elevado pelo alojamento, ter-se-ia que usar linguagens e softwares Adobe e, tal como na opção anterior, seria necessário que o grupo aprendesse novas linguagens.

 

2.2.1 – Front-end (aplicações) - No que diz respeito ao front-end algumas soluções foram estudadas, sendo que, das soluções referidas na tabela que apresenta o referido estudo, o grupo vai optar, no que concerne a aplicações e linguagens, pela opção que diz respeito ao PHP, MySQL, AMFPHP e AS3, sendo que as aplicações utilizadas para o efeito são o XAMPP, Dreamweaver ou Notepad++, EMS SQL Manager for SQL 2010, Flash, Flex e Tbeta (CCV)[link]. Esta escolha foi feita devido às facilidades de integração destas tecnologias umas com as outras bem como à variedade de exemplos disponíveis nas linguagens escolhidas para aplicações do mesmo género. Ainda neste aspecto há que referir que, apesar do grupo ainda não ser muito experiente, se considera profícua a inclusão destas linguagens e aplicações no projecto, conferindo-lhe uma vertente de inovação para a qual teremos o maior apoio possível, sendo que o orientador é bastante experiente nas aplicações consideradas nesta opção. Há ainda que referir que em todas as soluções estudadas no âmbito das aplicações para o front-end de multitoque, teria que ser utilizado o protocolo TUIO[link] bem como a aplicação FLOSC[link], sendo que estes são necessários à comunicação entre qualquer tecnologia escolhida para a construção do artefacto físico propriamente dito (entenda-se a mesa multitoque) e a aplicação em AS3 (desta solução ou de qualquer uma das outras estudadas nas aplicações do front-end).

 

2.2.2 – Front-end (API's, bibliotecas e frameworks) - No que toca às API's, bibliotecas e frameworks presentes na área funcional do front-end refere-se a opção da TouchLib[link], MapsTouch[link] e Greensock[link] (entre outras bibliotecas de tweens como esta última) como sendo a escolhida pelo grupo, sendo que a utilização da mesma não exclui o uso da opção referida como GestureWorks[link], sendo que o único problema desta última é o seu preço. Nestas opções pode mencionar-se a escolhida como a mais fiável e acessível, sendo que a biblioteca TouchLib já contém muitas das funções de navegação multitoque que o grupo pretende utilizar e tendo ainda em conta que a opção da utilização do Flash Player 10.1 ainda é experimental e está em versão beta, não havendo certezas de que o lançamento da versão final seja efectuada antes da finalização do projecto.

 

2.2.3 – Front-end (hardware) - Ainda no que diz respeito ao front-end, mas no campo dos hardwares utilizados, pretendemos optar pela tecnologia LLP[link], sendo que esta, é mais fiável no reconhecimento de áreas de toque, desde que usando uma quantidade de lasers que consiga abranger toda a superfície da mesa, embora sem reconhecimento de pressão ou de fiduciais. Esta técnica de contrução será, provavelmente, a mais cara de entre duas das mencionadas (LLP e FTIR), sendo que o preço dos lasers, raros no mercado nacional, encarece a construção. Ainda assim e, por não precisar de incluir uma superfície de silicone e por poder funcionar numa qualquer superfície que não seja o acrílico (muito embora talvez cheguemos a utilizar este mesmo material), o grupo vai eleger esta tecnologia sobretudo pela sua facilidade de montagem, sem molduras para sustentar uma grande quantidade de LEDs, coisa que acontece na tecnologia FTIR[link] também mencionada na tabela que apresenta os estudos efectuados. Finalmente, e apesar da fiabilidade da Reactable, esta não constitui uma opção possível para o projecto, visto ser tida como extremamente fora das possibilidades financeiras estabelecidas para o projecto (mesmo que o Departamento seja generoso a financiar o projecto).

 

2.3 – Testes (aplicações) - Finalmente, para o plano de testes e prototipagem, vão ser utilizadas três aplicações sendo que o SimTouch é a aplicação para a qual se escolhe uma área de actuação no monitor do utilizador, sendo possível simular o multitoque com o rato, adicionando vários pontos e mexendo cada um deles individualmente, utilizando a aplicação isoladamente. Cumulativamente podem ser usados o FLOSC para usar uma miniT (como a caixa que já elaborámos da qual se pode ver um vídeo no blog do grupo) ou a aplicação Select Server[10], que pode estabelecer um protocolo com um dispositivo móvel como um iPhone, podendo utilizar o monitor multitoque deste para interagir com área definida no SimTouch. Com cada uma destas aplicações será necessário utilizar, mais uma vez, o supracitado protocolo TUIO e transversal às aplicações multitoque a ser desenvolvidas. Estas opções vão ser utilizadas frequentemente tanto nas suas demais combinações como o SimTouch em separado, dependendo das plaformas multitoque que o grupo tiver disponíveis a cada momento do processo de prototipagem. Consideram-se ser, sobretudo, baratas, visto serem todas open source, e práticas, permitindo a produção de protótipos com o recurso a tecnologias que o grupo já possui ou que não precisam que uma montagem complexa.

 

2.4 - Conclusão

Em suma pode-se afirmar que na origem das nossas escolhas estiveram tanto razões de ordem financeira como razões de ordem técnica (seja por melhor domínio por parte dos elementos do grupo relativamente a algumas linguagens comparativamente com outras estudadas, seja pela expectativa de melhores resultados de uma determinada tecnologia). Por fim, importa salientar que há algumas decisões que, neste momento, não são ainda definitivas pois, por um lado, como foi referido, há software que se encontra em fase de testes, e cujo uso poderá ser vantajoso caso a versão final saia atempadamente e, por outro lado, há ainda algumas indefinições sobre qual o software a ser usado na programação em AS3 (se Flash, se Flex, se ambos). Finalmente, tal como já foi enunciado anteriormente, mediante as possibilidades financeiras poderemos ter de abandonar a preferência pela técnica de construção LLP em deterimento da FTIR, reforçando a intenção de que LLP é a opção prioritária a seguir.

 


tags:

publicado por samueltraquina às 15:00

mais sobre mim
Julho 2010
Dom
Seg
Ter
Qua
Qui
Sex
Sab

1
2
3

4
5
6
7
8
9
10

11
13
14
15
16
17

18
19
20
21
22
23
24

25
26
27
28
29
30
31


tags

todas as tags

subscrever feeds

RSSPosts

RSSComentários

RSSComentários do post