CARLA BELARMINO SISTEMA DE PROCESSAMENTO DE IMAGENS VIA WEB JOINVILLE-SC

Transcrição

1 CARLA BELARMINO SISTEMA DE PROCESSAMENTO DE IMAGENS VIA WEB JOINVILLE-SC 2010

2 UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC CENTRO DE CIÊNCIAS TÉCNOLOGICAS CCT DEPARTAMENTO DE CIÊNCIAS DA COMPUTÇÃO CARLA BELARMINO SISTEMA DE PROCESSAMENTO DE IMAGENS VIA WEB Trabalho de Conclusão de Curso apresentado à Universidade do Estado de Santa Catarina UDESC como requisito para obtenção do título de Bacharel em Ciências da Computação. Orientador: Alexandre Gonçalves Silva JOINVILLE SC 2010

3 CARLA BELARMINO SISTEMA DE PROCESSAMENTO DE IMAGENS VIA WEB Trabalho de Conclusão de Curso aprovado como requisito para obtenção do título de Bacharel no curso de graduação em Ciência da Computação da Universidade do Estado de Santa Catarina UDESC. BANCA EXAMINADORA Orientador: Dr. Alexandre Gonçalves Silva Universidade do Estado de Santa Catarina UDESC Membro: Dr. Maurício Aronne Pillon Universidade do Estado de Santa Catarina UDESC Msc. Débora Cabral Nazário Universidade do Estado de Santa Catarina - UDESC Joinville, 05 de novembro de 2010.

4 Agradeço primeiramente a Deus, pois sem Ele não somos nada. Aos meus pais, Ema e Vilmar Belarmino por estarem sempre ao meu lado. E por último ao meu esposo, Geovane Bitencourt, que me incentivou a nunca desistir dos meus objetivos.

5 RESUMO Este trabalho consiste no desenvolvimento de uma ferramenta web simples e intuitiva com o intuito de auxiliar o ensino de processamento de imagens. Python é a linguagem adotada pela sintaxe clara, recursos modernos e apropriados para testes de conceitos. Um módulo denominado spiweb, derivado do IA636, foi projetado para experimentação do sistema. Este é disponibilizado no modelo SaaS (Software como um Serviço), ou seja, utilizado em um servidor de internet sem necessidade de instalações locais e com reduzido custo de manutenção. As páginas dos módulos e operadores, os parâmetros de entrada exigidos, as saídas produzidas e a documentação são construídas dinamicamente com base em arquivos XML e ações do usuário. Dentre diversas características, inspiradas no que há de melhor em plataformas similares, destaca-se a agilidade de uso (sem necessidade de instalação de software), a programação orientada (documentação pontual a cada seleção) de técnicas ou exercícios de processamentos de imagem sem necessidade do conhecimento de uma linguagem específica, a extensibilidade bastando a criação de novo repositório de funções em XML, o encadeamento de operadores com a manutenção do histórico de imagens e a criação automática de scripts Python ao final da atividade. O projeto segue as etapas da Engenharia de Software: Planejamento, Projeto, Proposta, Levantamento e Análise de Requisitos, Modelagem (Diagramas, Protótipos, Base de Dados, Recursos UML), Implementação, Testes e Documentação do Sistema. Os resultados obtidos foram satisfatórios, considerando a ampla implementação dos itens imaginados inicialmente e a avaliação positiva do sistema feita por um grupo de estudantes. XML. Palavras-chave: Processamento de imagens. Web. Operadores. Python.

6 ABSTRACT This work consists in a simple and intuitive web tool in order to assist the teaching of image processing. Python is the language adopted by the clear syntax, modern features and suitable for testing concepts. A module called 'spiweb', derived from IA636, was designed to trial the system. The system is available on SaaS (Software as a Service), or used on a web server without the need of local installation and reduced maintenance costs. The web pages of the modules and operators, the input parameters required, outputs produced and documentation are built dynamically based on XML files and user actions. Among several features, inspired by the best in similar platforms, agility use (no need to install the software), oriented programming (exact documentation for each selection) of techniques or exercises of image processing without the need of the knowledge of a specific language, extensibility from the creation of functions in a new XML repository, the chaining operators with the maintenance of a historic of images and the automatic creation of Python scripts at the end of the activity are highlighted. The project follows the steps of Software Engineering: Planning, Design, Proposal, Survey and Requirements Analysis, Modelling (Diagrams, Prototypes, Database, UML Resources), Implementation, Testing and Documentation System. The results were satisfactory considering the wide implementation of the items originally imagined and the positive evaluation of the system by a group of students. Keywords: Image Processing. Web. Operators. Python. XML.

7 LISTA DE FIGURAS Figura 1 - Tratamento de imagem de raio-x: Figura 2 - Tomografia computadorizada de múltiplos detectores Figura 3 - Imagem em nível de cinza Figura 4 - Página Inicial do HIPR Figura 5 Exemplo de experimentação interativa Escala (Scaling) Figura 6 Página Inicial do CVonline Figura 7 Página Inicial do FIP com frames Figura 8 - Tela do Harpia Encadeamento de Funções Figura 9 - Arquitetura Backend-Frontend sendo executado em máquinas distintas. 36 Figura 10 Tela inicial do Adessowiki Figura 11 Diagrama de casos de uso Figura 12 Diagrama de Classe Figura 13 Associação/Multiplicidade entre as classes Usuario e Historico Figura 14 Estrutura XML do módulo do Adesso Figura 15 Estrutura XML do módulo do SPI via Web Figura 16 Exemplo de estrutura XML para a descrição de um módulo no SPI via Web Figura 17 Estrutura do XML do operador do SPI via Web

8 Figura 18 - Exemplo de estrutura XML para a descrição de um operador no SPI via Web Figura 19 Esboço da interface do SPI via Web Figura 20 Página Inicial do Aplicativo Figura 21 Página de Cadastro de Usuário do Aplicativo Figura 22 Página de Upload de Arquivos do Aplicativo Figura 23 Página de Operadores Figura 24 - Entradas de dados do operador Figura 25 Página de Inserção de Novos Operadores Figura 26 - Funcionamento do MVC Figura 27 - Funcionamento do Dajax Figura 28 - Estrutura dos arquivos Figura 29 - Carregamento dos operadores/funções Figura 30 - Carregamento das entradas do operador/função Figura 31 Execução de um operador/função Figura 32 - Histórico do sistema Figura 33 Verificação de utilização, organização e capacidade do sistema Figura 34 Aprendizado do Usuário Figura 35 Verificação de requisitos

9 LISTA DE TABELAS Tabela 1 Estudo das principais características dos trabalhos relacionados Tabela 2 Checklist dos requisitos levantados no projeto Tabela 3 Checklist das restrições levantadas no projeto

10 LISTA DE ABREVIATURAS CV CDD CID CMD DTD HIPR2 HTML IA636 MATLAB PI SaaS SPI SPIWeb SOA UML Unicamp URL XML Visão Computacional Charge Coupled Device Charge Injection Device Complementary Metal Oxide Semiconductor Document Type Definitions Hypermedia Image Processing Reference HyperText Markup Language Visão Computacional Matrix Laboratory Processamento de Imagens Software as a Service Sistema de Processamento de Imagens Sistema de Processamento de Imagens via Web Arquitetura Orientada a Serviços Unified Modeling Language Universidade Estadual de Campinas Uniform Resource Locator Extensible Markup Language

11 SUMÁRIO 1 INTRODUÇÃO TRABALHOS RELACIONADOS HIPR CVonline FIP HARPIA ADESSOWIKI CONSIDERAÇÕES FINAIS SPI VIA WEB - PROJETO PROPOSTA LEVANTAMENTO E ANÁLISE DE REQUISITOS Requisitos Restrições MODELAGEM Caso de Uso Atores/Usuários Diagrama de Casos de Uso Diagramas de Classes e MER Estrutura dos arquivos XML Arquivo de definição dos módulos (XML) Arquivo de definição dos operadores/funções Protótipo de telas Página inicial Página de Cadastro de Usuários Página de Upload de Arquivos Página de Operadores Página de Inserção de um Novo Operador SPI WEB DESENVOLVIMENTO IMPLEMENTAÇÃO Django Dajax Módulos e Operadores/Funções...73

12 Estruturação dos arquivos Funcionamento de execução dos operadores TESTES/RESULTADOS Resultados Checklist de verificação de requisitos e restrições CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A APÊNDICE B APÊNDICE C APÊNDICE D APÊNDICE E APÊNDICE F APÊNDICE G

13 13 1 INTRODUÇÃO As imagens, com o passar do tempo, tornam-se essenciais e indispensáveis na vida humana. Exemplo disto são as imagens de raios X, como mostra a Figura 1 e as de tomografia computadorizada, visualizadas na Figura 2. A partir destas, com o auxílio de tratamentos, pode-se descobrir diversos tipos de doenças, como tumores e cânceres, que de outra forma, seriam difíceis de serem diagnosticados. Com isso, a análise de imagens de forma automática ou semi-automática é uma ferramenta imprescindível para a resolução de problemas, além da área médica, em outros como na geologia, na astronomia, nas artes, na física, entre outros (SILVA, 2000). Figura 1 - Tratamento de imagem de raio-x: (a) imagem original; (b) aplicação de brilho; (c) pseudo-coloração; (d) auto-relevo. Fonte:

