14
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ COORDENAÇÃO DE INFORMÁTICA
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
PEDRO HENRIQUE DE ALENCAR MACHADO
SOFTWARE DE SIMULAÇÃO 3D
MÓDULO GERENCIADOR DE CONTEÚDO
TRABALHO DE DIPLOMAÇÃO
CORNÉLIO PROCÓPIO 2013
14
PEDRO HENRIQUE DE ALENCAR MACHADO
SOFTWARE DE SIMULAÇÃO 3D
MÓDULO GERENCIADOR DE CONTEÚDO
Trabalho de conclusão de curso de graduação, apresentado à disciplina Trabalho de Diplomação, do curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas da Coordenação de Informática – COINF – da Universidade Tecnológica Federal do Paraná – UTFPR, como requisito parcial para a obtenção do título de Tecnólogo. Orientador: Prof. Gabriel Canhadas Genvigir
CORNÉLIO PROCÓPIO 2013
14 Ao meu pai Miguel Angelo Machado (in memoriam).
14
AGRADECIMENTOS
Aos meus pais, pela educação, pelo amor incondicional, pelo apoio e pela confiança, sem as quais jamais daria início a essa idealidade. Por conta de vocês aprendi a “caminhar com minhas próprias pernas”.
A toda minha família pelo grande estímulo que recebi durante esse longo período, em especial a minha avó Edith, cuja se tornou minha mãe e meu pai enquanto não os tinha presente. Por conta de vocês aprendi o significado da palavra “incondicional”.
A todos meus amigos distantes, em especial meu irmão José (Obina), pelos momentos de descontração, desordem, cilada e confidencia. Por conta de vocês aprendi o que é amizade.
Ao meu professor orientador Gabriel Canhadas Genvigir, pela disposição em ajudar, mesmo em períodos de greve. Pelo conhecimento transmitido e confiança depositada em mim. Por sua conta aprendi a importância de um “Mestre”.
À empresa S4W – Agencia de Marketing Digital, em especial a Mario Franco de Almeida por todos os conhecimentos transmitidos e oportunidade de fazer parte do magnífico time S4W. Por conta de vocês aprendi o que é coletividade.
Aos amigos que realizei durante a faculdade, Vinicius Coimbra, Jéssica e Pablo pelos momentos incomparáveis de risadas e pela amizade. Por conta de vocês aprendi o caminho do “Zero Grau”.
Aos meus amigos “republicanos”, Vinicius Diniz, Leonardo, Vinicius Bacon e todos os que vieram posteriormente, pelos momentos de companheirismo. Por conta de vocês aprendi o quanto tudo isso é fundamental.
A minha amiga e meu amor Juliéli, pelos momentos de refúgio, conversas e silêncios. Por sua conta aprendi a amar.
À Deus, por ter me permitido a vida, e pessoas tão especiais. Por sua conta, estou aqui.
15
“Não sabendo que era impossível, ele foi lá e fez”.
16
RESUMO
MACHADO, Pedro Henrique de Alencar. Software de Simulação 3D – Módulo
Gerenciador de Conteúdo. Trabalho de Diplomação (Tecnologia em Análise e
Desenvolvimento de Sistemas), Universidade Tecnológica Federal do Paraná. Cornélio Procópio, 2012.
Este trabalho apresenta o desenvolvimento do módulo Gerenciador de Conteúdo do projeto Sofware de Simulação 3D (S3D). A metodologia de desenvolvimento utilizada é a customização do processo Web Agile Process (WAP), baseado em metodologias como Rational Unified Process (RUP), Microsoft Solutions Framework
for Agile Software Development (MSF for Agile) e Web Engineering (WebE). Foi
utilizada a UML para a modelagem, linguagem de programação C#, banco de dados SQL Server 2008 e o paradigma de orientação a objetos.
17
ABSTRACT
This paper presents the development of Content Manager Module to the project scope Sofware Simulation 3D (S3D). It uses as a development methodology customization process Agile Web Process (WAP), which in turn is based on methodologies such as Rational Unified Process (RUP), Microsoft Solutions Framework for Agile Software Development (MSF for Agile) and Web Engineering (WebE) using UML for modeling, programming language C #, database SQL Server 2008 and the paradigm object orientation.
18
LISTA DE FIGURAS
Figura 1 - Integração dos módulos ... 28
Figura 2 - Trecho de código em C# ... 29
Figura 3 - Trecho de código em C# - Enum ... 30
Figura 4 - Trecho de código Code Behind - UsuárioDados.aspx ... 31
Figura 5 - Controle Ajax PasswordStrength - Exemplo de senha ideal ... 32
Figura 6 - Controle Ajax Calendar - Exemplo de data de nascimento ... 32
Figura 7 - Sintaxe Stored Procedure ... 38
Figura 8 - Fases e marcos do WAP Fonte: retirado da monografia sobre Customização de processo para aplicações Web (ALMEIDA NETO, 2008). ... 39
Figura 9 - Diagrama de Caso de Uso Geral do GDC ... 41
Figura 10 - Diagrama de Pacotes - Arquitetura do Software ... 41
Figura 11 - Protótipo da GUI ... 42
Figura 12 - Diagrama de Classe GDC ... 45
Figura 13 - Modelo Físico Base de Dados GDC ... 47
Figura 14 - Comparação dos Cronogramas ... 49
Figura 15 - Diagrama Navegacional – GDC ... 51
Figura 16 - Diagrama Navegacional - Gerenciar Usuário ... 52
Figura 17 - Diagrama de Sequencia - Inserir Usuário ... 53
Figura 18 - Diagrama Navegacional - Gerenciar Log ... 54
Figura 19 - Stored Procedure – GerPermissaoPorUsuario ... 55
Figura 20 - WUI - Gerenciar Usuário ... 56
Figura 21 - Diagrama Navegacional - Gerenciar Produto ... 58
Figura 22 - Diagrama Navegacional - Gerenciar Simulação ... 59
Figura 23 - Diagrama de Sequencia - Inserir Produto ... 60
Figura 24 - Stored Procedure - AtualizaPathObj3DProduto ... 61
Figura 25 - Método - UploadImagem ... 62
19
LISTA DE QUADROS
Quadro 1 - Estereótipos WAE ... 34
Quadro 2 - Ícones estereótipos WAE ... 36
Quadro 3 - Cronograma Oficial ... 66
20
LISTA DE SIGLA E ABREVIATURAS
AJAX Asynchronous Javascript and XML
ASP.NET Active Server Pages
C# C Sharp
CASE Computer Aided Software Engineering
CMMI Modelo Integrado de Capacitação e Maturidade (do original Capability Maturity Model Integration)
CMS Content Management System
CSS Cascading Style Sheets
DLL Dynamic-link library
GDC Gerenciador de Conteúdo
GUI Interface Gráfica de Usuário (do original Graphical User
Interface)
HTML Linguagem de Marcação de Hipertexto (do original
HyperText Markup Language)
IBM International Business Machines
IDE Ambiente de Desenvolvimento Integrado (do original
Integrated Development Environment)
IIS Serviço de Informação da Internet (do original Internet
Information Service)
MSF Microsoft Solutions Framework
PHP Personal Home Page
RUP Processo Unificado da Rational (do original Rational
Unifired Proces)
S3D Simulador 3D
SEO Mecanismo de otimização de busca (do original Search
Engine Optimization)
SGBD Sistema Gerenciador de Banco de Dados
SQL Structured Query Language
UML Linguagem de Modelagem Unificada (do original Unified
Modeling Language)
21 VB SCRIPT Visual Basic Script
W3C World Wide Web Consortium
WAE Extensão para aplicativo Web (do original Web Application
Extension)
WAP Processo Ágil para Web (do original Web Agile Process) WebE Engenharia para Web (do original Web Engineering) WUI Interface para Web (do original Web Interface)
XHTML Linguagem de Marcação de Hipertexto Extensível (do original eXtensible Hypertext Markup Language) XML Linguagem de Marcação Extensível (do original
22 SUMÁRIO 1. INTRODUÇÃO ... 23 1.1 APRESENTAÇÃO ... 23 1.2 OBJETIVOS ... 24 1.3 JUSTIFICATIVA ... 25 1.4 ORGANIZAÇÃO DO TRABALHO ... 26 2. SIMULADOR 3D (S3D) ... 26
2.1 MÓDULO AMBIENTE DE SIMULAÇÃO ... 27
2.2 MÓDULO GERENCIADOR DE CONTEÚDO ... 27
2.3 INTEGRAÇÃO DOS MÓDULOS... 27
3. REVISÃO BIBLIOGRÁFICA ... 28
3.1 C SHARP (C#) ... 29
3.2 ACTIVE SERVER PAGES.NET (ASP.NET) ... 30
3.3 TABLELESS ... 31
3.4 ASYNCHRONOUS JAVASCRIPT AND XML (AJAX) ... 32
3.5 MICROSOFT VISUAL STUDIO 2010 ... 33
3.6 IBM RATIONAL ROSE ... 33
3.7 UNIFIED MODELING LANGUAGE (UML) ... 34
3.8 MICROSOFT SQL SERVER 2008 ... 36
3.9 STORED PROCEDURE (PROCEDIMENTO ARMAZENADO) ... 37
4. METODOLOGIA DE DESENVOLVIMENTO ... 38 4.1 METODOLOGIA ... 38 4.2 DESENVOLVIMENTO ... 40 4.3 RESULTADOS ATINGIDOS ... 68 4.4 DIFICULDADES ENCONTRADAS ... 68 5. CONCLUSÃO ... 69 4.1 CONSIDERAÇÕES FINAIS ... 69 4.2 PERSPECTIVAS FUTURAS ... 69 6. REFERÊNCIAS ... 71
23
1. INTRODUÇÃO
É evidente que a evolução da internet e dos recursos computacionais caminham de forma paralela e com intensidades semelhantes. Essa evolução cria um perfil diferente de usuário, aqueles cada vez mais exigentes em relação aos requisitos das aplicações. (NIELSEN, 2008).
É com vista nestas exigências que foi desenvolvido o Simulador 3D (S3D). O S3D é uma aplicação web que permite ao usuário interagir com diferentes objetos de um imóvel dentro de um cômodo em três dimensões. A complexidade do desenvolvimento do S3D criou a necessidade da divisão do software em dois módulos diferentes: Módulo Ambiente de Simulação e Módulo Gerenciador de Conteúdo, este ultimo é o objeto detalhado deste trabalho.
1.1 APRESENTAÇÃO
O Software de Simulação 3D – Módulo Gerenciador de Conteúdo apresenta o Trabalho de Conclusão de Curso à Coordenação de Informática da Universidade Tecnológica Federal do Paraná (UTFPR) – Campus Cornélio Procópio.
O trabalho desenvolvido refere-se à análise e desenvolvimento de um gestor de conteúdo online, visando é a de administrar a alteração das informações apresentada aos usuários na aplicação S3D – Módulo Ambiente de Simulação.
Este tipo de software, conhecido como CMS (Content Management System) fornece um conteúdo dinâmico para as páginas e/ou aplicações web onde o usuário realiza a interação. De acordo com Conallen (2003), o gerenciamento do conteúdo de uma aplicação web é de responsabilidade da aplicação gestora e o tipo de conteúdo a ser dinâmico depende do sistema a ser utilizado.
Como metodologia de desenvolvimento foi utilizada uma customização do modelo de processo WAP (Web Agile Process). A linguagem de programação o C
Sharp (C#). O desenvolvimento das páginas web dinâmicas foi desenvolvido na
24 1.2 OBJETIVOS
Este trabalho teve como objetivo a elaboração de uma ferramenta web para gerir as informações e os objetos do S3D, o Gerenciador de Conteúdo (GDC).
A principal funcionalidade da ferramenta é a gestão dos modelos manipulados no escopo Ambiente de Simulação do S3D. Outros objetivos são de responsabilidade do software:
Gerenciar usuários e permissões: Os usuários são todos os stakeholders que detenham uma ou mais funcionalidade no GDC. As
funcionalidades são: Gerenciar usuários, gerenciar logs, gerenciar produtos, visualizar simulações e visualizar clientes. Os usuários com permissão de “Gerenciar Usuários” poderão cadastrar novos com suas respectivas concessões de acesso.
Visualizar logs: Logs, dentro deste escopo, são informações geradas
pela aplicação de forma automática permitindo ao usuário realizar uma auditoria das ações praticadas no GDC.
Efetuar login e logout: Os usuários que foram cadastrados no GDC,
com suas respectivas premissas (nome de usuário e senha) podem acessar a ferramenta, efetuando login. As permissões indicam quais opções pode ser exibidas. Um usuário logado pode encerrar o uso do sistema, efetuando logout, terminando todas as sessões abertas.
Visualizar simulações: Simulações realizadas dentro do ambiente de
simulação geram informações que podem ser visualizadas por intermédio do GDC. Um usuário que detenha da permissão “Visualizar Simulações” pode ter acesso a todos os elementos que foram previamente gravados.
Visualizar clientes: Os clientes, dentro deste escopo, são stakeholders que por intermédio do ambiente de simulação realizaram um breve
cadastro, para posterior uma simulação. Sendo assim, uma simulação, obrigatoriamente está vinculada a um cliente cadastrado.
O GDC foi divido em dois módulos, descritos a seguir:
Módulo Core: Contém as funcionalidades administrativas básicas para
a utilização do GDC. Como
o Gerenciar usuários e permissões; o Visualizar logs;
25 o Controlar login e logout.
Módulo Content: Administrar as informações dos produtos dispostos
no Módulo Ambiente de Simulação e gerencia o upload de arquivos pré – modelados1, em três dimensões. Deste modo, é possível um feedback sobre a utilização do S3D, permitido ao usuário interpretar informações sobre simulações.
1.3 JUSTIFICATIVA
“Na década de 90, com o desenvolvimento dos primeiros Sistemas de Gestão de Conteúdo (CMS), a liberação do polo emissor é materializada, tendo em vista que as interfaces de gerenciamento de conteúdo melhoram a usabilidade e experiência do usuário, e consequentemente, novas vozes ganharam visibilidade e ampliação na rede”. (ALMEIDA, 2010).
O CMS oferece aplicação mais interativa com alta taxa de atualização do conteúdo, ou seja, mais conteúdos são produzidos em um intervalo menor de tempo. A optimização de sites para mecanismos de pesquisa, “Por meio da criação conteúdo útil, exclusivo e atualizado irá provavelmente exercer maior influência no seu site do que qualquer um dos outros fatores já discutidos neste documento.” (Google, 2012).
A aplicação S3D é voltada para o mercado alvo dos segmentos moveleiro e decorações, cujas formas e estilos sejam padronizados e de marcas conhecidas. A construção de um sistema CMS vinculado ao S3D proporciona uma maior liberdade para o usuário da aplicação simuladora e a atualização do conteúdo exibido fica a critério do usuário.
Outra vantagem a ser explorada com a implementação do GDC, refere-se às informações geradas durante uma determinada simulação. À medida que os usuários realizem as ações dentro do ambiente de simulação, os dados tornam-se informações, que podem ser acessadas, por meio do gestor de conteúdo.
1
A modelagem dos objetos não é de responsabilidade do GDC, é realizada em uma ferramenta de modelagem tridimensional, atualmente as mais utilizadas são: SketchUP, 3ds Max, Blender, Maya entre outras.
26 1.4 ORGANIZAÇÃO DO TRABALHO
Este trabalho é composto de 6 capítulos, 1 anexo e 5 apêndices, organizados da seguinte forma: o primeiro capítulo traz uma breve introdução do trabalho desenvolvido, a justificativa que motivou o desenvolvimento do GDC, os objetivos alcançados e a organização do trabalho esta organizado. O capítulo 2 apresenta uma descrição da ferramenta S3D, os módulos que foram desenvolvidos e a forma que interagem entre si. O capítulo 3 aborda a revisão bibliográfica que descreve as tecnologias e ferramentas utilizadas para o desenvolvimento do Gerenciador de Conteúdo. O capítulo 4 mostra a metodologia utilizada para o desenvolvimento deste trabalho, a descrição das fases e disciplinas realizadas, detalhando o desenvolvimento dos módulos construídos. O capítulo 5 apresenta as considerações finais e perspectivas futuras.
Nos apêndices podem ser encontrados os documentos de maior relevância gerados durante o desenvolvimento do trabalho, sendo eles: no Apêndice A está o Documento de Requisitos de Software; no Apêndice B está o Plano de Projeto; no apêndice C encontram-se os Planos de Iterações de todas as fases do modelo de processo; no apêndice D o Plano de Teste e Qualidade; no apêndice E os cenários de teste; no apêndice F estão as especificações dos casos de uso; no apêndice G está o documento de customização da Metodologia de Processo; no Apêndice H está o documento de Proposta de Trabalho de Conclusão de Curso.
2. SIMULADOR 3D (S3D)
O software de simulação 3D (S3D) é uma aplicação web voltada para o mercado alvo dos segmentos moveleiro e decorações, onde formas e estilos são padronizados. O S3D permite aos seus usuários simular espaços de um imóvel. A partir de um ambiente gerado em três dimensões, o usuário é capaz de simular a decoração de um cômodo, incluindo e/ou excluindo objetos pré-modelados em 3D. Visando a organização no desenvolvimento da ferramenta, o S3D foi dividido em dois diferentes módulos: Ambiente de Simulação e Gerenciador de Conteúdo.
27 2.1 MÓDULO AMBIENTE DE SIMULAÇÃO
O desenvolvimento do módulo ambiente de simulação foi a parte. Contudo, uma melhor interpretação da aplicação S3D é valida uma descrição do seu funcionamento.
O ambiente de simulação pode ser entendido como a parte pública do S3D, ou seja, neste módulo os internautas, usuários da aplicação, realizaram uma maior interação, permitindo a simulação da decoração do cômodo e a disposição dos objetos.
2.2 MÓDULO GERENCIADOR DE CONTEÚDO
O módulo GDC é o artefato deste trabalho, fornece ao módulo ambiente de simulação os modelos em 3D, utilizados como objetos dentro de um cômodo a ser simulado.
Serve como ferramenta de análise dos dados coletados durante uma simulação. O usuário pode obter uma série de informações armazenadas anteriormente, como por exemplo: Dados pessoais do usuário que realizou a simulação, objetos que foram utilizados durante a ação, tempo que o internauta permaneceu na aplicação simuladora, entre outras.
2.3 INTEGRAÇÃO DOS MÓDULOS
A comunicação dos dois módulos é fundamental nas ações de “persistir” e “consumir”, ou seja, o que um módulo persiste, o outro consome, e vice-versa. A persistência dos dados nos módulos é realizada em uma mesma base de dados.
Os elementos gerados pelo Ambiente de Simulação são salvos em uma base de dados e podem ser acessados pelo módulo Gerenciador de Conteúdo. Por sua vez, os dados gerados pelo GDC são gravados no mesmo banco de dados e podem ser acessados pelo Ambiente de Simulação. A Figura 1 apresenta a integração entre os módulos:
28 Figura 1 - Integração dos módulos
3. REVISÃO BIBLIOGRÁFICA
A ferramenta GDC não é a única aplicação do tipo CMS (Content
Management System) utilizada atualmente no mercado, porém o seu alto nível de
especificidade demarcou a necessidade do seu desenvolvimento. Os níveis de particularidade do Gerenciador de Conteúdo em questão são descrito a seguir:
Consumir dados de uma segunda aplicação, o módulo Ambiente de Simulação;
Prover dados para uma aplicação que utiliza uma tecnologia Unity3D;
Gerar arquivos de logs das ações efetuadas dentro do próprio módulo de gestão de conteúdo.
Construir novas funcionalidades sem a dependência de terceiros;
Ter controle sobre a codificação;
Evitar estudar outra linguagem de programação utilizada em diferentes aplicações CMS, como por exemplo, a linguagem Personal Home Page (PHP), utilizada no software Joomla2.
2
29 A revisão bibliográfica das principais tecnologias, ferramentas e técnicas utilizadas no desenvolvimento do módulo Gerenciador de Conteúdo são apresentadas:
3.1 C SHARP (C#)
C Sharp (C#) é uma linguagem de programação visual dirigida a eventos e
totalmente orientada a objetos. (DEITEL, 2005).
A utilização da linguagem de programação C# é muito simples, os recursos e a sintaxe da linguagem são muito similares à linguagens C++ e Java e de conhecimento do desenvolvedor. Utiliza parâmetros para delimitar as estruturas de blocos lógicos facilitando a endentação do código e o entendimento dos grupos de código. A Figura 2 ilustra um trecho de código desenvolvido destacando a endentação.
Figura 2 - Trecho de código em C#
Outra vantagem da linguagem de programação C# são as enumerações, ou
Enum. No C Sharp as enumerações são fortemente tipadas tornando-se assim
incompatíveis com outras enumerações. A Figura 3 ilustra um trecho de código onde é utilizado o tipo de dado enum.
O enum fornece uma maneira eficiente para definir um conjunto de constantes nomeadas de integrais que pode ser atribuído a uma variável.
30 Figura 3 - Trecho de código em C# - Enum
3.2 ACTIVE SERVER PAGES.NET (ASP.NET)
Microsoft ASP.NET é uma plataforma de desenvolvimento gratuita que permite ao desenvolvedores a criação de aplicações web dinâmicas. (SIMÕES, 2010).
A utilização do ASP.NET como plataforma de desenvolvimento, foi considerada para criação de paginas web dinâmicas.
A Master Page é um recurso que permite desenvolver uma página padrão, as demais herdam suas características. Qualquer alteração efetuada na Master
Page é compilada em tempo de execução, assim qualquer mudança é
automaticamente aplicada nas demais páginas. (HADDAD, 2012).
Outro recurso utilizado é o Code Behind. A solução refere-se ao código para a página em ASP.NET que está no arquivo de classe a parte, permitindo uma separação do código HTML da sua lógica de apresentação. (MICROSOFT, 2012). A Figura 4 ilustra uma página Code Behind referente a item ASP.NET UsuarioDados.aspx.
31 Figura 4 - Trecho de código Code Behind - UsuárioDados.aspx
3.3 TABLELESS
O termo tableless (sem tabela) é um padrão de desenvolvimento para sites
web, ou webstandards. Padrões de desenvolvimento são criados por pessoas e/ou
empresas que se vinculam ao W3C (World Wide Web Consortium3), regulamentando
as normas técnicas para a web (GOMES. 2010).
O tableless, usam-se, obrigatoriamente algumas regras de semântica, como por exemplo: A tag “<table>” em HTML, para exibir apenas dados tabulados e a tag “<p>” refere-se à criação de parágrafos de textos, entre outras.
Uma aplicação web que utiliza tableless como padrão de desenvolvimento, implica em dizer que sua diagramação não será feita usando tabelas, utilizando propriedades de Cascading Style Sheets (CSS) 4.
Para diagramação do layout do GDC foi utilizado o padrão de desenvolvimento, descrito acima, garantindo que mudanças no arquivo de CSS da aplicação equivalem a alterações no desenho do site.
3
http://www.w3c.br
4 “CSS é um padrão para a declaração de propriedades de exibição de elementos HTML”. (AMARAL, 2001).
32 3.4 ASYNCHRONOUS JAVASCRIPT AND XML (AJAX)
Ajax é uma técnica de desenvolvimento web que combina tecnologias conhecidas como Javascript, XML, entre outras, tornando páginas mais dinâmicas e interativas. (NIEDERAUER. 2007).
Os controles Calendar e PasswordStrength foram utilizados na aplicação GDC, visando uma maior interatividade na utilização da ferramenta.
O Calendar exibe um calendário para o usuário, facilitando e tornando mais agradável a escolha de uma data desejada.
O PasswordStrength verifica o a senha em questão, e exibe ao usuário um indicador. Uma senha ideal, neste escopo, deverá conter dígitos do tipo letras, números e caracteres especiais, além de ter mais que seis algarismos. A segurança da senha é representada por indicadores das cores Vermelha (senha fraca), Azul (senha relevante) e Verde (senha ideal). A Figura 5 ilustra um exemplo de utilização do componente PasswordStrength.
Figura 5 - Controle Ajax PasswordStrength - Exemplo de senha ideal
A Figura 6 ilustra o emprego do controle Ajax Calendar.
33 3.5 MICROSOFT VISUAL STUDIO 2010
O Visual Studio é uma suíte de desenvolvimento de software criada pela empresa Microsoft que oferece suporte a uma diversidade de linguagens de programação, como por exemplo: C Sharp (C#), VB (Visual Basic) Script, C++ entre outras. A versão 2010 possui um modelador UML5 integrado, permitindo a realização de um ciclo de vida completo, dentro do ambiente de desenvolvimento, desde a análise até os testes (SIMÕES, 2010).
A ferramenta apresenta as funcionalidades de “engenharia versa” e “engenharia reversa” que permitem a geração de códigos de programação, a partir de um modelo e/ou vice-versa. Nesta versão estão presentes os diagramas UML: Diagrama de caso de uso, diagrama de componentes, diagrama de classe, diagrama de sequencia, diagrama de atividades e diagrama de camadas. (SYCH, 2010).
Para analise e o desenvolvimento da aplicação GDC esse ambiente é ideal. Os diagramas não presentes na aplicação foram desenvolvidos utilizando outra ferramenta, o IBM Rational Rose.
3.6 IBM RATIONAL ROSE
O Rational Rose é uma aplicação desenvolvida pela empresa IBM (International Business Machines) de modelagem visual de software que permite a criação, análise, projeto (design), visualização, modificação e manipulação dos componentes (CORDEIRO, 2002).
Para a criação de alguns modelos UML não suportados pela aplicação
Visual Studio 2010, como o diagrama navegacional foi utilizado a ferramenta CASE
(Computer Aided Software Engineering)6 Rational Rose versão Enterprise 7.0.
Para representar as páginas web desenvolvidas para o GDC e a comunicação entre elas, foi incorporado ao Rational Rose um pacote de extensão da UML, que permite a utilização das estruturas da WAE (Web Application Extension). A WAE é um mecanismo de extensão da UML que define estereótipos que podem ser aplicados na arquitetura web, como a representação dos cenários do GDC que
5
Unified Modeling Language (UML) é uma linguagem visual utilizada para a modelagem de sistemas computacionais utilizando o paradigma de orientação a objetos. (GUEDES. 2005).
6
Engenharia de software assistida por computador. Aplicações CASE são capazes de construir um sistema mediante o uso de ferramentas de software automatizadas. (POLLONI, 2009).
34 utilizam o mesmo padrão dos diagramas, já utilizados na modelagem do sistema. (CONNALEN, 2003). Os principais estereótipos são mostrados no Quadro 1 – Estereótipos WAE.
Estereótipo Descrição
<<link>> Faz a ligação entre a página do cliente e outra pagina web. Parâmetros para outra página podem também ser passados.
<<build>> Faz a ligação entre a página do cliente e a página do servidor, sendo que a página do cliente é gerada dinamicamente e em tempo de execução. <<submit>> Envia valores de um formulário HTML para uma página do servidor.
<<redirect>> Faz o direcional entre duas páginas, incide de uma solicitação para outro recurso.
Quadro 1 - Estereótipos WAE
3.7 UNIFIED MODELING LANGUAGE (UML)
A UML ou linguagem de modelagem unificada é uma linguagem visual utilizada para a modelagem de sistemas computacionais utilizando o paradigma de orientação a objetos (GUEDES, 2005).
Possui uma linguagem gráfica utilizada para a visualização, especificação estrutural e comportamental do sistema, proporcionando uma orientação para a construção da aplicação em questão. Os modelos desenvolvidos durante a fase de análise e desenvolvimento são objetos de orientação para o construtor e toda a equipe de desenvolvimento.
A UML visa orientar o desenvolvimento, documentar as funcionalidades e auxiliar na tomada de decisão durante o desenvolvimento do GDC.
3.7.1 DIAGRAMAS UML
Os diagramas da UML podem representar graficamente determinadas estruturas do sistema em questão. Os modelos gerados podem ser divididos em duas classes: modelos estruturais representando visão estática do sistema, ou seja, abrange uma visão predominantemente dos dados e da estrutura da aplicação e os modelos comportamentais representando visão dinâmica do sistema, ou seja, uma visão predominantemente das funcionalidades e suas especificações (JACOBSON, 2006).
35 3.7.1.1 DIAGRAMA DE CASO DE USO
Os diagramas de casos de uso são diagramas do tipo comportamental e especificam o comportamento de um determinado sistema. Em alguns casos define o conjunto de ações realizadas pelo sistema produzindo um resultado para determinado ator7. Apresenta uma visão externa geral das funcionalidades e serviços oferecidos aos usuários, sem preocupar-se com a maneira que elas serão implementadas.
Para o desenvolvedor de sistema, o diagrama de caso de uso oferece uma maneira de chegar a uma compreensão comum com os usuários finais e outros
stakeholders envolvidos na aplicação.
3.7.1.2 DIAGRAMA DE CLASSE
O diagrama do tipo estrutural que especifica as Classes, abstrações e suas responsabilidades, dentro do escopo do projeto. Define as estruturas, exibindo a colaboração entre classes e mostra a estruturação conceitual do banco de dados (modelo lógico).
Para o usuário final da aplicação, este diagrama oferece suporte aos requisitos funcionais do software em questão.
3.7.1.3 DIAGRAMA DE SEQUENCIA
O diagrama do tipo comportamental que especifica determinado trecho de interação, formada por um conjunto de objetos e seus relacionamentos, incluindo as mensagens que poderão ser enviadas entre eles. Exibindo a ordem temporal de determinada ação no sistema, ou seja, a ordem que os eventos ocorrem.
Para o desenvolvedor, o diagrama de sequencia oferece informações detalhadas de como determinada funcionalidade do sistema é executada. Possibilita o entendimento do curso da aplicação ao ser efetuada determinada interação. É utilizado principalmente para especificar o fluxo básico de algum caso de uso, e suas variações.
7
O ator pode ser entendido como um conjunto de papéis que os usuários desempenham ao interagir com determinado caso de uso.
36 3.7.1.4 DIAGRAMA NAVEGACIONAL
A utilização do modelo navegacional emprega a extensão da UML para a arquitetura web, a WAE, descrita no item 3.6.
O diagrama navegacional descreve a navegação da aplicação, ou seja, como o usuário tem acesso as funcionalidades do sistema. Representar a navegabilidade de um sistema baseado na web é a principal razão da utilização desse modelo. O modelo navegacional possibilita estruturar, os incrementos navegacionais, auxiliando a documentação do sistema.
Para o desenvolvedor, este diagrama oferece informações de comunicação realizada entre as páginas que compõe a aplicação, evidenciando a navegabilidade da aplicação web.
O Quadro 2, Ícones estereótipos WAE, apresenta os principais estereótipos na forma de ícone da WAE utilizados nos diagramas navegacionais (CONNALEN, 2003).
Server Page
(Página do servidor)
Representa uma página web dinâmica que contém o conteúdo do servidor sempre que solicitado. Pode realizar a interação com o a base de dados, regra de negócio, sistemas externos entre outros.
Client Page
(Página do cliente)
São páginas web formatadas com alguma linguagem de marcação e apresentadas pelos navegadores de clientes.
Form Page
(Página do formulário)
Coleção de campos de entrada que fazem parte de uma página cliente.
Quadro 2 - Ícones estereótipos WAE
3.8 MICROSOFT SQL SERVER 2008
O Microsoft SQL (Structured Query Language) Server 2008 é um Sistema Gerenciador de Banco de Dados (SGBD) que permite a organização a gerência de quaisquer dados e em lugares distintos. A partir do o armazenamento de documentos estruturados, semi estruturados e não estruturados como imagens e
37 mídias. O SQL Server 2008 fornece um conjunto de serviços integrados que permitem consultar, sincronizar, relatar e analisar dados (MICROSOFT, 2011).
Sua utilização também como o Sistema Gerenciador de Banco de Dados, permitindo a fácil integração entre as ferramentas, e o suporte que a empresa oferece e outros diferentes recursos de consulta.
3.9 STORED PROCEDURE (PROCEDIMENTO ARMAZENADO)
O procedimento armazenado é um grupo de comandos SQL (Structured Query Language) armazenados no servidor dentro do banco de dados. Além de um método de encapsulamento de tarefas repetitivas, as stored procedures dão suporte a diferentes variáveis e tipo de dados. Os procedimentos armazenados no SQL
Server são semelhantes aos procedimentos de outras linguagens de programação, e
têm as seguintes vantagens: Podem conter comandos que executam operações no SGBD; chamar outros procedimentos, aceitar parâmetros de entrada de valores e retornar valores de status e diferentes parâmetros de saída (FERNANDES, 2002).
Outra vantagem do uso de stored procedures é a redução de tráfico de rede, considerando que os procedimentos são executados pelo SGBD no servidor de banco de dados, permitindo mover grande parte do código de manipulação de dados para o servidor. Eliminando a transferência de dados do servidor para o cliente pela rede.
A segurança do banco de dados é uma vantagem, uma vez que os procedimentos podem acessar tabelas que o usuário não tem o direito de fazê-la. Por exemplo, suponha que um determinado usuário da aplicação precise obter um relatório que mostre todas as simulações de determinado cliente. Ainda que as informações venham da tabela simulações, não queremos que o usuário tenha acesso irrestrito às simulações efetuadas. A solução é escrever uma stored
procedure que extraia da tabela simulações informações resumidas referente à
simulações de determinado cliente, e provendo ao usuário o direito de executar esse procedimento armazenado. A Figura 7 ilustra a sintaxe utilizada pra a criação de uma stored procedure (FERNANDES, 2002).
38 Figura 7 - Sintaxe Stored Procedure
A partir das vantagens descritas, foi utilizado o grupo de comandos SQL para a comunicação entre a regra de negócio e o SGBD.
4. METODOLOGIA DE DESENVOLVIMENTO
Este capítulo traz uma descrição das atividades e o período em que foi realizado o desenvolvimento da aplicação GDC. A seção 4.1 apresenta a metodologia empregada e a seção 4.2 detalha as atividades.
4.1 METODOLOGIA
O processo deve estabelecer um modelo a ser seguido por toda a equipe de desenvolvimento, auxiliando e estipulando quem deve fazer o quê, quando e como para alcançar o objetivo, que é a entrega da aplicação GDC com qualidade e dentro do prazo estipulado.
Para o desenvolvimento, foi empregado uma customização da metodologia de desenvolvimento Web Agile Process (WAP). De acordo com Almeida Neto (2008) o processo foi baseado em metodologias já utilizadas na indústria de desenvolvimento de softwares, tais como: Rational Unified Process (IBM, 2006),
Microsoft Solution Framework for Agile Software Development (MICROSOFT, 2006)
e Web Engeneering (OLSINA, 1999), além de utilizar os princípios do Capability
Maturity Model Integration (CMMI) nível de maturidade 2 (GRUNDMAN, 2005)
garantindo a qualidade do processo.
O WAP utiliza a estrutura de fases e marcos de processo do RUP, porém não utiliza o seu conceito básico, considerando que é um processo prescritivo, ou seja, todas as atividades declaradas têm por obrigação serem executadas. Entretanto, o WAP é um processo ágil, na qual, não há a necessidade da execução
39 de uma tarefa, se esta não for objeto imperativo para a construção da aplicação. A Figura 8 ilustra quais são as fases e marcos da metodologia de desenvolvimento WAP.
Figura 8 - Fases e marcos do WAP
Fonte: retirado da monografia sobre Customização de processo para aplicações Web (ALMEIDA NETO, 2008).
As fases e as responsabilidades do processo WAP são descritas a seguir:
Iniciação: Definir o escopo, a viabilidade da aplicação e o ambiente
propício para o projeto. O marco principal é o objetivo do ciclo de vida do software;
Elaboração: Definir os requisitos para a continuidade da construção do software, marcando a arquitetura do ciclo de vida;
Construção: Disponibiliza a capacidade operacional da aplicação, de
forma iterativa e incremental.
Transição: Realiza as últimas adaptações à aplicação para implantá-la
no seu ambiente final e definitivo, liberando a aplicação.
Cada fase descrita anteriormente apresenta sete disciplinas necessárias o ciclo de vida completo do projeto, são elas:
Requisitos: Obtém as necessidades da organização responsável por
custear o projeto mantendo a concordância entre toda a equipe de desenvolvimento;
Modelagem: Mapeia o modelo de requisitos em um modelo
arquitetural e um modelo de projeto, auxiliando a equipe a validar e construir uma solução para a aplicação, de acordo com as necessidades levantadas;
Implementação: Planeja a implantação da aplicação, disponibilizando
a solução para os usuários finais e preparando materiais de suporte, caso necessário;
Teste: Testa as funcionalidades desenvolvidas à procura de defeitos,
40
Implantação: Planeja a implantação da aplicação em ambiente final ou
de teste, disponibilizando a solução para usuários finais;
Gerenciamento de Projeto: Planeja, monitora e oferece suporte as
atividades necessárias para o andamento correto do projeto. Inclui o gerenciamento de recursos, de riscos, de custos e de cronograma;
Gerenciamento Operacional: Fornece suporte às atividades
operacionais envolvidas na construção da solução.
4.2 DESENVOLVIMENTO
Na execução das iterações foram gerados os artefatos. A cada iteração todas as disciplinas são executadas.
4.2.1 INICIAÇÃO
A iniciação defini a necessidade da organização, o escopo da aplicação, o plano de testes, as funcionalidades (casos de uso) iniciais e os possíveis atores para um entendimento generalizado do escopo do projeto GDC. Nesta fase, foi desenvolvido o plano de iteração, encontrado no apêndice C.1, e definido o seu prazo de início e término. Início em 08/08/2011 e término em 27/09/2011.
4.2.1.1 REQUISITOS
O levantamento de requisitos foi obtido a partir de reuniões com os envolvidos na aplicação, assim foram definidas as funcionalidades para o GDC. O documento de Requisitos de Software encontrado no Apêndice A, que descreve o programa, identifica os requisitos funcionais e não funcionais; os atores que realizam de alguma tarefa no escopo do GDC.
41 4.2.1.2 MODELAGEM
Após elaboração do modelo de requisitos, é possível esboçar o Diagrama de Caso de Uso representando as funcionalidades obtidas, em conjunto com os atores que interagem com elas. A Figura 9 ilustra o diagrama de caso de uso geral do GDC.
Figura 9 - Diagrama de Caso de Uso Geral do GDC
Foi elaborado e definido a arquitetura de software do sistema, representada por meio do Diagrama de pacotes, ilustrado na Figura 10.
42 As camadas representadas na Figura 10 formam a arquitetura do software:
WUI: Responsável pela representação gráfica do Módulo Gerenciador
de Conteúdo ao usuário.
BO: Responsável pela implementação da Regra de Negócio.
SGBD: Responsável pelo gerenciamento das informações persistidas
na aplicação.
4.2.1.3 IMPLEMENTAÇÃO
O artefato Requisitos de Software permite desenvolver o protótipo de interface para a Graphical User Interface (GUI), Figura 11. Seu principal objetivo é avaliar a disposição dos elementos e funcionalidades na interface, minimizando riscos com navegação.
43 4.2.1.4 TESTES
Na fase foram definidos quais os planos de testes fundamentais para validar a qualidade da aplicação. Assim é possível de averiguar defeitos em qualquer uma das camadas, para corrigi-las. O principal artefato é o documento de testes e qualidades apresentado no apêndice D.
4.2.1.5 GERENCIAMENTO DE PROJETO
No gerenciamento de projeto identificou-se os riscos do projeto, medindo a qualidade dos artefatos gerados e o impacto que as atinge. O principal artefato gerado foi o Plano de Projeto, no Apêndice B. O plano de iteração para a próxima fase (Apêndice C.2) refere-se ao desenvolvimento da ferramenta, definindo quais casos de uso foram implementados e quais artefatos foram gerados.
4.2.1.6 GERENCIAMENTO OPERACIONAL
Ocorreu a elaboração do documento de customização da metodologia de desenvolvimento WAP, Apêndice G. A instalação das ferramentas necessárias para a execução correta do desenvolvimento da ferramenta GDC, fase iniciação, com o desenvolvimento do protótipo da GUI e a construção dos artefatos citados anteriormente.
4.2.2 ELABORAÇÃO
Visando refinar os requisitos da aplicação, e permitindo o entendimento do escopo do projeto, foi construído a Master Page do GDC. No Plano de Projeto definiu-se a data de desenvolvimento entre os dias 04 de outubro de 2011 e 25 de novembro de 2011. Contudo houve um atraso na data de término da etapa por conta de dificuldades encontradas no recorte do layout para a construção da Master Page.
44 4.2.2.1 REQUISITOS
De acordo com o documento de customização da metodologia de desenvolvimento WAP, verifica-se a necessidade, identificando algum caso de uso de maior risco. Contudo nesta disciplina foi validado a não obrigatoriedade, portanto nenhuma funcionalidade foi produzida. O principal marco dessa fase foi o desenvolvimento da Master Page e todos seus métodos de funcionamento.
4.2.2.2 MODELAGEM
Na disciplina de modelagem foram elaborados modelos gráficos tornando a compreensão das funcionalidades mais claras. Foi desenvolvido o Diagrama de Classe do GDC, como um todo, ajudando no entendimento da regra de negócio e da base de dados. A Figura 12 ilustra esse artefato.
45 Figura 12 - Diagrama de Classe GDC
46 4.2.2.3 IMPLEMENTAÇÃO
Nesta disciplina iniciou-se a construção do projeto da GUI, das funcionalidades da Master Page, e o princípio da base de dados. Foi construído e configurado o banco de dados com as tabelas e colunas necessárias para o funcionamento correto da ferramenta GDC. Após a identificação dos dados e seus tipos pelo diagrama de classe, define-se o modelo físico do Banco de Dados, implementado usando a ferramenta Microsoft SQL Server 2008 R2. A Figura 13 pode observar o modelo físico do banco de dados.
47 Figura 13 - Modelo Físico Base de Dados GDC
48 Em seguida foi projetada a Master Page, uma página padrão utilizada posteriormente em todo o site. Esta contém os menus, cabeçalho e rodapé, serve como um modelo base. Esta página compartilha os métodos com as demais páginas, esses procedimentos restringem o acesso de usuários, reformulam a diagramação do menu lateral, montam o caminho de navegação auxiliando para o usuário, entre outras tarefas.
4.2.2.4 TESTE
Para os testes descritos foram utilizado os navegadores Mozilla Firefox
11, Internet Explorer 8/9 e Google Chrome 20.0, e realizados no Visual Studio Professional 2010. A escolha do ambiente de desenvolvimento integrado (IDE)
considera as ferramentas direcionadas ao controle da qualidade, como:
Testes Unitários: Foram os primeiros testes executados, invocando
rotinas de sistemas, suprindo parâmetros com valores pré-definidos e analisando o comportamento resultante, de acordo com o esperado (QUEZEDA, 2011).
Testes de Revisão: Realizados visando inspecionar toda a aplicação,
ou a funcionalidade testada; garantir que pequenos erros sejam validados e seguir padrão de códigos e documentos.
4.2.2.5 GERECIAMENTO DE PROJETO
O principal artefato gerado nesta disciplina foi o plano de iteração da próxima fase a construção da ferramenta. O plano de iteração contém os casos de uso implementados e quais artefatos gerados. O documento de plano de iteração da fase de construção 1 ª Iteração, Apêndice C.3.
A fase de Elaboração foi encerrada, observando que suas metas foram atingidas com sucesso e devidamente testadas.
49 4.2.3 CONSTRUÇÃO
Nesta fase, a primeira atividade desenvolvida foi a revisão do Plano de Projeto e do cronograma inicial. O cronograma inicial tinha duas iterações para a fase de Elaboração. Após o estudo da tecnologia e da metodologia de desenvolvimento, foi reformulada e proposta a construção da fase de Elaboração em apenas uma iteração. Devido a este estudo antecipado e dificuldades encontradas na construção da Master Page, houve um atraso, se comparado com o cronograma inicial, e a fase de Elaboração só teve término na ultima semana de novembro.
Considerando a análise, foi proposto duas iterações para resolver a fase de construção, diferente do proposto no cronograma inicial. Devido ainda ao atraso no término da fase de Elaboração, a primeira iteração da etapa de Construção teve início apenas na segunda semana de Março de 2012 e a próxima iteração teve término na segunda semana do mês de Abril de 2012. Entre as datas de término da fase de Elaboração e início de Construção, houve o período de férias. Reformulado todo o cronograma, pode-se dar continuação no desenvolvimento do projeto. A Figura 14 ilustra a comparação entre os dois cronogramas, o inicial e posteriormente o atual.
50 O principal objetivo da fase de Construção é desenvolver capacidade operacional do sistema a ser construído e os casos de uso. Deste modo, são finalizadas as atividades de modelagem e conclui-se a codificação baseada na arquitetura de software desenvolvida na fase de Iniciação. A arquitetura propõe a construção da camada do SGBD (stored procedures), após é codificada a regra de negócio e a camada de WUI. Esse processo é efetuado no desenvolvimento de cada funcionalidade proposta no Diagrama de casos de uso.
A fase de construção para o desenvolvimento do GDC é composta de duas iterações.
4.2.3.1 PRIMEIRA ITERAÇÃO
Esta iteração teve início na data de 12 de março de 2012 e término 23 de março de 2012, desta iteração é o funcionamento adequado do módulo core, composto pelas seguintes funcionalidades: Efetuar Login, realizar Logout, Consultar
Log e Gerenciar Usuários e Permissões. A seguir, é descrito as disciplinas, que são
respectivo marcos e artefatos que compõe a primeira iteração da fase de construção.
4.2.3.1.1 REQUISITOS
Após realizada a revisão de todos os requisitos da aplicação, nenhuma nova funcionalidade foi identificada, continuando com os mesmos casos de uso, anteriormente apresentados. Cada uma das funcionalidades desenvolvidas contaram com suas respectivas especificações de caso de uso. Deste modo, foi analisado e esclarecido todos os cenários dos casos de uso.
4.2.3.1.2 MODELAGEM
A primeira atividade desenvolvida nesta disciplina foram o acompanhamento e a revisão dos riscos, levantados para a aplicação. A análise, construção e testes
51 das funcionalidades propostas para esta iteração auxiliaram na eliminação da maioria dos riscos.
Para cada caso de uso do Módulo Core foram elaborados: Diagramas de sequencia, diagramas navegacional, e as especificações dos cenários, de cada uma das funcionalidades deste módulo. A Figura 15 ilustra a navegação de todo o GDC, a partir da página Default.aspx.
Figura 15 - Diagrama Navegacional – GDC
As Figuras 16 e 17, respectivamente, apresentam o Diagrama Navegacional Gerenciar Usuário e o Diagrama de Sequencia Inserir Usuário. A Figura 18 ilustra o Diagrama Navegacional Gerenciar Logs.
52 Figura 16 - Diagrama Navegacional - Gerenciar Usuário
53 Figura 17 - Diagrama de Sequencia - Inserir Usuário
54 Figura 18 - Diagrama Navegacional - Gerenciar Log
4.2.3.1.3 IMPLEMENTAÇÃO
O principal caso de uso nesta iteração é Gerenciar Usuários e Permissões, considerando que determinado usuário têm acesso à aplicação, efetuando login no GDC. As permissões do usuário indicam as interfaces diagramadas, exibindo apenas os menus referentes às permissões do usuário logado. A primeira camada de desenvolvimento para qualquer funcionalidade é a de Base de Dados, que desenvolvem as storeds procedures que faz comunicação com a regra de negócio. A Figura 19 apresenta a GetPermissaoPorUsuario, resgatando todas as permissões de determinado usuário. Esse procedimento é requisitado em todo momento que o usuário realiza login no GDC. A segurança da aplicação exige o método, nativo do
55 SQL Server, PWDENCRYPT, que criptografa a senha do usuário. Dessa forma, as senhas na base de dados são manipuladas e salvas, com caracteres diferentes daqueles digitados pelo usuário no momento de cadastro.
A Figura 20 ilustra a camada de WUI de Gerenciar Usuário. A interação com a interface e seu filtro de pesquisa, permite um usuário encontrar outros já cadastrados na aplicação, para desativar, ou alterar dados do usuário escolhido.
56 Figura 20 - WUI - Gerenciar Usuário
4.2.3.1.4 TESTE
Nesta disciplina foram realizados testes manuais para verificar as funcionalidades desenvolvidas previstas na especificação do caso de uso. A padronização de códigos e interface gráfica são verificadas nos cenários de testes e teste de revisão, previsto no plano.
4.2.3.1.5 GERENCIAMENTO DE PROJETO
O principal artefato desenvolvido o Plano para a 2ª Iteração na Construção, que constam os casos de uso que foram desenvolvidos e utilizados como marcos para conclusão da iteração, encontrado no Apêndice C.4.
57 4.2.3.2 SEGUNDA ITERAÇÃO
De acordo com o Plano de Projeto, esta iteração teve início na data de 26 de março de 2012 e término 17 de abril de 2012. O principal marco para conclusão da iteração é o funcionamento adequado do módulo Content: Gerenciar Produto, Gerenciar Clientes e Gerenciar Simulações. A seguir, são descritos as disciplinas, marcos e artefatos que compõe a segunda iteração da fase de construção.
4.2.3.2.1 REQUISITOS
Após a revisão de todos os requisitos da aplicação, observa-se que nenhuma nova funcionalidade foi identificada, assim a ferramenta continua com os mesmos casos de uso apresentados. Cada funcionalidade a serem desenvolvida conta com suas especificações de caso de uso e analisam e esclarecem todos os cenários que os casos de uso oferecem.
4.2.3.2.2 MODELAGEM
A primeira atividade desenvolvida foi o acompanhamento e revisão dos riscos levantados para a aplicação. A análise, construção e testes das funcionalidades propostas para esta iteração auxiliaram na eliminação dos riscos levantados.
Na primeira iteração foram desenvolvidos Diagramas Navegacionais, Diagramas de Sequencia e Especificações dos Casos de Uso para as funcionalidades que compõe o módulo Content. A Figura 21 ilustra o Diagrama Navegacional Gerenciar Produto, principal funcionalidade do módulo.
58 Figura 21 - Diagrama Navegacional - Gerenciar Produto
59 Figura 22 - Diagrama Navegacional - Gerenciar Simulação
60 Figura 23 - Diagrama de Sequencia - Inserir Produto
61
4.2.3.2.3 IMPLEMENTAÇÃO
O principal caso de uso nesta iteração é Gerenciar Produto. Os produtos são os objetos de uma simulação, realizada no módulo Ambiente de Simulação. O produto é composto de um arquivo pré-modelado e uma imagem ilustrada do objeto, visando não sobrecarregar a base de dados, o produto é salvo na tabela Produto, no formato string, o endereço que hospeda o objeto no servidor que hospeda a aplicação. A Figura 24, AtualizaPathObjeto3D, atualiza a coluna que representa o destino do arquivo pré-modelado.
Figura 24 - Stored Procedure - AtualizaPathObj3DProduto
Da construção da regra de negócio desta iteração, os métodos desenvolvidos visam redimensionar imagens em tempo de execução, permitindo a seleção de figuras de qualquer tamanho. As figuras devem obedecer a um padrão de tamanho, exibidos no módulo Ambiente de Simulação. A Figura 25 ilustra um dos métodos responsáveis pelo redimensionamento da imagem.
62 Figura 25 - Método - UploadImagem
A Figura 26 ilustra a camada de WUI Detalhes da Simulação, que permite ao usuário obter diferentes particularidades de uma determinada simulação, como quanto tempo (em segundos) que um cliente demorou, os dados pessoais do cliente e quais produtos foram usados na simulação.
63 Figura 26 - WUI - Detalhes Simulação
4.2.3.2.4 TESTE
Realizados os testes manuais para verificar se as funcionalidades foram desenvolvidas da forma como previsto nas especificações de caso de uso. Os Cenários de Teste, os testes de revisão confirmam a padronização de códigos e interface gráfica. Previsto no Plano de Qualidade e Teste.
64
4.2.3.2.5 GERENCIAMENTO DE PROJETO
O principal artefato desenvolvido foi o Plano de Iteração para a Transição. Indicando quais os marcos, as datas de inicio e término de cada uma das atividades, disponível no Apêndice C.5.
4.2.4 TRANSIÇÃO
A fase de Transição inicia uma série de testes em versões beta do GDC em seu ambiente de teste, indicando melhorias e/ou correções de erros.
O lançamento do produto final conclui esta fase. A discussão das lições aprendidas durante o projeto foi o passo seguinte.
4.2.4.1 TESTE
Nesta fase são elaborados são elaborados alguns cenários de teste visando obter maior precisão do funcionamento. As necessidades de alteração são realizadas neste escopo.
Para a execução dos cenários de testes, é escolhido um testador que avalia seu nível de experiência, de acordo com as seguintes habilidades:
Navega em sites da web no mínimo em 5 dias da semana;
Tem contato contínuo com alguma linguagem de programação;
É programador de plataforma web.
O nível de experiência de um testador pode ser: Razoável (se afirma como verdadeiro, apenas a primeira das opções anteriores), Intermediário (se afirma como verdadeiro a primeira das opções anteriores e a segunda), Avançado (se afirma como verdadeiro todas as opções anteriores).
Para o escopo deste trabalho foi desenvolvido dois cenários de testes, disponíveis nos Apêndice E.1 e E.2, respectivamente.
65 4.2.4.2 IMPLANTAÇÃO
A implantação de aplicações no ambiente web publica em um servidor da
web, as páginas, regra de negócio, arquivos de configuração, script de banco de
dados e todo o material que compõe a aplicação. No caso de soluções web que utilizam o .NET Framework, a ferramenta é o Microsoft Internet Information Service (IIS). Para o escopo desse trabalho, a implantação não foi realizada em um servidor
web para os testes foram utilizados a máquina local, preparada para uma futura
implantação da aplicação em um servidor de hospedagem. As atividades desenvolvidas para a implantação foram:
O Visual Studio 2010: realizou o build do projeto web, gerando os
arquivos para a implantação da aplicação em um servidor web. O Visual Studio compila no formato Dynamic-link library (DLL) a regra de negócio e o código fonte implementado nas páginas Aspx. As páginas ASP, arquivos de configuração e demais itens necessários para um correto funcionamento da aplicação em outro ambiente que não a máquina local, também foram gerados.
O SQL Server 2008: Gera um script da base de dados do GDC, com
todas as tabelas e suas relações; stored procedures e configurações das tabelas. O
script pronto pode ser executado em uma base de dados qualquer, que utilize a
ferramenta SQL Server.
4.2.4.3 GERENCIAMENTO DE PROJETO
Foi finalizado o cronograma e o Plano de Projeto com as datas reais de execução do projeto. Entre a transição das fases de Elaboração e Construção, o cronograma final da aplicação já havia sofrido algumas alterações, conforme observado na Figura 14. O término desta disciplina consta as reais datas de execução das tarefas. O Quadro 3 detalha as atividades do desenvolvimento da ferramenta GDC e suas respectivas datas.
66
2011 2012
Atividades / Meses Jul Ago Set Out Nov Dez Jan Fev Mar Abr Maio Jun Jul
Revisão Bibliográfica Desenvolvimento do GDC
Análise dos Resultados e Redação do Trabalho de Diplomação
Reunião com Orientador
Quadro 3 - Cronograma Oficial
O Quadro 4 apresenta o Cronograma Detalhado e Refinado da construção da ferramenta GDC.
67
2011/2012
Disciplina/Meses Ago Set Out Nov Dez Jan Fev Mar Abr
Requisitos Modelagem Implementação Testes Implantação Ger. Projeto Ger. Operacional
Iniciação Elaboração --- Construção T
68 4.3 RESULTADOS ATINGIDOS
O desenvolvimento do trabalho de conclusão de curso atingiu o objetivo proposto, foram gerados os documentos necessários dos módulos propostos, alguns disponíveis nos Apêndices.
A utilização de modelo de processo a maior vantagem identificada, permitindo descrever cada uma das atividades desenvolvidas e as datas de início e fim. Os atrasos foram ajustados reestruturando o modelo de processo não comprometendo seus marcos.
O processo finalizado e validado, observa-se o uso de uma metodologia adequada e de customização flexível.
Em conjunto com o Módulo Ambiente de Simulação, a ferramenta GDC funcionou corretamente atingindo a aplicação S3D e seu objetivo.
4.4 DIFICULDADES ENCONTRADAS
Algumas dificuldades foram encontradas durante toda a análise e desenvolvimento a ferramenta GDC. A primeira foi um problema prever as datas de início e término de cada uma das fases, do modelo de processo.
A segunda ocorreu durante a disciplina de implementação na fase de Elaboração, cujo marco principal era o objeto “Master Page”, cujo problema era não conhecer as ferramentas para a construção da WUI, ferramentas como Adobe
Photoshop CS4, Adobe Illustrator CS4, entre outras.
Na comunicação com o módulo Ambiente de Simulação, na necessidade de acompanhar o desenvolvimento do outro módulo para que não houvesse nenhuma dificuldade ao fornecer conteúdo errado ou absorver alguma substancia desnecessária do Ambiente de Simulação. Considerando que a construção do Ambiente de Simulação utilizou outra ferramenta, tecnologias.
69
5. CONCLUSÃO
Com o término deste trabalho, muitos conhecimentos e experiências foram adquiridos. Algumas considerações requerem um tópico mais detalhado, bem como as perspectivas para o desenvolvimento de um trabalho futuro.
4.1 CONSIDERAÇÕES FINAIS
Considerando o objetivo do trabalho de análisar e desenvolver um software do tipo CMS, com a habilidade de se comunicar com um segundo módulo. O gestor de conteúdo e ambiente de simulação, compõe o Simulador 3D.
O processo de desenvolvimento em conjunto com a modelagem, o acompanhamento dos riscos; o plano de iteração e o cronograma foram úteis para examinar o progresso do projeto. Acompanhadas de eventuais adequações ou modificações dentro do desenvolvimento cumprindo os objetivos do sistema.
O desenvolvimento ágil e mais rápido de softwares é fundamental, exigência de usuários e clientes cumprimento de prazos e qualidade. As metodologias que reduzem o tempo gasto com a análise e construção da ferramenta, trazem um benefício enorme, aos responsáveis pelo desenvolvimento, aos usuários e clientes.
A ferramenta S3D visa inovar e oferecer ao mercado de software atual. A aceitação da aplicação é de fundamental importância considerando a localização dos usuários e a plataforma web.
4.2 PERSPECTIVAS FUTURAS
A tecnologia se transforma e evolui de uma maneira rápida integrar novas funcionalidades ao sistema GDC e fundamental.
A atual versão do GDC permite que um determinado usuário insira um novo produto. Esse produto, obrigatoriamente deverá se relacionar com um objeto pré-modelado, que será fruto de interação com o usuário no módulo Ambiente de Simulação. Esse artefato pré-modelado, atualmente só é permitido sua escolha, se o mesmo for da extensão “.unity3D”. A próxima versão do gestor de conteúdo permitirá que o usuário selecione um arquivo de modelagem 3D de diferentes
70 formatos, sendo que a responsabilidade de convertê-lo para o formato “.unity3D” será da ferramenta GDC.
71
6. REFERÊNCIAS
ALMEIDA, Mário F. Customização de processo para aplicações Web com
princípios das metodologias MSF, RUP, WebE E CMMI. 2008. Monografia
(Especialização em Engenharia de Software com UML). Centro Universitário Filadélfia, Londrina, Paraná 2008.
ALMEIDA, Yuri. et al. CMS e a produção colaborativa de conteúdo. Revista Espírito Livre São Paulo, p. 49, jun. 2010. Disponível em: <http://revista.espiritolivre.org/pdffiles/Revista_EspiritoLivre_015_junho2010.pdf>. Acesso em: 20 Jun. 2012.
BBC NEWS. Web users getting more ruthless. Disponível em: <http://news.bbc.co.uk/2/hi/technology/7417496.stm>. Acesso em: 04 Jun. 2012. CONALLEN, Jim. Desenvolvendo aplicações web com UML. Rio de Janeiro: Campus, 2003.
CORDEIRO, P. B. Utilizando o Rational Rose. Paraiba, Brasil, 2002.
DEITEL, Harvey M.; DEITEL, Paul J.; C# como programar. São Paulo: Makron Books, 2005.
FERNANDES, Alessandro. Introdução a Stored Procedures e Triggers no
Firebird, Jul. 2002. Disponível em:
<http://www.comunidade-firebird.org/cflp/downloads/CFLP_T003.PDF>. Acesso em: 07 Jul. 2012. GOMES, Ana. XHTML/CSS: Criação de Páginas Web. São Paulo, 2010.
GOOGLE. Otimização de sites para Mecanismos de Pesquisa (SEO). Disponível em:
<http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.co
m/pt-BR//intl/pt-BR/webmasters/docs/guia-otimizacao-para-mecanismos-de-pesquisa-pt-br.pdf/>. Acesso em: 22 Jun. 2012.
GRUNDMAN, M. A CMMI Maturity Level 2 assessment of RUP. IBM
DevelopersWorks. Disponível em:
<http://www.ibm.com/developerworks/rational/library/dec05/grundmann/>. Acesso em: 03 Jul. 2012.
GUEDES, Gilleanes T. A.; UML: Uma abordagem prática. 2 ed., São Paulo: NovaTec, 2005.
