Portfolio Grupo 5semestre Ads

8/16/2019 Portfolio Grupo 5semestre Ads

1/21

BRASÍLIA/DF2015

ALESSANDRO FERNANDES SANTOS

CARLOS EDUARDO CARVALHOCARLOS THIAGO REIS DOS SANTOSISABELLA MOURA ALVES

NATALIA GOMES MARQUES

SISTEMA DE ENSINO PRESENCIAL CONECTADOCURSO SUPERIOR DE ANÁLISE E DESENVOLVIMENTO DE

SISTEMAS

PRODUÇÃO TEXTUAL EM GRUPO

BOOKTECH3.0


2/21

Brasília/DF2015

PRODUÇÃO TEXTUAL EM GRUPOBOOKTECH3.0

Trabalho de Análise e Desenvolvimento de Sistemasapresentado à Universidade Norte do Paraná -UNOPAR, como requisito parcial para a obtenção demédia bimestral na disciplina De Projeto Orientado aObjetos, Engenharia e Projeto de Software,Programação para Web II.

Orientador: Márcio Roberto Chiaveli,Luis Claudio Perini,Marco Ikuro Hisatomi,Veronice de Freitas.

ALESSANDRO FERNANDES SANTOSCARLOS EDUARDO CARVALHO

CARLOS THIAGO REIS DOS SANTOS

ISABELLA MOURA ALVESNATALIA GOMES MARQUES


3/21

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 ............................................................. 12

3.3 Cronograma e Relação dos envolvidos ......................................................... 13

3.3.1 PROGRAMAÇÃO PARA WEB II ............................................................... 14

3.3.1.1 XStream ........................................................................................................ 14

3.3.1.2 Hibernate ...................................................................................................... 14

3.3.2 PROJETO ORIENTADO A OBJETOS ..............Erro! Indicador não definido.

3.3.2.1 Diagrama de Classe .................................................................................... 17

3.3.2.2 Diagrama de Componentes ........................................................................ 18

4 CONCLUSÃO .................................................................................................... 19

REFERÊNCIAS ......................................................................................................... 20


4/21

3

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 BOOKTECH3.0, um

sistema de gerenciamento de bibliotecas que funciona em nuvem.

O software proposto trata-se de um aplicativo, denominado

BOOKTECH3.0, 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) dosistema de apoio às atividades da BOOKTECH3.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.


5/21

4

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.


6/21

5

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.

O projeto de arquitetura é primeiro estágio no processo de projetos. Ele

estabelece um framework para controlar a comunicação dos subsistemas, que são

sistemas grandes decompostos em subsistemas e que fornece algum conjunto de

serviços relacionados. Ele também representa uma ligação critica entre processos

de engenharia de projeto e requisitos. Existem três vantagens de projetar e

documentar explicitamente uma arquitetura de software:

Comunicação de Stakeholders: é uma apresentação em alto nível do sistema

que enfoca a discussão entre diferentes Stakeholders.

Analise de sistemas: Tem profundo efeito sobre o sistema, mostra se o

sistema pode atender aos requisitos críticos como, confiabilidade,

desempenho e facilidade de manutenção.

Reuso em larga escala: apoia o reuso em larga escala de sistemas

que possuem arquiteturas de sistemas familiares. A arquitetura de software

serve para negociar requisitos de sistema e estruturar discussões com os

clientes, desenvolvedores e gerentes. É uma ferramenta essencial parra

gerenciamento de complexidade, ocultando detalhes e focando as abstrações

principais do sistema.


7/21

6

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

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.

Ao Projetar uma arquitetura de sistemas, você precisa decidir o que seusistema e classes mais amplas de aplicação têm em comum, e decidir quanto

conhecimento dessas arquiteturas de aplicação você pode reusar. A arquitetura de

um sistema de software pode ser baseada em um modelo ou estilo de arquitetura

específico. Em alguns casos a arquitetura geral de um sistema pode ser uma

arquitetura composta.

Os modelos de arquitetura que podem ser desenvolvidos: Um Modelo

Dinâmico de Processo: que mostra como o sistema esta organizado em

processos em tempo de execução. A organização de um sistema reflete a

estratégia básica usada para estrutura-lo. Você precisa tomar decisões sobre


8/21

7

o modelo geral organizacional de um sistema com antecedência no processo

de projeto de arquitetura. A organização pode refletir diretamente na estrutura

subsistema.

Modelo Cliente-Servidor: é um modelo em que o sistema é organizado como

um conjunto de serviços e servidores e clientes associados que acessam e