14 14 Figura 2 - Tomografia computadorizada de múltiplos detectores Fonte: Uma imagem pode ser considerada como uma matriz, onde os índices de linhas e colunas representam um ponto na imagem, denominado pixel, e o valor do elemento da matriz, ou seja, do pixel identifica o nível de cinza daquele ponto (GONZALEZ, 2000). Na Figura 3, tem-se um exemplo de imagem em níveis de cinza, aplicando-se um determinado aumento (zoom), encontram-se os pontos da imagem cada qual com uma intensidade. Figura 3 - Imagem em nível de cinza A área de processamento de imagens, segundo Gonzalez, surgiu da necessidade de melhorias de informações visuais para a interpretação humana e o processamento de cenas para a percepção automática através de máquinas. Na primeira categoria, tem-se o melhoramento de imagens digitais, como ajuste de tonalidade, brilho, contraste, aplicações de filtros. Na segunda categoria, se agrupam as soluções de problemas relacionados à percepção por máquina.

15 15 Existem inúmeros ambientes para processamento de imagens, tanto standalone como online. Os de stand-alone, possuem interfaces de programação visual atrativa, porém há a necessidade de instalação e em muitos casos precisa-se da aquisição de licença. Os desenvolvidos para internet, na sua maioria consistem de ajuda online para os usuários de forma interativa, possuindo em alguns casos demonstrações na linguagem JAVA com realizações de exercícios. Sendo assim, o objetivo geral desse trabalho é desenvolver uma ferramenta web para processamento de imagens, utilizando o melhor dos dois ambientes e disponibilizando operações referentes ao processamento de forma simples e intuitiva. Esse sistema será baseado no modelo SaaS, Software como um Serviço (Software As A Service em inglês), onde a atividade de laboratório não implique em problemas de aquisição de licenças ou instalação indevida de softwares, reduzindo a carga de trabalho de manutenção das máquinas. Este sistema será implementado para algumas funcionalidades de processamento de imagens, tendo como estudo de caso o módulo spiweb, criado a partir do IA636 da linguagem Python (SILVA, 2000). O módulo IA636, nome oriundo da sigla da disciplina de Visão Computacional da Unicamp, base de teste deste trabalho, é um conjunto de funções para Python para a manipulação de sinais (1D) ou imagens (2D). Este módulo abrange alguns tópicos como: a criação de imagens, processamento de cor, filtragem, transformações, manipulação, visualização, medidas, entre outras. A idéia do SaaS é construir um sistema e oferecê-lo como um serviço, implementado em plataforma web, sendo acessado utilizando tecnologias e protocolos da internet. Desta forma o cliente não compra um sistema/software mais

16 16 sim adquire o direito de usufruir do serviço (CLAUDIO, 2008). De acordo com Claudio, as principais vantagens de um sistema SaaS são: 1. Estrutura de Tecnologia de Informação (TI) simplificada: o cliente/usuário não precisa mais preocupar-se na estrutura, a não ser com uma instalação para acesso a internet. A estrutura é de responsabilidade de quem oferece o serviço; 2. Portabilidade: sendo um software para ambiente web, pode ser acessado por qualquer computador com acesso a internet e um navegador instalado; 3. Baixo custo de licenciamento: como a estrutura de TI é compartilhada entre vários clientes, os custos são reduzidos oferecendo assim um serviço mais acessível para pequenas e médias empresas; e 4. Propaganda e distribuição: a distribuição do serviço, na maioria dos casos, não necessita da criação da área comercial para a venda e distribuição do sistema. Cadastro em ferramentas de busca, anúncios em até mesmo outro SaaS, ou em sites específicos, são o que garantem ao software sua distribuição em escala. Entretanto, alguns detalhes devem ser vistos para esse tipo de sistema como, a Escalabilidade, Segurança e Usabilidade. Com relação à escalabilidade, é preciso que a estrutura suporte o crescimento de usuários. Cuidar da segurança e privacidade, pois como a estrutura é compartilhada pelos clientes, as empresas resistem em agregar no sistema informações referentes ao negócio (preço de produtos, carteira de clientes, etc.). E por fim o sistema terá que ter grande usabilidade, ou seja, deve ser de fácil utilização pelo usuário. E, além disso, deve

17 17 permitir uma boa customização do serviço (CLAUDIO, 2008). Um exemplo interessante é o Adobe Photoshop Express, uma versão simplificada e online (gratuita) do mais famoso software de edição de imagens. Outro exemplo é o Google Docs, o mais conhecido e utilizado de acordo com Freitas. Segundo Freitas, o Google Docs já possui mais de 100 usuários corporativos, sem contar com os usuários domésticos. Algumas das suas características são: Editor de texto, planilhas, apresentações e formulários. Existem ainda muitos outros exemplos como Microsoft Office Live Small Business (básico é livre), ThinkFree Online e o Zoho Show (apresentações na web). Além do SaaS tem-se também o SOA e o Cloud Computing. O SOA, Arquitetura Orientada a Serviços, é um estilo de arquitetura de software, cujo princípio fundamental está nas funcionalidades implementadas pelas aplicações, que devem estar disponibilizadas em forma de serviços (THOMAS, 2009). Uma implementação SOA, de acordo com Thomas, pode consistir de uma combinação de tecnologias, produtos, APIs, extensões da infra-estrutura de suporte e várias outras partes. Ela é baseada nos princípios da computação distribuída, utilizando-se do paradigma resquest/reply para realizar a comunicação entre os sistemas clientes e os sistemas que implementam os serviços. Neste caso, a orientação ao serviço, definido por Thomas, existem como programas de software fisicamente independentes, com características de design distintas que dão suporte à obtenção dos objetivos estratégicos associados à computação orientada a serviço. O modelo Cloud Computing, ou Computação em Nuvem, é um modelo de computação onde os dados, arquivos e aplicações residem em servidores físicos e virtuais, sendo acessíveis por meio de uma rede. Isso significa compartilhar ferramentas computacionais pela interligação dos sistemas, semelhante as nuvens

18 18 no céu, em vez de possuir essas ferramentas localmente. Desta forma o computador passa a ser somente um chip ligado a internet, a grande nuvem de computadores, sem a necessidade de instalação de programas, serviços e armazenamento de dados e sim dispositivos de entrada e saída para os usuários (NOGUEIRA, 2010). Entretanto, o modelo adotado neste trabalho será o SaaS, pois o SPI via Web, será um serviço gratuito disponibilizado pela internet para auxiliar estudantes da área. Os objetivos específicos para a execução são: a) Apresentar motivações para a construção do sistema SaaS de processamento de imagens; b) Estudo e construção de base de dados para as funções dos módulos que serão utilizados pela aplicação (spiweb); c) Avaliar os resultados, com testes e verificação do sistema. O presente trabalho está estruturado em quatro capítulos. No primeiro capítulo, são definidos os objetivos gerais e os específicos, algumas definições utilizadas no decorrer da pesquisa e a justificativa. O segundo capítulo apresenta o estudo de trabalhos relacionados, com o detalhamento de suas características e uma visão geral de seus funcionamentos. As vantagem e desvantagens de cada proposta são mencionadas. O terceiro capítulo abrange o projeto do sistema, ou seja, é realizada a modelagem em UML, seguindo os passos da engenharia de software. Nesta fase são levantados os requisitos, aspectos e funcionalidades do sistema. Descrição das plataformas utilizadas, como servidor, linguagens de programação, ferramentas para o desenvolvimento.

19 19 No quarto capítulo, o desenvolvimento do projeto é descrito, abrangendo a especificação das plataformas utilizadas, como servidor, linguagens de programação entre outras ferramentas. Os capítulos seguintes apresentam respectivamente, as considerações finais com as conclusões obtidas juntamente com sugestões para trabalhos futuros e as referências bibliográficas utilizadas na pesquisa.

20 20 2 TRABALHOS RELACIONADOS Neste capítulo serão apresentados os trabalhos relacionados ao projeto de SPI via Web, descrevendo suas funcionalidades, vantagens e desvantagens. 2.1 HIPR2 HIPR2, Hypermedia Image Processing Reference - Referência Hipermídia de Processamento de Imagem ajuda online para os usuários de processamento de imagens. Desenvolvido no Departamento de Inteligência Artificial da Universidade de Edinburgh, para ser utilizado em conjunto com cursos de processamento de imagens. Possui referências e informações tutoriais de uma série de operações de processamento de imagens, ilustradas com imagens e em um formato hipermídia de fácil navegação (FISHER, 2000). De acordo com Fisher, as suas funcionalidades são: Informações de cerca de 50 operações; Descrição de funcionamento de cada operação; Demonstração JAVA de cada operador; Mesa interativa, onde é possível realizar uma seqüência de operações;

