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