No decorrer destas últimas duas semanas, e apesar de muito trabalho ter sido desenvolvido, a equipa não procedeu à actualização do blog devido ao facto de o tempo ter sido empregue no conhecimento das (novas) ferramentas de trabalho.

Após um longo período de desenvolvimento de documentos teóricos e respectiva investigação (módulo 1), a equipa sentiu a necessidade de se concentrar totalmente na exploração e domínio das funcionalidades do Flex, permitindo a integração de todos os conteúdos já produzidos nessa ferramenta.

Outra das razões pelas quais não foram feitas actualizações no blog deve-se ao facto das aulas de projecto e reuniões com orientadores serem de carácter meramente demonstrativo de todo o trabalho desenvolvido para protótipo, não havendo novas tomadas de decisão ou qualquer alteração às directrizes delineadas anteriormente.

Em suma, a equipa esteve estas duas semanas em total “modus operandis”.

Nestas duas semanas, a integração da interface em diferentes módulos de Flex revelou-se problemática, na medida em que o formato das imagens escolhido (.svg) apresentou problemas em suportar transparências definidas em Adobe Illustrator.

A solução encontrada passa por importar todos os gráficos para o Flex em formato .swf, o que no entanto, não é totalmente satisfatório, pois as imagens nao apresentam a qualidade esperada.

Relativamente à arquitectura do projecto, a estruturação deste baseia-se numa organização por módulos, isto é, na aplicação principal existirá um módulo principal (navlocator.mxml) que carregará os outros cinco módulos correspondentes a cada área de interacção (perfil, mapa, diário de bordo, definições, e viagens).
Por uma questão de organização, a equipa decidiu separar o código funcional do código gráfico, sendo que para cada mxml existe um ficheiro externo de Action Script que contém toda a programação necessária a esse módulo.

Desta forma, o grupo poderá trabalhar em gráficos e programação separadamente, sem que exista qualquer conflito entre estas duas componentes na altura de reunião de ficheiros.

Relativamente à apresentação de 22 de Abril, o grupo terá desenvolvido os seguintes módulos:

- módulo de Menu Inicial

- navegação básica (animada) da aplicação

- modulo de simulação de Gps

- simulação de dados de geo-posicionamento (em tempo real)
- definição de rotas
- simulação de dados de telemetria

- módulo de Diário de Bordo

- visualização de posts dos blogs/diários de bordo
- possibilidade de escrita de novos posts

- módulo de Mapa

– módulo de Perfil

- visualização de perfis completos (dados pessoais e avatares)

O grupo tem consciência que os objectivos de prototipagem definidos anteriormente não serão totalmente atingidos (passando estes pela construção de todas as funcionalidades do módulo do mapa à excepção da pesquisa), no entanto essa impossibilidade é justificada pelo surgimento do módulo de simulação de GPS, que necessitou de ser desenhado e programado de raíz e que consumiu uma considerável quantidade de tempo .

Os contratempos naturais que existem no confronto com uma nova ferramenta de trabalho estão igualmente a consumir tempo útil.

Amanhã, e em jeito de desculpa pela falta de actualizações neste blog, serão colocadas imagens, excertos de código e exemplos funcionais da aplicação NavLocator. Sim, porque estivemos realmente a trabalhar!

Durante a madrugada de terça feira, será disponibilizada a versão de protótipo em extensão AIR, antes da apresentação.

Até amanhã,

O grupo NavLocator

Deixamos aqui também os novos ícones a utilizar na interface final. A restante simbologia ainda está a ser desenvolvida (vectorialmente, claro está) pelo que serão aqui adicionados assim que estiverem finalizados.

Apesar do modelo da base de dados ter sido anteriormente apresentado em Access, já foi especificado que esta será implementada em MySQL, que comunicará com a aplicação via PHP.  A base de dados está actualmente a ser testada, de modo a verificar-se “à prova de erros” num ambiente de utilização real.