21 21 Diretrizes de utilização de cada operação, com suas vantagens e desvantagens, bem como o momento certo de usa-lá; Possui exemplo de entrada e saída, com imagens que mostram os resultados; Exercícios e referências para cada operador; Tabela de operadores que são comuns para vários pacotes: VISILOG, Khoros e o Toolbox de processamento de imagem do MATLAB. O HIPR2 está dividido, ou melhor, é composto de seis partes: Guia do Usurário (User Guide), Folhas de Exercícios (WorkSheets), Experimentação Interativa (Interactive Experimentartion), Biblioteca de Imagens (Images Library), Outros Recursos do Usuário (Other User Resources) e o Conteúdo e Índice (Contents and Index). Isto pode ser melhor visualizado na Figura 4.

22 22 Figura 4 - Página Inicial do HIPR2. No Guia do Usuário estão contidas as informações e instrução de como utilizar o HIPR2, além da explicação sobre o que é o HIPR2. Nas Folhas de Exercício encontram-se todas as operações disponíveis do sistema, agrupadas em grupos, como aritméticas, geométricas entre outros. As operações são descritas seu funcionamento, como devem ser utilizadas, possuem exercícios bem como uma experimentação interativa, no final da explicação há referências de livros onde podem ser encontradas mais informações. Na Experimentação Interativa, podem-se aplicar os conceitos abordados nas Folhas de Exercícios. Essa experimentação pode ser realizada tanto com operações individuais bem como aplicando uma cadeia de operações. Nessas experimentações podem ser utilizadas as imagens disponíveis pelo sistema, armazenadas na Biblioteca de Imagens, como mostra a Figura 5.

23 23 Figura 5 Exemplo de experimentação interativa Escala (Scaling) Em Outros Recursos do Usuário há informações referentes a conceitos comuns em processamento de imagens, levantamento de operações comuns em determinados softwares como Khoros, MATLAB, Visilog e HIPS e da relação bibliografia abordada no sistema. E finalizando o Conteúdo e Índice, é a relação de todos os assuntos e conteúdos abordados pelo aplicativo. Com isso, tendo analisado o aplicativo em questão, destacam-se algumas vantagens e desvantagens: Vantagens: 1. Aplicativo simples, de fácil utilização, na forma de um tutorial. Porém podem-se realizar experimentações; 2. Não há a necessidade de instalação, é um aplicativo web. Sendo necessário apenas o plugin Java, que já em previamente instalados nos navegadores. 3. Possui um guia de utilização para usuários iniciantes; 4. Nas Folhas de exercícios seguem sempre uma estruturação: uma breve descrição do operador, de como funciona, como deve ser utilizado, uma experimentação prática, exercício e as referências bibliográficas auxiliares;

24 24 5. Utilização de Applet Java para a experimentação dos operadores. Contém juntamente informações de como executar esse Applet, como devem ser carregadas as imagens e as instruções do operador; 6. Disponibilização do código fonte da experimentação na linguagem de programação JAVA; 7. Mostra o tempo de execução de um operador; 8. Possui a opção de encadeamento de operadores. Nessa opção há instruções de como deve ser utilizado; Desvantagens: 1. Sistema todo em inglês, sem a possibilidade de mudança de idioma. Exigência de inglês como pré-requisito; 2. As imagens utilizadas pelo aplicativo na experimentação, podem ser somente via URL, ou seja, aquelas existentes na sua biblioteca de imagens ou qualquer imagem da web, restringindo a extensão GIF. Desta forma o usuário não poderá utilizar imagens que estão armazenadas em seu computador; 3. Não possui nenhum tipo de aviso de carregamento da imagem, a única informação é o travamento do botão de upload; 4. Não existe nenhuma opção de poder salvar a imagem gerada na experimentação individual e no encadeamento de operações; 5. No encadeamento de operações os componentes estão dispostos em um menu drop-down, dificultando desta forma um pouco a sua utilização. Pois os operadores não são facilmente visíveis; Levando em consideração as vantagens e desvantagens do HIPR2, verificase que esse aplicativo segue uma linha de tutorial, opção de realização de

25 25 experimentações dos operadores. Tendo em vista que uma das características é a possibilidade de encadeamento de operações, esse seria um requisito para o desenvolvimento do aplicativo disposto nesse trabalho. Além disso, outro requisito seria além da possibilidade de upload de imagens via URL, realizar upload do computador utilizado. Sendo assim, do aplicativo web HIPR2 pode-se tirar alguns requisitos básicos que o sistema SPI via Web deverá possuir, como, um sistema de upload de imagens de fácil utilização, armazenamento das imagens geradas pelo aplicativo bem como a possibilidade de encadeamento de funções. 2.2 CVONLINE O CVonline, On-Line Compendium of Computer Vision Compêndio de Visão Computacional, visto na Figura 6, é uma base de artigos ligado ao HIPR2. Trata-se de uma coleção de tópicos centrais da visão computacional em formato de hipertexto, ou seja, é uma base de artigos sobre processamento de imagens e visão computacional. Possui um índice com cerca de 700 tópicos (nível superior), pretendendo ser um resumo de métodos e aplicações de visão computacional, organizando em seções dos principais temas da prática e pesquisa. Cada seção contém um conjunto de tópicos e estes estão ligados a um conjunto de materiais e artigos (FISHER, 2007).

26 26 Figura 6 Página Inicial do CVonline. Compêndio, segundo o Dicionário Michaelis, é o nome que se dá a um resumo dos conhecimentos relativos a uma dada área do saber, em forma de livro. Como exemplos, um compêndio de Física engloba em si os conhecimentos considerados mais importantes desta ciência ou uma enciclopédia é um compêndio do conhecimento humano. Este compêndio foi criado com a intenção de auxiliar os pesquisadores, professores e mesmo os acadêmicos, que muitas vezes não tem condições de adquirir livros na área de PI e visão computacional. Desta forma, todos podem colaborar com notas e artigos para o crescimento do compêndio, que em 2007 já possuía cerca de 3000 contribuições. Entretanto esse sistema é desenvolvido todo na linguagem inglesa (FISHER, 2007). Como descrito anteriormente, possui formato de hipertexto. Ou seja, é mais um recurso on-line para auxiliar em assuntos e pesquisas relacionadas na área de PI. A página inicial está estruturada da seguinte maneira: Informações antecedentes (Background information), Sumário do Compêndio (Compendium Contents), Busca no Compêndio On-line (Search the Online Compendium), Recursos Educativos

27 27 Adicionais de Visão (Additional Vision Educational Resources), Cursos Especiais de Visão (Special Vision Courses), Recursos Comerciais Educativos de Visão (Commercial Vision Educational Resources), Administração (Administration) e Outros Sites CVonline (Other CV Online Sites). Em Informações antecedentes (Background information) são exibidas informações referentes do que é o CVonline, como pode-se utilizar os materiais, como estar fazendo uma colaboração obtendo desta maneira obtêm identificação pública como contribuinte, satisfação de ter feito uma contribuição comunitária e além de porque em vez de escrever um livro contribuir para este compêndio (FISHER, 2007). No Sumário do Compêndio (Compendium Contents) os assuntos seguem uma hierarquia, sendo abordados desde aplicações, bases de dados e indexação, métodos genéricos de visão, geometria e matemática, transformações de imagens e filtros, sensores e suas propriedades, software processamento visual & ambientes, entre outros. Além disso, existe link para livros de visão relacionados, incluindo livros online e sites de livros de apoio (FISHER, 2007). Em Busca no Compêndio On-line (Search the Online Compendium), nada mais é do que uma caixa de pesquisa para o compêndio. Já os Recursos Educativos Adicionais de Visão (Additional Vision Educational Resources), são links para sites externos que podem estar complementando estes materiais. Exemplo o HIPR2, ferramenta estudada anteriormente, Página de Visão Computacional (Computer Vision Home Page), etc. (FISHER, 2007). Na seção Cursos Especiais de Visão (Special Vision Courses), tem-se uma lista de cursos para os interessados, como Mestrado em Visão e Robótica. Já em Recursos Comerciais Educativos de Visão (Commercial Vision Educational

28 28 Resources), listagem de links comerciais para quem deseja ir mais além (FISHER, 2007). Exemplos são: Enlighten3D Vision Blog, um blog sobre visão e os sistemas gráficos e Fundações e Tendências em Computação Gráfica e Visão, revista especializada em pesquisa de alta qualidade e tutorial de monografias. Em Administração (Administration), estão as informações referentes a administração deste projeto, instruções de como contribuir, questões de Copyright relacionado ao CVonline e o para quem desejar realizar comentários e sugestões. E em Outros Sites CVonline (Other CV Online Sites), mostra que existem outros sites CV, como o site da Hungria. Desta forma, tendo avaliado as suas características, pode-se destacar algumas vantagens e desvantagens: Vantagens: 1. Sistema simples e organizado, de fácil utilização pelos usuários, pois é um sistema de hipertexto. Segue o estilo tutorial, compêndio; 2. Possui um vasto conteúdo, abrangendo assuntos de PI e Visão Computacional, separados por assuntos; 3. Não há a necessidade de instalação, pois é um sistema web; 4. Interligado com o HIPR2. Desta forma, os usuários podem aplicar alguns de seus conhecimentos adquiridos. Desvantagens: 1. Sistema todo em inglês, sem a possibilidade de mudança de idioma. Exigência de inglês como pré-requisito; 2. O sistema não tem a possibilidade de realização de testes. Ou seja, não possui a parte prática;