usam os serviços. Os clientes talvez precisem saber os nomes dos servidores

disponíveis e os serviços que eles fornecem. No entanto os servidores não

precisam saber a identidade do cliente ou quantos são. São acessados os

serviços por meio de chamadas remotas de procedimento usando um

protocolo request –eply, o cliente faz um pedido a um servidor e espera ate

receber uma resposta. 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.

 O Modelo em Camadas: O modelo em camadas organiza um sistema em

camadas, cada uma das quais fornecendo um conjunto de serviços.

A abordagem em camadas apoia o desenvolvimento incremental de sistemas.

À medida que uma camada é desenvolvida alguns serviços fornecidos poressa camada podem ser disponibilizados para os usuários. Essa arquitetura

também é modificável e portável. Desde que sua interface permaneça

inalterada, uma camada poderá ser substituída por outra equivalente. Uma

desvantagem da abordagem em camadas é que a estruturação de sistemas

dessa maneira pode ser difícil. As camadas mais internas podem fornecer

recursos básicos, como gerenciamento de arquivos, necessários em todos os

níveis.

Arquitetura de Sistemas Distribuídos

As arquiteturas de referência não são geralmente consideradas um roteiro de

implementações. Em vez disso, sua principal função é ser um meio de discussão de

arquiteturas de domínio especifico e de comparação de sistemas diferentes em um

domínio. Um modelo de referencia fornece um vocabulário para comparação. Eleatua como uma base, em relação a qual os sistemas podem ser avaliados.


9/21

8

Uma proposta de modelo de referencia é um modelo para ambientes CASE que

identifica cinco conjuntos de serviços que um ambiente CASE deve fornecer. Ele

deve também fornecer recursos de plug in para ferramentas CASE individuais que

usam esses serviços.

Os cincos níveis de referencias são:

Serviços de repositório de dados: estes serviços fornecem recursos para o

armazenamento e o gerenciamento de itens de dados e seus

relacionamentos.

Serviços de integração de dados: estes serviços fornecem recursos para o

gerenciamento de grupos ou para definição de relacionamentos entre eles.

Serviços de gerenciamento de tarefas: estes serviços fornecem recursos paraa definição e aprovação de modelos de processo.

Serviços de mensagem: comunica ferramenta-ferramenta, ambiente-

ferramenta e ambiente-ambiente.

Serviços de interface com o usuário: este serviço fornecem recursos para o

desenvolvimento de interface com o usuário.

A finalidade dessa arquitetura de referencia é ser um meio de classificação e

comparação de ferramentas e ambientes CASE integrados.

Para o desenvolvimento do aplicativo BOOKTECH3.0 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


10/21

9

Em uma arquitetura cliente-servidor, uma aplicação é modelada como um

conjunto de clientes que usam esses serviços. Os clientes precisam estar

informados sobre os serviços disponíveis, mas geralmente não sabem da existência

de outros clientes. Vários processos de serviços podem ser executados em um único

processador de serviço, portanto não há mapeamento entre processos e

processadores de um sistema.

O projeto de sistemas cliente-servidor deve refletir a estrutura lógica da aplicação

que esta sendo desenvolvida. Um exemplo é uma aplicação q esta dividida em 3

camadas: a camada de apresentação, que se encarrega da apresentação de

informações para o usuário e toda a interação com o usuário. A camada deprocessos de aplicações que se encarrega da implementação da lógica da aplicação

e a camada de gerenciamento de dados, que se encarrega de todas as operações

de banco de dados. A arquitetura cliente-servidor mais simples denomina-se

arquitetura cliente-servidor de duas camadas, podem ter duas formas:

Modelo cliente-magro: o processamento e o gerenciamento de dados são

realizados no servidor. O cliente apenas executa o software de apresentação. Modelo cliente-gordo: o servidor é responsável somente pelo gerenciamento

de dados. O software do cliente implementa a lógica da aplicação e as

interações com o usuário do sistema.

Uma desvantagem do modelo cliente-magro é que ele impõe uma grande

carga de processamento sobre o servidor e a rede. O modelo cliente-gordo faz uso

dessa capacidade de processamento disponível e distribui o processamento lógico

de aplicação e a apresentação do cliente. O servidor é essencialmente um servidorde transações que gerencia todas as transações do banco de dados. Enquanto o

modelo cliente-gordo distribui o processamento mais eficientemente do que um

modelo cliente-magro, o gerenciamento do sistema é mais complexo. A