A mesma já foi convertida, para efeitos de teste e simulação, para MySQL. Está actualmente implementada localmente, à espera que cheguem os novos servidores para ser posteriormente copiada e alojada no seu destino final.

A prova, está no phpMyadmin!:

A comunicação do Flex com a BD também está assegurada; este executa os scripts de PHP (que contêm as queries), que geram resultados em XML e são interpretados pela aplicação. Exemplo de uma aplicação que retorna dados (ainda fictícios) a partir da base de dados:

E fica também o script PHP que torna esta comunicação possível;

Agora é apenas uma questão de adaptar estes novos ricos e fantásticos conhecimentos à mui nobre e cuidada interface, e tudo seguirá para bom porto!

No último post, explicitou-se a necessidade de utilização de um simulador de dados GPS para alimentar um ambiente de utilização fictícia. Como tal, iniciou-se o desenvolvimento de uma aplicação em Java (seguindo a lógica e conceito multi-plataforma) que fosse responsável por ler a rota definida e recalcular a posição do utilizador à medida que percorre essa mesma rota.

Sendo assim, a estrutura criada baseia-se no seguinte:

- Ficheiro XML, de nome “telemetria.xml”, que contém informação das coordenadas actuais, bem como da rota definida, velocidade e hora universal. A estrutura deste xml consiste em:

- Classe em JAVA, responsável por fazer variar as coordenadas actuais do dispositivo GPS simulado, de acordo com a rota definida. Esse mesmo ficheiro é responsável por registar as novas informações de dados no ficheiro “telemetria.xml”, substituindo as existentes. Deste modo o programa poderá sincronizar essa mesma informação com o ficheiro de mesmo nome em server-side, em intervalos que podem ser definidos pelo próprio utilizador.

Aqui fica o desenho da base de dados, já com as relações desenhadas, actualmente estruturada em Access. Após novas verificações quanto à consistência das tabelas e respectivas relações, esta será implementada em MySQL.O grupo já fez avanços no estudo sobre implementação de bases de dados em MySQL e sua integração com PHP. Eis alguns sites de investigação que servem de apoio:

MySQL — http://www.tizag.com/mysqlTutorial/

MySQL & PHP — http://www.w3schools.com/php/php_mysql_intro.asp

Modelo físico da BD

Dada a necessidade de criar um ambiente que possibilite a explicação perfeita de todo o conceito do NavLocator, foram pensados módulos de simulação integrados na aplicação, que permitem atingir o objectivo anteriormente descrito.

Segue-se a contextualização destes módulos de simulação;

- Simulador de dados GPS

Criação de uma aplicação independente da aplicação NavLocator, simuladora da comunicação entre dispositivo de GPS
e computador, calculando as coordenadas e registando-as num ficheiro XML, que será lido em Flex, que será posteriormente sincronizado num ficheiro de telemetria em XML no servidor.

O grupo encontra-se ainda a estrutura o modo de funcionamento (e respectivo fluxograma) deste simulador, pelo que a sua estruturação será aqui postada assim que concluída.

- Simulador de utilizadores e embarcações

Os administradores têm a possibilidade de adicionar utilizadores fictícios ao sistema NavLocator, com todos os dados inerentes a um perfil de embarcação, de utilizador e de viagem, aproximando-se do ambiente real no qual a aplicação NavLocator seria utilizada.

Estes utilizadores, ainda que não-reais, comportar-se-ão como verdadeiros utilizadores, isto é, serão dotados de uma “inteligência artificial” capaz de providenciar comportamentos semelhantes aos que um outro utilizador real providenciaria.

O intuito deste ambiente simulado é fornecer aos utilizadores uma experiência interactiva com outros utilizadores , que de outra forma não seria possível visto que não iriam existir registos no sistema.

Em anexo fica o documento da localização dos módulos de simulação no modelo de arquitectura de sistema.
Apresentamos ainda o mapa de navegação com a identificação das zonas que serão alimentadas pelos dados fictícios dos simuladores.