29 29 3. A página inicial poderia estar mais bem organizada, ou seja, poderia existir uma explicação breve do que se trata o site, e um menu. Neste menu, estariam as todas as partes apresentadas, onde cada qual levaria a sua explicação. Tendo em vista as vantagens e desvantagens do CVonline, tem-se que esse aplicativo segue uma linha de tutorial, de um compêndio. Ou seja, de uma pequena enciclopédia de PI e CV. Neste caso, este sistema ou aplicativo, teria somente um requisito para o desenvolvimento do aplicativo desta pesquisa, que seria a documentação de cada função do spiweb. Já que o sistema estudado não apresenta aplicação e sim somente documentação. 2.3 FIP O FIP, Image Processing Fundamentals Fundamentos de Processamento de Imagens é um curso interativo dos fundamentos de processamento de imagem em páginas dinâmicas. Existem três versões dessa hipermídia, uma em versão normal, outra baseada em frames, sendo que nesta última, há um menu interativo construído na linguagem JAVA e ainda uma versão interativa com exercícios, Porém esta última versão não está mais em funcionamento. Este curso abrange definição de imagem digital, ferramentas, percepção, amostragem, ruídos, câmeras, algoritmos e técnicas (YOUNG, 2005). A versão com frames é dividida em três partes ou frames, visualizada na Figura 7. No frame localizado à esquerda, tem-se o menu interativo, construído em Applet Java. No frame direito superior, há um

30 30 segundo menu, este serve para a navegação no aplicativo, como botões de anterior e próximo, topo, subir, sumário e glossário. Figura 7 Página Inicial do FIP com frames O menu do FIP divide-se em doze assuntos: Introdução (Introduction), Definições de Imagem Digital (Digital Image Definitions), Ferramentas (Tools), Percepção (Perception), Amostragem de Imagem (Image Sampling), Ruído (Noise), Câmera (Cameras), Visores (Display), Algoritmos (Algorithms), Técnicas (Techniques), Agradecimentos (Acknowledgements) e Referências (References). Na Introdução, é realizada uma descrição do que vem a ser uma imagem e a divisão em três categorias, Processamento de Imagem (Imagem Processing), Análise de Imagem e Entendimento/Compreensão da Imagem. Em Definições de Imagem Digital, há uma subdivisão de tópicos. Uma breve Introdução, definindo a imagem digital. Em seguida, Valores comuns (Common values), valores padrão utilizados em vários parâmetros encontrados em

31 31 processamento de imagens digitais. Depois, têm-se Características das Operações de Imagens, relata como classificar e caracterizar as operações em imagens. E por ultimo, Parâmetros de vídeo descrevem os tipos de vídeos padrão que estão sendo utilizados atualmente. Em Ferramentas, são apresentadas algumas ferramentas que são fundamentais para processamento de imagens digitais. As ferramentas abordadas neste tópico são: Convolução e suas Propriedades, Transformada de Fourier e suas Propriedades, Estatísticas e Representação de Contorno. O tópico Percepção trata em compreender as característica e limitações do sistema visual humano, para que seja possível compreender o receptor de sinais 2D. Engloba Sensibilidade do Brilho, Sensibilidade da Freqüência Espacial, Sensibilidade de Cores e por fim Ilusão de Ótica. Em Amostragem de Imagem explica há necessidade de um espaço de amostragem para a conversão de uma imagem contínua em representação digital. Além de explicar o que é um espaço de amostragem. Contempla os assuntos como Amostragem por Densidade para processamento de imagens e para análise de imagens. Na captura das imagens pode haver contaminação de ruídos, abordagem do próximo tópico, Ruídos. Estes ruídos são as variações estocásticas, distorções como sombreamento ou falta de foco. Assuntos tratados: Ruído fóton, Ruído térmico, Ruído Eletrônico On-chip, Ruído KTC, Ruído Amplificador e Ruído de Quantização. O tratamento dos sensores de capturas de imagens é realizado em Câmeras. Aborda o tipo de câmera mais importante, como a CCD e ignora as CID e CMOS. Abrange sub-tópicos como: Linearidade, Sensibilidade, Sombreamento, Forma do

32 32 Pixel, Sensibilidade Espectral, Velocidade do Obturador (Tempo de Integração) e Taxa de Leitura. Os Visores, ou mesmo, Displays, oitavo tópico do sistema, retrata que estes visores possuem características que ajudam a determinar a qualidade da imagem final. As mostradas por Young são: Taxa de Atualização (Refresh Rate), Entrelaçamento (Interlacing) e Resolução (Resolution). No tópico Algoritmos são descritos as operações que são fundamentais para PI (YOUNG, 2005). Segundo Young, são divididas em quatro categorias: operações baseadas no histograma de imagens, em matemática simples, em convolução e morfologia matemática. Sendo que estas, podem ser descritas em termos de implementação como operação em um ponto, operação local e operação global. As operações destacadas por Young são: Operações baseadas em Histograma, em Matemática, em Convolução, Operações Suavizadoras, Operações baseadas em Derivadas e Operações baseadas em Morfologia. No tópico das Técnicas os algoritmos apresentados na seção anterior são utilizados para construir técnicas específicas para resolver problemas relativos à PI. Apresenta alguns exemplos de modelos que podem ser usados para a resolução de problemas, como Correção de Sombreamento, Reforço Básico e Técnicas de Restauração e Segmentação (YOUNG, 2005). Nos últimos tópicos, Agradecimentos e Referências, são feitos os devidos agradecimentos e as referências utilizadas para a construção deste sistema, ou melhor, tutorial de PI. Além desses tópicos ainda possui um Glossário e um Sumário. O Glossário ainda está em construção e o Sumário apresentada todos os tópicos e sub-tópicos em um menu expandido.

33 33 Tendo assim realizado um estudo sobre o FIP, podem-se relacionar algumas vantagens e desvantagens desse sistema: Vantagens: 1. Aplicativo simples, fácil navegação, tanto na versão com frames e na versão normal. 2. A versão sem frames serve para usuários iniciantes, como um tutorial, seguidos passo a passo. Enquanto a com frames, já pode ser utilizada por usuários um pouco mais experientes, já que contém um menu interativo. Porém, este último, pode ser utilizado por iniciantes também, pois há como utilizá-lo passo-a-passo. 3. Menu interativo, em Applet Java. 4. Abrange todos os assuntos relacionados à PI, para usuários iniciantes. 5. Não há a necessidade de instalação, pois é um aplicativo web; Desvantagens: 1. Como os demais trabalhos relacionados, está todo em inglês, sem a possibilidade de mudança de idioma. Exigência de inglês como prérequisito; 2. O sistema não tem a possibilidade de realização de testes. Ou seja, não possui a parte prática. A única coisa interativa seria o menu, na versão frame; Levando em consideração as vantagens e desvantagens do FIP, tem-se que esse aplicativo segue uma linha de tutorial, que se pode utilizá-lo seguindo passo-apasso. Neste caso, teria somente um requisito para o desenvolvimento do aplicativo

34 34 desta pesquisa, a documentação de cada função do spiweb. Já que o sistema estudado não apresenta aplicação prática, como o CVonline e sim somente documentação. 2.4 HARPIA O aplicativo Harpia é um software livre e uma Ferramenta Gráfica para Aprendizado, Implementação e Gerenciamento de Sistemas de Visão. Desta forma o desenvolvedor do sistema, não precisa ter grandes conhecimentos das tecnologias utilizadas no projeto de um sistema de visão. Possui um ambiente gráfico que permite a construção de diagramas de blocos de maneira intuitiva e simples (JUNGLES, 2007), visualizado na Figura 8. Disponibilizado para aplicações no meio industrial e no meio acadêmico, auxiliando desta forma o desenvolvimento de sistema de controle de qualidade de produtos e processos baseados em sistemas de visão.

35 35 Figura 8 - Tela do Harpia Encadeamento de Funções Fonte: Erdtmann, O sistema Harpia trabalha com a arquitetura Backend Frontend. Segundo Erdtmann, em uma arquitetura Backend Frontend um aplicativo é executado a partir de dois programas, executado ou não na mesma máquina, que se comunicam através de mensagens. Se forem executados em máquinas diferentes, seria interessante que fossem utilizados protocolos de rede padrão para executar a troca de mensagem, facilitando a implementação e a manutenção do aplicativo. A parte de Backend é responsável pela execução de tarefas complexas, tem alto desempenho. Por isso, usar esse programa diretamente pode ser complexo, pela quantidade de parâmetros e pela interface precária (programa em modo texto). Já o Frontend, tem a função de apresentar de forma mais amigável e simples as