funcionalidade da aplicação é dividida entre vários computadores.

Quando o software precisa ser alterado, isso envolve reinstalação em cada

computador cliente, o que pode resultar em um custo significativo se houver

centenas de clientes no sistema. O problema com a abordagem cliente-servidor de

duas camadas é que as três camadas lógicas, devem ser mapeadas sobre dois

sistemas de computador, o cliente e o servidor. Pode haver problemas de


11/21

10

escalabilidade e desempenho, se o modelo cliente-magro for escolhido, ou

problemas de gerenciamento de sistemas, se o modelo cliente-gordo for usado. Para

evitar esses problemas uma alternativa é usar o modelo cliente-servidor de três

camadas. Em alguns casos é melhor estender o modelo cliente-servidor de três

camadas para uma variante com varias camadas, na qual servidores adicionais são

incorporados ao sistema.

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 demaquina. 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 determinadointervalo 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ções:

Papéis Equipe Responsabilidade

Gerente de ConfiguraçãoValdinei P. dos

Santos

Estabelecer Políticas de GC

Escrever Plano de GC

Configurar Ambiente de GCCriar 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


12/21

11

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

Status do Issues

Atividade Descrição Responsabilidade

Aberto

Criaçã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 Testador


13/21

12

analista

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.

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.

Temos que o APP BookTech3.0 decidiu investir em um software

ERP, mais especificamente da empresa SAP com módulo SAP BI (Business

Intelligence), para ser o sistema central adotado.

Segundo o PMBok, a EAP é uma decomposição hierárquica

orientada à entrega do trabalho a ser executado pela equipe para atingir os objetivos

do projeto e criar as entregas requisitadas, com cada nível descendente da EAP

representando uma definição gradualmente mais detalhada do trabalho do projeto.


14/21

13

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.

O Cronograma do projeto é o plano de distribuição das diferentes

etapas de sua execução, em períodos de tempos verdadeiros. Serve a diferentes

propósitos: permite verificar se os analistas tem conhecimento consistente acerca

das diferentes etapas que deverá percorrer, para executar o projeto que planejou, e

do período de tempo que deverá despender, ao fazê-lo. Serve, também, para

organizar e distribuir, racionalmente, em suas etapas, o tempo disponível para a

execução do projeto.

Segue abaixo um cronograma do App BookTech3.0 para

implementação do ERP, conforme o tema proposto.


15/21

14

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


16/21

15

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

.


17/21

16

3.3.2 Projeto Orientado a Objetos

Um diagrama de classe UML descreve o objeto e as estruturas

usadas pelo seu aplicativo internamente e comunicação com seus usuários deinformações. Ele descreve as informações sem referência a qualquer implementaçãoespecífica. Suas classes e relacionamentos podem ser implementados de diversasmaneiras, como tabelas de banco de dados, nós XML ou composições de objetos desoftware.

A linguagem UML especifica um conjunto de construtos que podemser utilizados para definir sistemas de software de tamanho e complexidadearbitrários. Em particular, define-se o conceito de componente, como uma unidademodular com um conjunto de interfaces bem definidas, que pode ser substituídodentro de seu ambiente. O conceito de componente é oriundo da área de

desenvolvimento baseado em componentes, onde um componente é modeladodurante o ciclo de desenvolvimento e refinado sucessivamente durante a instalaçãoe execução do sistema. Um aspecto importante do desenvolvimento baseado emcomponentes é o reuso de componentes previamente construídos. Um componentepode ser considerado como uma unidade autônoma dentro de um sistema ousubsistema. Ele deve possuir uma ou mais interfaces, que podem serpotencialmente disponibilizadas por meio de portas, e seu interior é normalmenteinacessível.

Descreve como os elementos são organizados dentro de pacotes esuas dependências, mostrando, inclusive, pacotes importados e extensões de

pacotes, além de pacotes contidos em outros.Um pacote pode ter qualquer diagramada UML, porém são maiscomuns em diagramas de caso de uso, para ajudar aabstração do domínio do problema, e em classes, para ajudar na organização dasclasses construídas em sistemas médios e grandes.

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


18/21

17

Figura 6 código-fonte

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.


19/21

18

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.

Figura 6.1 Diagrama de Componentes


20/21

19

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, quandodevemos implementar o diagrama, e os benefícios de sua utilização dentro do

projeto de desenvolvimento.


21/21

20

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: . 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 PHPcom alto nível de segurança e aprenda como manter os servidores web livres deameaç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.

Documents

Portfolio Grupo 5semestre Ads