Os fluxogramas da simulação de utilizadores/embarcações estão disponíveis nos respectivos módulos de login, inserção de utilizadores fictícios, e eliminação dos mesmos.

– PROTOTIPO 22 ABRIL –
– CARACTERÍSTICAS SEGUNDO STRAUSS –

1) Tipologia do Protótipo (forma de evolução)

> Reutilizável e modular: os módulos do protótipo a apresentar no dia 22 de abril são as primeiras versões desses componentes na aplicação final. Para esta apresentação, não estão contemplados todos os módulos, pelo que componentes adicionais serão acrescentados posteriormente à medida que forem testados (secção de “viagens” e secção de “definições”).

2) Nível de detalhe/profundidade do protótipo

> Prototipagem em T: serão prototipados alguns módulos principais (camada horizontal), e algumas secções dentro de cada um destes módulos (camada vertical). No caso específico do NavLocator, a prototipagem vertical incidirá especificamente nos módulos do Mapa e do Perfil de Utilizador. Os restantes módulos, Diário de Bordo, Viagens e Definições, serão prototipados horizontalmente.

Secção Mapa: Prototipagem Vertical

– Secção de FAVORITOS
– Visualização de POI’s
– Inserção de POI’s

– Visualização de utilizadores no mapa (em tempo real)

Secção Perfil: Prototipagem Vertical

– Inserção de dados pessoais
3) Nível de aproximação final

> Prototipagem High-Fidelity: as tecnologias utilizadas no protótipo serão o mais semelhantes possível às utilizadas na versão final, isto é, o código dos módulos prototipados será reutilizado e melhorado posteriormente.

mapa de prototipagem

No momento de Orientação Tutorial desta semana (terça-feira,25 Março), foram discutidas os diferentes perfis que o protótipo final do projecto pode/deverá assumir no momento de teste e apresentação, face à definição de três objectivos fundamentais a atingir nesse momento:

- Comunicação do Impacto Social da Aplicação NavLocator;

- Comunicação do Conceito base do projecto;

- Comunicação de todas as funcionalidades disponibilizadas na aplicação;

Partindo destes objectivos base, foi discutida a melhor forma de os transmitir, chegando-se à conclusão da necessidade de simulação de ambientes, para que se realize o teste à aplicação.

A estruturação da simulação será feita através da criação de um módulo especifico para o controlo de todas as variáveis do ambiente a simular. Este módulo pode ser operado numa máquina diferente da máquina-cliente.

Na máquina cliente estará instalada, apenas, a aplicação NavLocator . Qualquer utilizador que deseje testar o sistema necessita da criação de um registo pessoal e só posteriormente terá acesso ao sistema.

Assim que o login esteja efectuado, este utilizador terá acesso a todas as áreas principais da aplicação, que se pretende que sejam funcionais, na medida que exibirão os dados provenientes do ambiente de simulação, acumulados em server-side.

No que diz respeito à secção do mapa, esta permitirá a visualização dos vários utilizadores simulados.

A interacção com os utilizadores simulados deverá aproximar-se ao máximo de um ambiente real de viagem (existência de rotas, dados de telemetria e diário de bordo).

Na última aula de projecto, terça-feira, dia 25 de Março, a definição das características do servidor necessárias para que este se adeqúe às especificidades do projecto foi a meta estabelecida.

A publicação da decisão final relativa ao servidor deverá ser publicada no dia 27 de Março (quinta-feira), depois da discussão de diferentes soluções com os professores orientadores.

Aqui ficam todos os documentos relativos à apresentação.

– Apresentação Powerpoint

– Comparativo Adobe Flex vs Microsoft Silverlight

– Comparativo PHP vs JSP

– Mapa de navegação da aplicação

– Aplicação-exemplo da interacção

– Documento final (todos os tópicos)