36 36 funcionalidades implementadas no Backend (programa com interface gráfica) (ERDTMANN, 2006). Na Figura 9, tem-se à arquitetura Backend-Frontend. No Harpia, de acordo com Erdtamnn, o Frontend possui as seguintes funcionalidades: Figura 9 - Arquitetura Backend-Frontend sendo executado em máquinas distintas Fonte: Erdtmann, Interface para a criação e manipulação do diagrama de blocos; Interface para seleção das imagens envolvidas; Armazenar as cadeias de processamento em formato XML; Seleção dos parâmetros dos blocos da cadeia de processamento. E o Backend tem as seguintes funcionalidades (ERDTMANN, 2006): Converter as cadeias de processamento de XML para código fonte em C; Compilar e executar a cadeia de processamento; Receber e retornar as imagens e resultados envolvidos. A interface apresenta três áreas principais: a árvore de blocos, a área de ajuda do bloco e a área de trabalho. Na árvore de blocos, localizada na parte esquerda superior, estão disponíveis os blocos de operações (aritméticas, lógicas, etc.), de uso geral (salvar imagem, mostrar imagem, aquisição, histograma, etc.) entre outros. Na área de ajuda do bloco, localizada na parte esquerda inferior,

37 37 aparece uma pequena explicação do que o bloco escolhido faz. Esta última pode ser aberta como uma janela contendo as propriedades, aparência e ajuda. E por ultimo, a área de trabalho, é nela que são montadas as cadeias de processamento (JUNGLES, 2007). Tendo avaliado as suas características e realização de testes, podem-se destacar as seguintes vantagens e desvantagens: Vantagens: 1. Interface gráfica simples e intuitiva; 2. Aplicativo prático, contendo explicações dos operadores; 3. Encadeamento de operadores; 4. Possui campo de busca para auxiliar na procura dos operadores; 5. Possui versão em língua portuguesa, não sendo necessário a compreensão de outro idioma, como nos demais sistemas; Desvantagens: 1. O aplicativo Harpia, mesmo sendo livre, necessita de instalação. Além disso, sua instalação é um pouco complicada. Tendo estudado as suas vantagens e desvantagens, esse aplicativo segue mais a linha prática. Nele pode-se construir qualquer tipo de aplicação na área de processamento de imagens. Deste aplicativo o que seria interessante para o projeto proposto, é a interação com o usuário que é realizado pelo Harpia. Não seria a construção de blocos de operações, mais somente a interação, a opção de escolha de operadores, de imagens, entre outros.

38 ADESSOWIKI O Adessowiki é um ambiente colaborativo para desenvolvimento, documentação, ensino e propagação de algoritmos de computação científica. É composto de páginas web de edição colaborativa formando assim um wiki, onde os artigos podem incluir partes de programas. Esses programas são executados no servidor durante a sua formatação, com isso os resultados são colocados no artigo em formato de figuras, textos e tabelas (ADESSOWIKI, 2009). Utiliza-se da linguagem Python e C/C++. Na página inicial do Adessowiki, visualizada na Figura 10, há uma breve apresentação, em seguida, um link para uma explicação mais detalhada e um link para Ajuda. Além de uma área de exemplos e de scripts e toolboxes. Figura 10 Tela inicial do Adessowiki. Na área de exemplos, contêm exemplos de códigos, com seus respectivos resultados. E na área de scripts e toolboxes, mostra como está organizado o

39 39 Adessowiki, como está criando toolboxes em Python e em C/C++, como está executando o código Python. Desta forma podem-se destacar algumas vantagens e desvantagens (ADESSOWIKI, 2009). Vantagens: 1. Aplicativo web, ou seja, não há a necessidade de instalação ou configuração; 2. Aplicação e servidor centralizado. Fácil a atualização e manutenção; 3. Base de imagens centralizada; 4. Aplicação prática, porém não de forma interativa. O usuário deve conhecer a linguagem de programação. Desvantagens: 1. Algumas partes do sistema estão em linguagem estrangeira (inglês). Desta forma o usuário deve possuir algum conhecimento na linguagem; 2. Quanto à interface do usuário, navegação e organização dos documentos, o sistema pode crescer e ficar caótico e desorganizado; 3. Escalabilidade para expandir o sistema, para que vários usuários possam acessar o sistema simultaneamente. Levando em consideração as características estudadas do Adessowiki, este aplicativo segue a linha tutorial, com a possibilidade de inserção de programação. Desta maneira, seria interessante que o sistema proposto aceite a inserção de código fonte, porém não é o objetivo desse trabalho. Na ferramenta proposta, a intenção é trabalhar mais com a interação com usuário.

40 CONSIDERAÇÕES FINAIS Tendo em vista o estudo realizado sobre os trabalhos correlacionados, podem-se através de suas principais características formular a Tabela 1. Na última coluna, está à proposta do projeto SPI via Web. A tabela está dividida em oito características principais: - Estilo Tutorial/Programação: define se o sistema segue uma linha de tutorial, de programação ou ambos; - Utiliza Java: define se o sistema em questão utiliza-se de Applets Java. - Fácil extensão: define se há possibilidade do sistema crescer, acrescentando novas funcionalidades; - Encadeamento de operações: define se no sistema há a possibilidade de realizar o encadeamento de operações; - Necessária a instalação/executado no navegador: define se para utilizar o sistema é necessário a instalação do mesmo, ou pode-se acessar via navegador; - Instalação em servidor próprio: define se no sistema há suporte à instalação em servidor local (próprio). Isso não diz respeito ao usuário do sistema, que necessita somente de conexão com internet; - Documentação da ferramenta: define se há uma documentação sobre a ferramenta, para entendimento do software, ou seja, sobre seu desenvolvimento.

41 41 HIPR2 CVonline FIP Harpia Adessowiki SPI Web Estilo Tutorial / Tutorial / Tutorial / Tutorial Tutorial Tutorial Programação Programação Programação Programação Utiliza Java Sim Não Sim Não Não Não Fácil extensão Sim Sim Sim Sim Sim Sim Encadeamento de operações Necessária instalação / Executado no navegador Instalação em servidor próprio Documentação da ferramenta Sim Não Não Sim Sim Sim Navegador Navegador Navegador Instalação Navegador Navegador Não Não Não Sim Não Sim Não Não Não Sim Sim Sim Tabela 1 Estudo das principais características dos trabalhos relacionados. Levando em conta as características levantadas, para que o projeto tenha diferenciais em relação às demais deve: - Ter um ambiente de programação que possua documentação ágil (dinâmica) e simplificada, como o Adessowiki e o Harpia; - Nenhuma dependência de software (máquina virtual ou plugins) do lado do usuário, como o Cvonline, Harpia e Adessowiki (o Adessowiki não tem nenhuma dependência); - Realizar encadeamento de operações, ou seja, uso das saídas de uma função eventualmente como entrada para outras, como no HIPR2, Harpia e o Adessowiki. Porém, esse último é via programação; - Sem a necessidade de instalação, ou seja, que seja somente executado no navegador. Neste caso todos atendem, exceto Harpia; - O sistema deve possuir suporte para a instalação em servidor local, ou seja, ter uma opção de download do sistema com documentação e instalação simplificada. Desta forma existe a possibilidade de alteração de código por parte do usuário, adicionando assim novas funcionalidades, resolvendo muitas vezes os problemas de conexão

42 42 por congestionamento. Nenhum sistema tem a opção de download além do Harpia, que é um software de instalação; - E por último a documentação da ferramenta, nesse projeto requer-se um ambiente mais intuitivo, evitando a necessidade de leitura de material extenso para a utilização do sistema. Todos os sistemas possuem algum tipo de ajuda, de explicação sobre o sistema em si, mas muito precário. Desta forma conclui-se que para que este projeto se torne um diferencial entre os demais, é necessário que possua todas as características acima citadas.

43 43 3 SPI VIA WEB - PROJETO Nesta etapa segue-se o desenvolvimento do projeto do Sistema de PI via Web. Este projeto segue as etapas da Engenharia de Software, nas quais se destacam: Planejamento/Projeto/Proposta, Levantamento e Análise de Requisitos, Modelagem (Diagramas, Protótipos, Base de Dados), Implementação, Testes/Resultados, Documentação do Sistema (PRESSMAN, 2002). As fases de Implementação, Testes/Resultados e Documentação do Sistema serão vistos no próximo capítulo. 3.1 PROPOSTA A proposta do Sistema PI via Web é prover uma interface gráfica na web para a utilização de qualquer módulo de funcionalidades da linguagem de programação Python, com algumas outras funcionalidades criadas para melhor utilização do sistema. O módulo teste utilizado será o spiweb, podendo ser estendido para os demais módulos. Este sistema SaaS, que é nada mais que um software disponibilizado pela internet, será software livre, podendo ser usado como auxílio didático em PI. Quanto à escolha da linguagem Python para o desenvolvimento deste projeto, é pelo fato de ser um ambiente interpretado e dinâmico de programação. Esse tipo

