Download - Portfolio Grupo 4 ADS Unopar Desafios1-2-3-4
Eunápolis - BA2015
AGUINALDO GOMES DE SOUZA, ELENILTON DE SOUSA FREITAS, ELOISA SALA DE OLIVEIRA AMARAL, VALDINEI PINHEIRO DOS
SANTOS
SISTEMA DE ENSINO PRESENCIAL CONECTADOCURSO SUPERIOR DE ANÁLISE E DESENVOLVIMENTO DE
SISTEMAS
PRODUÇÃO TEXTUAL EM GRUPO - BIBLIOAPP
Eunápolis – BA2015
PRODUÇÃO TEXTUAL EM GRUPO - BIBLIOAPP
Trabalho de Análise e Desenvolvimento de Sistemas apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral na disciplina De Projeto Orientado a Objetos, Engenharia e Projeto de Software, Programação para Web II.
Orientador: Márcio Roberto Chiaveli,Luis Claudio Perini,Marco Ikuro Hisatomi,Veronice de Freitas.
AGUINALDO GOMES DE SOUZA, ELENILTON DE SOUSA FREITAS, ELOISA SALA DE OLIVEIRA AMARAL, VALDINEI PINHEIRO DOS
SANTOS
SUMÁRIO
1 INTRODUÇÃO.....................................................................................................3
2 OBJETIVO...........................................................................................................4
3 DESENVOLVIMENTO..........................................................................................5
3.1 PROJETO DE ARQUITETURA...........................................................................5
3.2 EAP – Estrutura Analítica do Projeto................................................................9
3.3 Cronograma e Relação dos envolvidos...........................................................9
3.3.1 PROGRAMAÇÃO PARA WEB II................................................................10
3.3.1.1 XStream........................................................................................................10
3.3.1.2 Hibernate......................................................................................................10
3.3.2 PROJETO ORIENTADO A OBJETOS.......................................................12
3.3.2.1 Diagrama de Classe.....................................................................................13
3.3.2.2 Diagrama de Componentes........................................................................13
4 CONCLUSÃO.....................................................................................................15
REFERÊNCIAS.........................................................................................................16
1 INTRODUÇÃO
Neste trabalho, apresentaremos uma proposta de desenvolvimento
de software para o empresário Sr. Freitas, proprietário da Macrosoft
Desenvolvimento e Informática, cujo principal produto é o BiblioTECH2.0, um
sistema de gerenciamento de bibliotecas que funciona em nuvem.
O software proposto trata-se de um aplicativo, denominado
BiblioAPP, que controla a data de empréstimo e devolução, emitindo um aviso
sonoro 24, 12, 6 e 3 horas antes do final do prazo para a devolução de livros para a
biblioteca parceira.
Este documento apresenta o documento de projeto (design) do
sistema de apoio às atividades da BiblioTECH2.0. Essa atividade foi conduzida em
refinamentos sucessivos, começando pelo projeto da arquitetura do sistema,
passando ao detalhamento dos componentes da arquitetura, até chegar ao projeto
detalhado das classes.
3
2 OBJETIVO
Visando a complementação de um sistema já existente, foi
elaborado uma proposta para o desenvolvimento de um sistema para lembretes de
devolução de livros de uma biblioteca,
O atual sistema conta com um gerenciamento de estoque e
empréstimo de livros. Ao utilizar o sistema notou-se a necessidade da criação de
uma aplicação web para o alerta informando a devolução do livro para o cliente que
o pegou emprestado.
4
3 DESENVOLVIMENTO
Nesse projeto será realizada a entrega de um aplicativo com completa
capacidade de operação. Está englobada nesse escopo a construção da aplicação e
a adaptação da empresa para atender as necessidades desse ramo de atividade.
Ao iniciar a elaboração do projeto, definimos que por já existir um
sistema e este efetuar a exportação de um arquivo XML contendo as informações,
foi proposto que a nova aplicação receberia essas informações pelo arquivo
exportado.
3.1 PROJETO DE ARQUITETURA
O aplicativo em questão trata-se de um sistema que envolve uma grande
quantidade de dados e sua gerencia será feita utilizando um banco de dados
PostgreSQL. Os usuários acessarão os dados sem concorrência utilizando a internet
e este aplicativo estará integrado ao sistema de bibliotecas nas nuvens.
Como se pode perceber pela especificação de requisitos para o sistema em
questão, não há grandes restrições de desempenho e disponibilidade. Assim,
levando-se em consideração os requisitos para o sistema proposto, foram
considerados como os principais atributos de qualidade a serem incorporados ao
sistema os seguintes, apresentados juntamente com as táticas a serem aplicadas:
Usabilidade:
As interfaces do sistema permitem, sempre que possível, a entrada por
meio de seleção ao invés da digitação de campos.
Segurança:
Autenticar usuários usando login e senha;
Limitar a exposição, disponibilizando pela Internet somente
funcionalidades de consulta ao prazo de devolução.
O aplicativo em questão não será organizado por módulos, devido à sua
simplicidade, mas usaremos o modelo de repositório. O aplicativo desenvolvido e o
sistema de biblioteca já existente devem trocar informações de modo que possam
trabalhar juntos eficientemente. Esse modelo é, portanto, adequado para aplicações
5
em que os dados são gerados por um sistema e usados por outro. O repositório é
passivo e o controle é de responsabilidade dos subsistemas que o usam.
Também será necessário a utilização de modelos orientados a interrupções.
Isso será preciso para requisições em tempo real, nas quais as interrupções
externas são detectadas por um trator de interrupções. A vantagem dessa
abordagem é que ela permite respostas muito rápidas aos eventos a serem
implementados.
Para o desenvolvimento do aplicativo BiblioAPP optou-se pela arquitetura de
cliente-servidor, por que a vantagem de um modelo cliente servidor é que ele é uma
arquitetura distribuída. O uso efetivo de sistemas em rede pode ser feito com muitos
processadores distribuídos. É fácil adicionar um novo servidor e integra-lo ao
restante do sistema. A figura 1 demonstra a arquitetura cliente-servidor.
Figura 1 – Arquitetura cliente-servidor
Também será usado na Arquitetura de aplicações o sistema de
processamento de linguagem. Em engenharia de software, os sistemas de
processamento de linguagens mais amplamente usados são os compiladores que
traduzem uma linguagem artificial de programação de alto nível em código de
maquina. Mais outros sistemas de processamento de linguagens traduzem uma
descrição de dados XML em comandos para consultar um banco de dados e
sistemas de processamento de linguagem natural que tentam traduzir uma
linguagem em outra.
No nosso caso, o sistema da biblioteca criará um XML com os dados básicos
de locação do livro e nosso aplicativo irá baixar e ler esse XML em determinado
6
intervalo de tempo para analisar a data da devolução do livro e então disparar o sinal
sonoro de acordo com os critérios pré-estabelecidos.
Gerenciamento de Configuraçoes:
Papéis Equipe Responsabilidade
Gerente de ConfiguraçãoValdinei P. dos
Santos
Estabelecer Políticas de GC
Escrever Plano de GC
Configurar Ambiente de GC
Criar Espaços de Trabalho de
Integração
Criar Baselines
Promover Baselines
CCM
Aguinaldo G. de
Souza
Eloisa S. O. Amaral
Estabelecer Processo de Controle de
Mudanças
Revisar Solicitação de Mudança
Desenvolvedor
Elenilton de S. Freitas
Valdinei P. dos
Santos
Seguir os padrões e procedimentos
definidos no Plano de Gerência de
Configuração
Todos os Papéis:
Elenilton de S. Freitas
Valdinei P. dos
Santos
Enviar Solicitação de Mudança
Atualizar Solicitação de Mudança
Tabela 1: Responsáveis e Responsabilidades
As solicitações de mudanças das Baselines serão realizadas através da
ferramenta Issues disponibilizada pela Google através do endereço do repositório na
qual terá o seguinte fluxo:
Figura 2 – fluxo de mudanças das baselines
7
Status do Issues
Atividade DescriçãoResponsabilidade
AbertoCriação da solicitação. Todos
Em Analise Análise da solicitação Analista de sistemas
Analisado Aguardando desenvolvimento Analista de sistemas
Em desenvolvimento Solicitação sendo desenvolvida Desenvolvedor
Desenvolvido Aguardando teste Desenvolvedor
Em testes Solicitação em teste Testador
Testado com erro Aguardando desenvolvimento Testador
Testado sem erro Solicitação esperando finalização pelo analista
Testador
Finalizado Solicitação finalizada Analista
O comitê de Controle de Mudanças (CCM) será formado por Analista de
sistemas e Gerente de Projetos. O backup do repositório deverá ser feito toda
semana pelo gerente de configuração. Os artefatos alterados durante a semana de
trabalho será armazenado em mídia de CD. Um para cada Mês.
Os CDs deverão conter a seguinte descrição: a data e hora e a periodicidade.
Liberação de release:
Basicamente os projetos irão ser desenvolvidos e testados na main-line. Para
gerar o release a versão em questão tem que estar devidamente testada, livre de
erro e aprovado pelo analista responsável.
8
3.2 EAP – ESTRUTURA ANALÍTICA DO PROJETO
A estrutura analítica do projeto é uma estrutura hierárquica que
representa graficamente as entregas do projeto, elaborando uma subdivisão das
entregas e do trabalho do projeto em componentes menores e mais facilmente
gerenciáveis.
A EAP não é criada apenas para o gerente do projeto, mas para
toda a equipe de execução do projeto, bem como para as demais partes
interessadas tais como clientes e fornecedores.
Elaboramos então a seguinte EAP, veja a imagem 1.1:
Figura 1.1 EAP do Projeto
3.3 CRONOGRAMA E RELAÇÃO DOS ENVOLVIDOS
Visando o cumprimento dos prazos e do projeto como um todo, foi
elaborado um cronograma contendo prazos e metas a serem cumpridas, facilitando
o entendimento do projeto no seu todo e as tarefas a seus respectivos responsáveis.
9
Figura 2.1 Cronograma
3.3.1 PROGRAMAÇÃO PARA WEB II
Para o desenvolvimento do nosso sistema, foi utilizado alguns
frameworks.
3.3.1.1 XSTREAM
Para o uso de XML em persistência de dados, transmissão e
configuração, utilizamos o XStream, pela sua facilidade de uso e performance
elevada em comparação aos demais.
3.3.1.2 HIBERNATE
O objetivo do Hibernate é diminuir a complexidade entre os
programas Java, baseado no modelo orientado a objeto, que precisam trabalhar com
um banco de dados do modelo relacional (presente na maioria dos SGBDs). Em
especial, no desenvolvimento de consultas e atualizações dos dados.
Sua principal característica é a transformação das classes em Java
para tabelas de dados (e dos tipos de dados Java para os da SQL).
O Hibernate gera as chamadas SQL e libera o desenvolvedor do
trabalho manual da conversão dos dados resultante, mantendo o programa portável
para quaisquer bancos de dados SQL, porém causando um pequeno aumento no
10
tempo de execução.
O projeto, foi elaborado para ser o mais simples possível, facilitando
a utilização, não sendo necessário mudar completamente de sistema. O
funcionamento é simples, o cliente loga no sistema, veja a imagem 3.1.
Figura 3.1 Login do Sistema
Efetue o envio do XML, depois visualiza as informações dos
empréstimos, visto que o arquivo XML já foi carregado
Figura 4 Relatório de Empréstimos.
11
3.3.2 PROJETO ORIENTADO A OBJETOS
Para facilitar o entendimento do estudo de caso, foi elaborado
diagramas, que são utilizados pela equipe.
Parte do código utilizado:
Figura 5 código-fonte
Figura 6 código-fonte
12
3.3.2.1 DIAGRAMA DE CLASSE
Descreve o objeto e as estruturas usadas pelo aplicativo
internamente, as informações não possuem referência a qualquer implementação
específica, simplesmente explicas as classes do sistema.
Figura 5.1 Diagrama de Classe
3.3.2.2 DIAGRAMA DE COMPONENTES
Ilustra como as classes deverão se encontrar, organizadas através
da noção de componentes de trabalho. Por exemplo, pode-se explicitar, para cada
componente, qual das classes que ele representa.
É utilizado para modelar os dados do código fonte, do código
executável do software, Destacar a função de cada módulo para facilitar a sua
reutilização e Auxiliar no processo de engenharia reversa, por meio da organização
dos módulos do sistema e seus relacionamentos.
13
Figura 6.1 Diagrama de Componentes
14
4 CONCLUSÃO
Neste trabalho fizemos a elaboração de um projeto de um produto
de software. Esta pesquisa trouxe conhecimentos que serão extremamente uteis
para quem pretende trabalhar com esse tipo de desenvolvimento. No conteúdo aqui
apresentado nos elaboramos uma proposta de projeto onde utilizamos da
Engenharia e Projeto de Software a EAP – Estrutura Analítica do Projeto, o
Cronograma das atividades para o desenvolvimento do projeto e a Relação dos
envolvidos, papéis dentro do projeto. Implementamos uma consulta/relatório
relacionado ao projeto usando o framework (Java Web). Analisando mais sobre os
Diagrama da UML melhorou bastante o entendimento sobre o mesmo, quando
devemos implementar o diagrama, e os benefícios de sua utilização dentro do
projeto de desenvolvimento.
15
REFERÊNCIAS
LAHR Thiago Canozzo. Segurança em Aplicações Web. Sep 3 2009. Dissertação (Analista de Segurança da Informação) - PUC-Campinas, 2002. Disponível em: < https://www.ibm.com/developerworks/community/blogs/tlcbr/entry/seguranca_em_aplicacoes_web?lang=en>. Acesso em: 25 out. 2014.
Wikipédia. Diagrama de atividade. Wikipédia, a enciclopédia livre. Disponível em: < http://pt.wikipedia.org/wiki/Diagrama_de_atividade>. Acesso em: 25 out. 2014.
Wikipédia. Modelo entidade relacionamento. Wikipédia, a enciclopédia livre. Disponível em: < http://pt.wikipedia.org/wiki/Modelo_entidade_relacionamento>. Acesso em: 24 out. 2014.
PESSOA Márcio. Segurança em PHP. Dissertação (Desenvolva programas PHP com alto nível de segurança e aprenda como manter os servidores web livres de ameaças) - Novatec. Disponível em: < http://www.martinsfontespaulista.com.br/anexos/produtos/capitulos/254879.pdf>. Acesso em: 25 out. 2014.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edição. São Paulo: Pearson Addison Wesley, 2007.
16