44 44 de ambiente tem suas desvantagens, como o desempenho de execução, sendo menos eficiente que soluções compiladas, especialmente em trechos de código com comando de repetição. Além disto, a linguagem Python, possui sintaxe simples, recursos modernos, implementação de estruturas de dados complexas e funcionalidades básicas nativas diversificadas. E também é apropriado para teste de conceito, a partir do desenvolvimento rápido de algoritmos e verificação dinâmica de seu correto funcionamento. Esta interface deve apresentar uma forma intuitiva de operar as funções do módulo, ou seja, mostrar as funções de uma forma que o usuário possa compreender e aplicar de forma fácil, como uma caixa de seleção. Para isso as páginas serão construídas dinamicamente de acordo com as informações contidas no XML. 3.2 LEVANTAMENTO E ANÁLISE DE REQUISITOS Nesta seção, serão definidos os requisitos necessários para a implementação do sistema, através de uma listagem e uma breve descrição dos requisitos. Os requisitos de um sistema são as descrições das suas funções que este deve possuir bem como as restrições que devem ser satisfeitas. Ou seja, são os serviços que o sistema deve fornecer (SOMMERVILLE, 2003) Requisitos Os requisitos serão divididos de acordo com uma prioridade, seguindo alguns critérios. Estas prioridades serão: Alta, Média e Baixa.

45 45 - Alta: o sistema deve obrigatoriamente ter, sendo essencial para o bom funcionamento e o cumprimento da proposta do projeto; - Média: são requisitos desejáveis, mas não essencial para o funcionamento do sistema. Caso não haja o cumprimento deste, não prejudica o andamento do projeto; - Baixa: são requisitos que não são necessários para o funcionamento do sistema, de certa forma desejáveis, sendo um recurso interessante, facilitador. Desta forma, os requisitos para o funcionamento do sistema seguem abaixo: 1. Deve existir uma área para o uso das operações. Prioridade: Alta Descrição: Área destinada para a manipulação dos operadores/funções. Esta área estará subdivida em outras duas subáreas: Área de escolha da função/operação: nessa área é realizada a escolha da função/operação a ser executada. Área da função/operação: área destinada para a execução da função/operação. Esta área será construída dinamicamente de acordo com a função/operação solicitada. 2. Deve existir uma caixa de seleção para a escolha do módulo a ser utilizado na área de escolha de função/operação. Prioridade: Alta Descrição: A existência da opção de escolha do módulo torna a escolha das funções/operadores mais fácil e ágil, pois estão separadas de acordo com suas características.

46 46 3. Deve existir uma caixa de seleção para a escolha de funções de um determinado módulo na área de escolha de função/operação. Prioridade: Alta Descrição: A partir da escolha de uma função, o formulário é criado automaticamente através do XML de acordo com cada função (entradas e saídas). 4. Deve existir uma área para o upload de arquivos, como imagens, scripts Python e arquivos XML (novas funções). Prioridade: Alta Descrição: Nessa área deverá existir um campo para upload de imagens. Sendo que a escolha das imagens tanto pode ser da base do sistema, de URL (de outra base de imagens disponíveis na internet) ou de upload do computador utilizado. 5. Deve existir uma subárea para a galeria de imagens, dos arquivos disponíveis no sistema, na área de upload de arquivos. Prioridade: Média Descrição: Esta área estaria à disposição do usuário para a que possa verificar que tipos de imagens e arquivos disponíveis. 6. Deve existir uma subárea com as entradas dos valores dos parâmetros da função escolhida, na área da função/operação. Prioridade: Alta Descrição: A área deve possuir campos de acordo com os parâmetros de cada função/operação. Ou seja, essa área deve ser construída dinamicamente, com a escolha da função/operação. 7. Deve existir uma subárea com informações/ajuda da função utilizada,

47 47 na área gerada da função/operação. Prioridade: Média Descrição: A página gerada da função deve possuir uma área contendo as informações referentes a função, como seus parâmetros de entrada e saída, seu código fonte e um pequeno exemplo de utilização de código. 8. A área da função/operação deve possuir uma sub-área com as saída das funções/operações realizadas. Prioridade: Alta Descrição: A área de saída da função/operação deve possuir os resultados obtidos na execução dos operadores. 9. Deve existir uma área para possibilidade de criação de novas funções/operações pelos usuários. Prioridade: Média Descrição: Esta área deve conter já pré-carregado em um campo de texto uma estrutura/modelo XML. 10. Deve existir a possibilidade de encadeamento de operações, com geração de script Python final com opção de download. Prioridade: Média Descrição: A cada execução de uma operação, deve haver a possibilidade de utilizar as suas saídas em outras funções. No final deve gerar um script Python para download, desta forma o usuário possa testar o código. 11. O sistema deve possuir uma área com os históricos do usuário. Prioridade: Baixa

48 48 Descrição: O sistema deve possuir uma área com os históricos das imagens, funções, arrays gerados/utilizados pelo usuário na seção atual. 12. O sistema deve possuir uma área de inicial de login. Prioridade: Alta Descrição: O sistema deve possuir uma área inicial de login para o seu acesso, para controle de usuários e para que seja possível a execução dos históricos. 13. Deve existir uma área para cadastro de novos usuários. Prioridade: Alta Descrição: O sistema deve possuir uma área para a realização de cadastramento de novos usuários. Deve ser composto de campos como: nome completo, , senha para acesso no sistema. Além do nome do curso (caixa de seleção), instituição de ensino (universidade, escola ou empresa) e o estado/cidade. Os requisitos levantados têm como base as características abordadas anteriormente. Há alguns requisitos que não tem como base nenhuma característica, mais são o diferencial deste projeto, como o sistema de login, a área de histórico bem como a opção de download do script Python da função utilizada. Além disso, estes requisitos poderão ser utilizados para a validação do projeto na fase de testes, através de um checklist. Desta forma os usuários testam a funcionalidade do sistema e verificam se estão de acordo com os requisitos levantados.

49 Restrições As restrições para o bom funcionamento do sistema são: 1 O usuário somente poderá utilizar o sistema se possuir cadastro e estiver logado; 2 O sistema será inicialmente limitado para trinta (30) usuários simultaneamente por servidor (e haverá total independência de um servidor para outro, exceto o registro de login de usuários que deverá ser comum a todos); 3 No upload de imagens será aceito inicialmente somente a extensão PGM, ou seja, imagens em níveis de cinza. E um tamanho máximo de 304 kb (640 x 480 pixels, se arquivo representado com 1 byte por pixel). Estas restrições servem para limitar o sistema em certas situações. Como na quantidade de usuários utilizando o sistema ao mesmo tempo e o tamanho da imagem, resolvendo o problema com a transferência de dados e largura de banda. 3.3 MODELAGEM Na modelagem é criada a estrutura base do sistema, através de ferramentas auxiliares como a UML, respeitando e implementando os requisitos levantados. A UML é uma linguagem visual para especificação, documentação, visualização e construção de sistema, sendo desta forma considerada uma das linguagens para a modelagem de sistemas. O sistema deve ser projetado de forma que novos módulos possam ser agregados posteriormente, habilitando novas funções/operadores para o usuário.

50 50 Tendo isso em vista, o carregamento dos módulos/funções será realizado através de arquivos XML, contendo as informações necessárias para a construção das páginas relativas às funções/operações. Desta forma, para melhor entendimento do sistema e utilizar os recursos que a linguagem UML oferece, criaram-se os diagramas mais utilizados Caso de Uso Nesta fase da modelagem, as necessidades dos usuários são expressas através do uso de funções denominadas caso de uso. Os casos de usos, segundo Fowler, são uma técnica para capturar os requisitos funcionais de um sistema. Servem para descrever as interações entre os usuários e o sistema, fornecendo informações de como o sistema é utilizado (FOWLER, 2005) Atores/Usuários Os atores, ou usuários do sistema são: - Usuário: qualquer pessoa interessada em processamento de imagens. - Sistema: responsável pela execução das tarefas requisitadas pelo usuário Diagrama de Casos de Uso No diagrama de casos de uso são definidas as interações entre o usuário e o sistema. Neste caso (Figura 11), o diagrama mostra todas as atividades que o usuário pode realizar no sistema. Os casos de uso estão separados em cinco áreas:

51 51 Login : responsável pelas atividades de cadastro de usuário e login no sistema; Upload de Arquivos : responsável pela inserção de novos arquivos (imagens, scripts Python) e visualização destes; Operadores : atividades referentes à escolha e execução de um operador/função. Com acesso à ajuda do operador/função; Novos Operadores/Funções : responsável pela atividade de inserir novos operadores/função; Histórico : interação de visualização dos históricos de operadores, imagens e arrays. Com a opção de download dos arquivos; Acessar ajuda do Sistema : acesso à ajuda/documentação do sistema.

52 52 Figura 11 Diagrama de casos de uso Diagramas de Classes e MER O diagrama de classes, segundo Folwer, descreve os tipos de objetos presentes no sistema e os vários tipos de relacionamentos estáticos existentes entre eles. Mostram as propriedades/atributos/associação e as operações de uma classe

53 53 e as restrições que se aplicam a maneira como os objetos estão conectados, ou seja, a sua multiplicidade (FOLWER, 2005). Já o MER, ou Modelo Entidade- Relacionamento, serve para representar as estruturas de dados de forma mais próxima do mundo real. Neste projeto o MER será apresentado no mesmo diagrama de classe, podendo ser visualizado na Figura 12. Figura 12 Diagrama de Classe. O sistema é formado por cinco classes principais (Figura 12): Modulo, Operador, Arquivo, Historico e Usuario. O Modulo contêm informações referentes aos módulos, como nome, quantidade de operadores e uma descrição, sendo que um Modulo, por ter um ou mais operadores. Na classe do Operador

54 54 encontram-se informações dos operadores, como nome, parâmetros de entrada e saída, tipos de entradas e saídas, módulo pertencente, descrição e exemplos. A classe Usuario é responsável por conter os dados dos usuários, entre eles, o nome, , senha, instituição de ensino, cidade e estado. Já na classe Arquivos estão os dados dos arquivos do sistema (nome, tipo, tamanho e data de inserção). Um Usuario pode ter muitos arquivos, mais um arquivo pode pertencer a um Usuario. Bem como o Historico, um Usuario poderá ter somente um Historico. Onde o Historico, contêm o código Usuario, código do arquivo, código do Operador e data de inserção. No diagrama de classes, as propriedades, segundo Folwer, representam as características estruturais de uma classe e aparecem em duas notações bastante distintas: atributos e associações. Os atributos descrevem uma propriedade como sendo uma linha de texto dentro de classe em si. Como exemplo, tem-se na classe Operador, o atributo nome, como seu respectivo tipo de objeto. A associação é uma linha cheia entre as classes, saindo da classe de origem para a classe de destino e juntamente está a multiplicidade. A multiplicidade é a indicação de quantos objetos podem preencher a propriedade, com um limite inferior e um limite superior. As mais usadas são: 1 (uma classe x tem exatamente uma outra classe), 0..1 (uma classe x pode ter ou não outra classe), * (uma classe x não precisa ter outra classe ou não existe nenhum limite superior). Exemplo, na Figura 13, tem-se as classes Usuario e Historico, conectados pela associação de 1 para 1, ou seja, para cada Historico existe um e somente um Usuario.

55 55 Historico +usuario: Usuario +arquivo: Arquivo +operador: Operador +data_insercao: Date +visualizarhistorico(): void +adicionaraohistorico(): void Usuario 1 +nome: String + String +senha: String +curso: String +instituicao_ensino: String +cidade: String +estado: String 1 +cadastrarusuario(): void +login(): void Figura 13 Associação/Multiplicidade entre as classes Usuario e Historico. De acordo com Folwer, as operações são as ações que uma classe pode realizar, são os métodos presentes em uma classe. Como exemplo, tem-se na classe Usuario, a operação cadastrarusuario() Estrutura dos arquivos XML Nesta seção, estão especificadas as estruturas dos arquivos XML, que serão utilizados na criação das páginas do sistema. A criação dos XML dos módulos e dos operadores é baseada na estrutura XML do sistema Adesso (SILVA, 2003). O fator de ter o XML do Adesso como base, é de ser completo, fácil de compreender e modificar. O Adesso, segundo Silva, é um projeto que explora o modelo de programação em componentes reutilizáveis e configura-se em uma base de dados de algoritmos representados em XML e em conjunto de ferramentas de transformação para a geração de códigos, documentação e empacotamento.

56 56 O XML foi escolhido por trazer flexibilidade, buscas mais eficientes (com bando de dados é necessário saber como é esquematizado e construído), distribuição de dados via rede de forma mais comprimida e escaláveis e por possuir padrões abertos Arquivo de definição dos módulos (XML) O arquivo de definição dos módulos no SPI via Web, baseia-se na estrutura do XML do Adesso (SILVA, 2003). Na Figura 14, tem-se a estrutura original do Adesso. AdToolbox(name, prefix, title, major, minor, vdate) Short Documentation AdIncludeToolbox(name, rel) Bibliography Categories Directories Releases AdStylesheets AdDatatypes AdFunctions Category(name, Title, Short, Descr)* Directory(dir, name, Title, Short, Descr)* Release(name, Title, Short, Descr)* AdCFunction(name, exposed, documented, xref, dir, cat, rel, state, lang)* AdFunction(name, exposed, documented, xref, dir, cat, rel, state, lang)* AdDemo(name, exposed, documented, xref, dir, cat, rel, state, lang)* AdLegacyFiles(Exports*, CSourceFile*, CIncludeFile*, PySourceFile*, OtherFile*, DataFile*) AdLegacyInclude AdLegacySource AdExternalFiles Figura 14 Estrutura XML do módulo do Adesso Fonte: Silva, Na Figura 15, tem-se estrutura modificada para o projeto SPI via Web. Houve alteração nos nomes dos elementos (retirada do prefixo Ad ): AdToobox, AdIncludeToolbox, AdStylesheets, AdDatatypes, AdFunctions, AdFunction, AdLegacyFiles, AdLegacyInclude, AdLegacySource e AdExternalFiles. Esta retirada deu-se pelo fato de Ad serem as iniciais do sistema Adesso. Além disso, foi

57 57 excluído do elemento Functions, o CFunction e o Demo, tendo que para o SPI via Web o Cfunction tem o mesmo valor que o Functions. E o Demo, como trata de lições de algum conceito de PI, não se incluirá por que o sistema trata apenas de funções isoladas. Os elementos com asteriscos (*) indicam que podem ter mais filhos do mesmo tipo na árvore. Na estrutura XML do modulo, referenciada na figura 15, são relacionados elementos, ou mais conhecidos como tags. A seguir são descritas as tags mais importantes do XML do modulo: Toolbox: Responsável pelo início do XML do módulo. Nessa marcação ficam armazenadas informações como o nome, prefixo, entre outras do módulo; Short: Pequena descrição sobre o módulo; Documentacion: Descrição mais detalhada; IncludeToolbox: Necessário caso o módulo precise de outros módulos includos; Categories: Especifica as categorias do módulo; Directories: Especifica os diretórios dos arquivos para o funcionamento do módulo. Datatype: Especifica os tipos de dados utilizados pelo módulo, como imagens, booleanos, etc.; Functions: São relacionadas todas as funções/operadores do módulo. Estas funções são descritas pelo nome, seu diretório, sua categoria entre outros.

58 58 Toolbox(name, prefix, title, major, minor, vdate) Short Documentation IncludeToolbox(name, rel) Bibliography Categories Category(name, Title, Short, Descr)* Directories Directory(dir, name, Title, Short, Descr)* Releases Release(name, Title, Short, Descr)* Stylesheets Datatypes Functions Function(name, exposed, documented, xref, dir, cat, rel, state, lang)* LegacyFiles(Exports*, CSourceFile*, CIncludeFile*, PySourceFile*, OtherFile*, DataFile*) LegacyInclude LegacySource ExternalFiles Figura 15 Estrutura XML do módulo do SPI via Web. Como exemplo da estrutura do XML da Figura 15, tem-se o XML para a descrição do módulo spiweb (módulo teste), ilustrado na Figura 16.

59 59 <?xml version="1.0" encoding="iso "?> <Toolbox name="spiweb" prefix="ia" title="toolbox spiweb" vdate="10dec2002"> <Short>Funções e demosntrações utilizados no curso SPIWeb.</Short> <Documentation> <Descr name="description">descrição técnica do módulo.</descr> </Documentation> <Categories> <Category name="base"> <Title>Todas as Funções do Toolbox</Title> <Short /> <Descr /> </Category> </Categories> <Directories> <Directory name="iademos" dir="iademos"> <Title>Image Processing Course</Title> <Short>Image Processing with MATLAB/Python</Short> <Descr/> </Directory> </Directories> <Releases> <Release name="all"> <Title>Full release</title> <Short/> <Descr/> </Release> </Releases> <Stylesheets/> <Datatypes> <Datatype name="mmimage" exposed="yes" documented="yes" xref="iatypes/iaimage.xml" dir="iatypes" cat="_99datatypes" rel="all"> <Dependencies></Dependencies> <Seealso></Seealso> </Datatype> </Datatypes> <Functions errormsg="mm_lasterrormsg()"> <Function name="iabwlp" exposed="yes" documented="yes" xref="ia636/iabwlp.xml" dir="ia636" cat="imagecreation" rel="all"></function> </Functions> <LegacyFiles> <Exports/> <PySourceFile file="legacy/view"/> <DataFile file="data/blobs.pbm"/> </LegacyFiles> <LegacySource/> <ExternalFiles/> </Toolbox> Figura 16 Exemplo de estrutura XML para a descrição de um módulo no SPI via Web Arquivo de definição dos operadores/funções Como no arquivo de definição dos módulos, o arquivo de definição dos operadores, baseia-se também na estrutura do XML do Adesso. A Figura 17 mostra a estrutura do XML dos operadores do SPI via Web. Assim como no módulo, houve a retirada do prefixo Ad em alguns elementos, por ser as iniciais do Adesso, como o Function (elemento pai). Entretanto a estrutura continua a mesma do Adesso.

60 60 Function (name, state, lang) Seealso Dependencies Module(name) Short Documentation Descr(name, Mcode, PYcode, Eq)* Return (name, type, output, constraint) Args (name, type,dir,constraint,optional,default,hidden) Source (lang, Slide) Slide(title, Descr, Code) Testsuite(Code, ExternalFiles) Platforms ExternalFiles Figura 17 Estrutura do XML do operador do SPI via Web. Como no XML do módulo, são utilizados tags para especificar as propriedades e informações que a função deve possuir. Dentre os elementos destacam-se: Function: Como no módulo, serve para iniciar a descrição da função/operador. A tag Function possui atributos como seu nome, estado e linguagem de programação; Seealso: Especifica na função, se há outras funções semelhantes; Dependencies: Especifica se a função tem dependência com outros módulos; Short: Pequena descrição da funcionalidade da função; Documentation: Descreve informações importantes referentes à função. Pode-se dizer, é a ajuda da função; Return: Especificação do tipo de retorno da função; Args: Especifica os tipos de argumentos utilizados pela função; Source: Mostra o código em Python/Matlab da função; Testsuite: Exibe um código em Python/Matlab de um exemplo utilizando a função;

61 61 Plataforms: Especifica em que plataformas operacionais esta função funciona corretamente; Desta forma na Figura 18, mostra-se um exemplo da estrutura do XML da Figura 17, onde se verifica o XML da descrição dos operadores. Neste exemplo construiu-se a descrição do operador spiapplylut do módulo teste spiweb. <?xml version="1.0" encoding="iso "?> <Function name="spiapplylut" state="alpha" lang="matlab python"> <Seealso>iacolormap</Seealso> <Dependencies> <Module name="numeric"> asarray product ravel NewAxis reshape array transpose </Module> </Dependencies> <Short>Intensity image transform.</short> <Documentation> <Descr name="description"> Apply an intensity image transform to the input image. The input image can be seen as an gray scale image or an index image. </Descr> <Descr name="examples"> <PYcode> f = [[0,1,2], [3,4,5]] it = Numeric.array(range(6)) # identity transform print it g = <Self/>(f, it) print g itn = 5 - it # negation g = <Self/>(f, itn) print g </PYcode> </Descr> </Documentation> <Return name="g" type="mmimage" output="yes" constraint="image"/> <Args> <Arg name="fi" type="mmimage" dir="in" constraint="image" optional="no" default="" hidden="no"> <Descr>input image, gray scale or index image.</descr> </Arg> </Args> <Source lang="python"> <Slide> <Descr></Descr> <Code><![CDATA[...]]></Code> </Slide> </Source> <Testsuite> <Code lang="python"><![cdata[...]]></code> <ExternalFiles></ExternalFiles> </Testsuite> <Platforms>windows linux sunos</platforms> <ExternalFiles/> </Function> Figura 18 - Exemplo de estrutura XML para a descrição de um operador no SPI via Web Protótipo de telas Nesta seção, serão apresentadas algumas páginas do aplicativo em desenvolvimento, ou seja, uma prévia de como será sua interface. Porém poderão

62 62 ocorrer mudanças no decorrer da implementação, como alteração/inserção de requisitos, conseqüentemente, alterações no visual e nos campos. O layout das páginas tem como base um layout pronto adquirido gratuitamente em um site especializado em desenvolvimento em templates de sites, Free Layouts 1. Porém houve modificações de acordo com o esboço da interface, visto na Figura 19, seguindo as prioridades de requisitos. Figura 19 Esboço da interface do SPI via Web. As áreas do esboço da interface são: (1) representa as informações mais importantes, com prioridade alta e média; (2) área de login e menus; (3) área dos históricos, informações com prioridade baixa; (4); área do banner do aplicativo; (5) área do rodapé. 1

63 Página inicial Na página inicial, tem-se a área de login, localizado na área 2 do esboço, apresentado na Figura 19. Logo abaixo, na mesma área, há uma subárea com um menu, contendo os seguintes itens: Home, Documentação e Cadastro. Na área 1, existirá uma pequena introdução sobre o que é o aplicativo. E por último na área 3, possui um campo de busca. Na área 4, está inserido um banner ou imagem com a logomarca do sistema e na área 5, o rodapé. Estas duas últimas seguem para as demais páginas. Figura 20 Página Inicial do Aplicativo Página de Cadastro de Usuários Nesta página, é realizado o cadastro de novos usuários no aplicativo. Desta forma somente poderá utilizar o sistema quem estiver cadastrado, visualizada na Figura 21.

64 64 Considerando o esboço da Figura 19, na área 1, localiza-se o cadastro. Na área 2, o menu de interação e na área 3, sistema de busca. Figura 21 Página de Cadastro de Usuário do Aplicativo Página de Upload de Arquivos Nesta página, apresentada pela Figura 22, é realizada a inserção de novos arquivos no sistema, bem como a visualização de todos os arquivos. Se o usuário deseja inserir um novo arquivo, basta buscar no computador local.

65 65 Na área 1, localiza-se o upload e o sistema de visualização. Na área 2, o menu de interação e na área 3, o histórico do usuário (funções/operadores, arrays, imagens) e sistema de busca. Figura 22 Página de Upload de Arquivos do Aplicativo Página de Operadores Na Figura 23, visualiza-se a página de execução de operadores. A partir desta é gerada a página especifica do operador escolhido, de acordo com seu XML. Na área 1, estão as informações referentes aos operadores. As demais áreas continuam as mesmas da página de upload de arquivos. Para o usuário que deseja realizar alguma operação, escolhe-se inicialmente um módulo. Desta forma, o usuário visualiza somente as funções aos quais gostaria de usar. A seguir escolhe a função, nesse momento através do XML são geradas,

66 66 na página, as informações necessárias para a execução da função/operador (Figura 24). Figura 23 Página de Operadores. Figura 24 - Entradas de dados do operador

67 Página de Inserção de um Novo Operador Na Figura 25, tem-se a página de inserção de novo operadora através de código XML. Nesta página, o usuário pode criar um novo operador, seguindo apenas o XML pré-carregado, inserindo nos locais específicos as informações necessárias para a criação da função. Seguindo o layout sugerido, na área 1, localiza-se a criação de um novo operador. As demais áreas são as mesmas do upload de arquivos e operadores. Figura 25 Página de Inserção de Novos Operadores.

68 68 4 SPI WEB DESENVOLVIMENTO Este capítulo abrange o desenvolvimento em si do Sistema de PI via Web. Seguem as etapas da Engenharia de Software, descritas anteriormente, incluindo a implementação, testes e resultados. 4.1 IMPLEMENTAÇÃO Na fase de implementação inicia-se a construção do sistema, ou seja, são produzidos os códigos necessários ao projeto. A implementação mesmo com um projeto muito bem elaborado, não é uma questão fácil. Pois, muitas vezes os projetistas não conhecem em detalhes a plataforma de implementação, desta forma não são capazes de chegar a um projeto algorítmico passível de implementação direta. Devem ser levadas em conta questão quanto à legibilidade, alterabilidade e reutilização (PFLEEGER, 2004). De acordo com Pflleger, haver correspondência entre os componentes do projeto e o código é fundamental. Sendo que o projeto é o guia para a implementação, o programador possui certa flexibilidade para desenvolvê-lo como código.

69 Django Para a implementação do projeto, foi utilizado o framework Django. Porém, primeiramente é necessário saber o que é framework. Framework, segundo a Django, é uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. É ele quem dita o fluxo de controle da aplicação. Django é um framework, escrito em Python, para desenvolvimentos rápidos para web. Utiliza o padrão MVC (model-view-controller). Foi criado a princípio como um sistema para gerenciar um site jornalístico. Mas tornou-se um projeto de código aberto e publicado sob licença BSD em Seu nome foi inspirado no músico de jazz Django Reinhardt. Além disso, utiliza-se do principio DRY (Don t Repeat Yourself), onde o desenvolvedor aproveita ao máximo o código já feito, evitando repetição (DJANGO, 2010). O MCV, segundo Reenskaug, é um padrão de arquitetura de software que visa separar a lógica de negócio da lógica de apresentação, permitindo o desenvolvimento, teste e manutenção isolados de ambos. Na Figura 26, pode-se visualizar o funcionamento do MCV. Figura 26 - Funcionamento do MVC Fonte: Reenskaug, 2010