Anda di halaman 1dari 25

SISTEMA DE ENSINO PRESENCIAL CONECTADO

ANALISE E DESENVOLVIMENTO DE SISTEMAS


XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXX

ATIVIDADE INTERDICIPLINAR DE GRUPO

Ariquemes
2015

XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXX

ATIVIDADE INTERDICIPLINAR DE GRUPO

Trabalho apresentado ao Curso Tecnologia Em Anlise E


Desenvolvimento De Sistemas
da UNOPAR Universidade Norte do Paran, para as disciplinas:
Projeto Orientado a Objetos, Engenharia e Projeto de
Software e Programao para Web II.
Orientador: Prof. Mrcio Roberto Chiaveli, Luis Claudio
Perini, Marco Ikuro Hisatomi e Veronice de Freitas.

Ariquemes
2015

SUMRIO
1

INTRODUO.......................................................................................................5

DESAFIO 1 - PROPOSTA DE PROJETO.............................................................6

DESAFIO 2 - BASEADO NO PMBOK................................................................12

DESAFIO 3 - PROGRAMAO JAVA WEB......................................................16

DESAFIO 4 - DIAGRAMAS DA UML..................................................................18

CONSIDERAES FINAIS........................................................................................23
REFERNCIAS...........................................................................................................23

1 INTRODUO

A produo textual interdisciplinar grupo tem como base os assuntos


abordados no eixo temtico, envolvendo todas as disciplinas do semestre. Neste
semestre dada continuidade em alguns temas tratados no semestre anterior, alm
de abordar a viabilizao do desenvolvimento de sistema de informao analisado,
incrementar o conhecimento em engenharia de software, gesto de projetos e
programao para Web. Ao projetar uma arquitetura de sistemas, voc precisa
decidir o que seu sistema e classes mais amplas de aplicao tem em comum, e
decidir quanto conhecimento dessas arquiteturas de aplicao voc pode reusar. O
principal problema que ele necessita ser um formato comum para transferir dados
que possa ser reconhecido por todas as transformaes. Hoje, uma empresa, com
em um ambiente tecnologicamente preparado torna-se mais competitiva no cenrio
atual, se diferenciando dos demais e atendendo seus clientes com excelncia. Cada
vez mais as empresas buscam alternativas para facilitar o gerenciamento de suas
atividades, visando aumentar o controle e obter informaes precisas que possam
de fato agilizar a tomada de decises e, consequentemente, melhorar o nvel de
servio prestado.

2 DESAFIO 1 - PROPOSTA DE PROJETO

O Projeto de arquitetura tem por deciso estabelecer uma


organizao de sistema que satisfaa os requisitos funcionais e no funcionais do
sistema. Durante o processo de projeto de arquitetura, os arquitetos de sistema
preciso tomar uma srie de decises fundamentais que afetam profundamente o
sistema e o seu processo de desenvolvimento. O Sistema de Gerenciamento de Call
Center - SGC, otimiza todas as atividades operacionais e administrativas dentro do
processo de atendimento ao cliente incluindo todo o fluxo de operaes dentro do
servios prestados pela empresa. O SGC operacional significa que a empresa
depende menos da experincia das pessoas, uma vez que o sistema tem
inteligncia e seguem padroes e cronograma para solucionar problemas no
atemdimento ao cliente.A utilizao de um sistema SGC fundamental para o bom
funcionamento operacional com qualidade no controle de solues de problemas do
clinte sendo assim processado todos os protocolo de atendimento.
Embora cada sistema de software seja nico, pode ocorrer de ter
domnio de aplicao de arquitetura similares que refletem os conceitos
fundamentais de domnio.

Foco no Cliente

Liderana

Envolvimento das Pessoas

Aproximao dos Processos

Sistema de Aproximao com a Gerncia

Melhoria ContnuaAproximao Casual para

Tomada de Deciso

Relacionamento Mutuamente Benfico com

Fornecedor
Essa arquitetura de aplicao pode ser bastante genrica como
a arquitetura de sistemas de gerenciamento de informaes, ou muito mais
especficas.

Finalidade

6
A finalidade do Plano de Desenvolvimento de Software reunir
todas as informaes necessrias para controlar e gerenciar o prottipo de projeto
de Gerenciamento de Navegao e Controle GNC. Ele descreve a abordagem
dada ao desenvolvimento do software e o plano de nvel mais alto gerado e usado
pelos gerentes para coordenar o esforo de desenvolvimento.
O Plano de Desenvolvimento de Software usado por estas
pessoas:
O gerente de projeto utiliza-o para planejar o cronograma do projeto
e as necessidades de recursos e para acompanhar o andamento do projeto em
relao ao cronograma.
Membros da equipe do projeto utilizam-no para entender o que
precisam fazer, quando precisam faz-lo e quais so as outras atividades das quais
eles dependem.

Escopo

Este Plano de Desenvolvimento de Software descreve o plano geral


a ser usado pelo prottipo de projeto GNC incluindo a implantao do produto. Este
projeto rene e sintetiza as seguintes Unidades de Softwares: PCDs Plataforma
de Coleta de Dados. Os detalhes de iteraes individuais sero descritos nos Planos
de Iterao. Os planos, conforme especificado neste documento, baseiam-se nos
requisitos do produto definidos no Documento de Viso.
Este Plano de Desenvolvimento de Software contm as seguintes
informaes:
Viso Geral do Projeto apresenta uma descrio da finalidade, do
escopo e dos objetivos do projeto. Tambm define os produtos que se espera que o
projeto libere.
Organizao do Projeto descreve a estrutura organizacional da
equipe do projeto.
Processo de Gerenciamento explica o custo estimado e o
cronograma, define os principais marcos e fases do projeto e descreve como o
projeto ser monitorado.
Planos e Diretrizes aplicveis apresentam uma viso geral do
processo de desenvolvimento do software, abrangendo mtodos, ferramentas e
tcnicas a serem seguidos.
Gerenciamento de Requisitos
Os requisitos desse sistema so capturados no Documento de
Viso. As mudanas solicitadas nos requisitos so capturadas nas Solicitaes de
Mudana e so aprovadas como parte do processo de Gerenciamento de
Configurao.

7
Controle de Cronograma e Oramento
As despesas so monitoradas pelo gerente de projeto, e reportadas
e avaliadas mensalmente. (Consulte Relatrios e Mtricas abaixo).
O gerente de projeto mantm uma programao mostrando a data
esperada de cada marco. Os itens de linha na programao incluem pacotes de
trabalho atribudos a pessoas. Cada pessoa a quem atribudo um pacote de
trabalho fornece ao gerente do projeto informaes sobre o percentual de concluso
das tarefas semanalmente. As mudanas na programao ficaro a cargo dos
patrocinadores do projeto, que decidiro se o escopo ser alterado a fim de
preservar as datas-alvo de concluso.
Controle de Qualidade
Os defeitos sero registrados e monitorados como Solicitaes de
Mudana, e as mtricas de defeito sero coletadas (consulte Relatrios e Mtricas
abaixo).
Ser necessrio que todos os produtos liberados sejam submetidos
ao processo de reviso adequado, conforme est descrito no Caso de
Desenvolvimento. A reviso necessria para assegurar que cada produto liberado
seja de qualidade aceitvel, usando as orientaes descritas nos pontos de
verificao e nas diretrizes de reviso do RUP para Projetos Pequenos.
Todos os defeitos encontrados durante a reviso que no forem
corrigidos antes da liberao para integrao devero ser capturados como
Solicitaes de Mudana para que no sejam esquecidos.
Um exemplo disso so as linhas de produtos de aplicaes que so
criadas com base em um ncleo de arquitetura com variaes que satisfazem os
requisitos especficos do cliente.
Ao se projetar uma arquitetura de sistema, necessita-se decidir o
que seu sistema e classes mais amplas de aplicao tm em comum, e decidir
quanto conhecimento dessas arquiteturas de aplicao pode-se reusar.
A arquitetura de um sistema de software pode ser baseada em um modelo ou
estilo de arquitetura especfico. Um estilo de arquitetura um padro de organizao
de sistema (Garlan e Shaw, 1993). Como uma organizao cliente-servidor ou uma
arquitetura em camadas.

O sistema possibilita ao cliente atualizar seus dados cadastrais

acessando o site na internet.

A organizao de um sistema requer uma estratgia bsica

utilizado para estrutur-lo e necessita-se tomar decises sobre o


modelo geral organizacional de um sistema com antecedncia no
processo de projetos de arquitetura.

A organizao do sistema pode refletir-se diretamente na

8
estrutura do subsistema. freqente que o modelo de subsistema
inclua mais detalhes que o modelo de organizao, nem sempre h
um mapeamento simples dos subsistemas para a estrutura
organizacional.
Arquitetura de sistemas distribudos -

Sabe-se

que

quase

todos os sistemas baseados em grandes computadores atualmente so sistemas


distribudos.

O desafio projetar o software e o hardware para fornecer os

recursos de sistema distribudo desejveis e ao mesmo tempo,


minimizar os problemas inerentes a esses sistemas.

Arquitetura cliente-servidor: funciona como um conjunto de

servios fornecidos aos clientes que fazem uso desses servios. De


modo que os servidores e clientes so tratados de maneira diferente
nesses sistemas.

Os clientes e servidores so processos separados, que um

modelo lgico de uma arquitetura cliente-servidor distribuda. A


arquitetura cliente-servidor mais simples chamada de arquitetura
cliente-servidor de duas camadas, na qual uma aplicao
organizada como um servidor ou vrios servidores idnticos e um
conjunto de clientes. As arquiteturas cliente-servidor podem ter duas
formas: modelo cliente-magro e modelo cliente-gordo.
Uma arquitetura cliente-magro de duas camadas a abordagem
mais simples a ser usada quando sistemas legados centralizados evoluem para uma
arquitetura cliente-servidor. A interface com o usurio desses sistemas migra para
PCs, e a aplicao em si atua como um servidor e cuida de todo o processamento
da aplicao de do gerenciamento de dados.
O

modelo

cliente-gordo

faz

uso

dessa

capacidade

de

processamento disponvel e distribui o processamento lgico de aplicao e a


apresentao ao cliente. O servidor essencialmente um servidor de transaes
que gerencia todas as transaes de banco de dados. Um exemplo desse tipo de
arquitetura so os sistemas de caixas eletrnicos de bancos, nos quais o caixa
eletrnico o cliente e o servidor um mainframe que realiza operaes sobre o
banco de dados de contas dos clientes.

9
Arquitetura de Aplicaes - Sistemas de aplicaes so criados
para atender algumas necessidades de negocio ou organizacionais. Todos os
negcios tm muito em comum, eles necessitam contratar pessoas, emitir faturas,
administrar as contas e outros. Um dos vrios modelos de aplicaes a aplicaes
de processamento de dados: que voltada a dados:

Elas processam dados em lotes sem intervenes explicitas do


usurio durante o processamento. As aes especficas tomadas
pela aplicao dependem dos dados que so processados.

Os sistemas de processamento em lotes so normalmente usados


em aplicaes de negcios nas quais as operaes similares so
realizadas sobre uma grande quantidade de dados.

Tratam de uma grande variedade de funes administrativas.


Escolhi

esse

tipo

de

sistema

especifico

pelo

fato

de

representarem a maioria dos sistemas em uso atualmente. Sistemas


de negcios so em geral sistemas de processamento de dados ou
transaes, e a maioria dos softwares de computadores pessoais
construda em torno de uma arquitetura de processamento de
eventos. Sistema de tempo real tambm conta com sistemas de
processamento de linguagem, como os compiladores.
Gerenciamento de configuraes - O plano de gerenciamento de
configuraes descreve os padres e procedimentos que devem ser usados para o
gerenciamento. o ponto de partida para o desenvolvimento do plano deve ser um
conjunto de padres de configurao, que deve ser adaptados para se atender aos
requisitos e as restries de cada projeto especifico.
Como se pode perceber pela especificao de requisitos para o sistema em
questo, no h grandes restries de desempenho e disponibilidade, ainda que algumas restries
tenham sido explicitamente apontadas. Assim, levando-se em considerao 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 tticas a serem aplicadas:
Usabilidade: o Separar a interface do restante da aplicao. O prover ao usurio a capacidade de
entrar com comandos que permitam operar o sistema de modo mais eficiente. Para tal, as
interfaces do sistema devem permitir, sempre que possvel, a entrada por meio de seleo ao invs
da digitao de campos como:

10
Manutenibilidade o Coerncia semntica: a organizao do sistema deve se
dar de modo que as responsabilidades em um mdulo trabalhem em conjunto sem depender
excessivamente de outros mdulos;
Uso de interfaces com ocultao de informaes especficas sobre a
implementao dos mdulos;
Uso de um intermedirio para isolar o mecanismo de persistncia de dados;
Uso de um intermedirio para tratar as requisies da interface.
Segurana: o Autenticar usurios usando login e senha;
Autorizar usurios, criando os seguintes grupos: (I) Gerente de Acervo acesso
s funcionalidades do controle de acervo; (II) Atendente acesso s funcionalidades de
atendimento a clientes; (III) Administrador acesso geral a todas as funcionalidades do sistema,
incluindo o cadastro de usurios. Limitar a exposio, disponibilizando pela Internet somente
funcionalidades de consulta ao acervo.
Manter uma trilha de auditoria para as operaes de atendimento ao cliente,
sempre registrando o atendente que efetuou uma locao ou devoluo (e, por conseguinte, um
pagamento).
Ainda que os demais atributos de qualidade no tenham sido considerados
como sendo condutores da arquitetura, algumas tticas foram aplicadas visando garantir o nvel de
atendimento requerido. A seguir, as tticas consideradas so listadas:
Desempenho: o Reduzir overhead computacional em situaes que no
comprometam a manutenibilidade. Estabelecer uma configurao de hardware mnima para
comportar o sistema.
Disponibilidade: uso de excees e transaes para deteco, tratamento e
preveno de falhas.
Portabilidade: uso da linguagem Java web e de bibliotecas e mecanismos de
persistncia capazes de rodar em qualquer navegador e sistemas operacionais Windows e Linux.

Os Procedimentos de gerenciamento de mudana dizem respeito a


analise de custo e beneficio das mudanas propostas, a provao das mudanas
viveis rastreabilidade de quais componentes do sistema foram alterados. O
processo de gerenciamento de mudanas deve surtir efeito quando o software ou a
documentao associada so colocados em baseline pela equipe de gerenciamento
de configuraes.

11

Sommerville, Ian. Engenharia de Software, 6 edio.

Os

processos envolvidos

no

gerenciamento

de

verses

preocupam-se com a identificao e a manuteno da rastreabilidade das verses


de um sistema. Uma verso de sistema uma instancia de sistema que diferem, de
alguma maneira, de outra instancias. Verses de sistema podem ter funcionalidades
distintas, desempenho aprimorado ou defeito de software reparado. Algumas
verses podem ser funcionalmente equivalentes, mais projetadas para diferentes
configuraes de hardware e software. Verses com somente pequenas diferenas
so as vezes chamadas de variantes.

3 DESAFIO 2 - BASEADO NO PMBOK

A Estrutura Analtica de Projetos ferramenta imprescindvel no


gerenciamento de projetos. A EAP rene, em um nico documento, aspectos de
Escopo, Tempo e Custo. No apenas rene, mas promove um melhor planejamento
desses aspectos.

12
Organograma do Projeto

O desenvolvimento da EAP a decomposio do trabalho


necessrio para a realizao de um projeto. O raciocnio simples, necessrio
dividir o projeto em pacote de trabalhos organizados de cima para baixo
hierarquicamente.
Vejamos o exemplo simplificado da construo de uma casa:

13
Os pacotes so decompostos at um nvel que permita um planejamento
mais preciso do trabalho:

Funo

Atribuio

Gerente de Projetos

Desenvolver o escopo e plano do gerenciamento do projeto.


Elaborar o prospecto de servios de procedimento de TI.
Gerenciar toda a execuo do projeto.

Analista de Sistemas

Analisar as rotinas de trabalho fazer as customizaes.


Desenvolver as novas rotinas para o sistema. Gerenciar a
equipe de programao e implantao.

Analista de Banco de Dados

Instalar e configurar banco de dados. Realizar testes e auxiliar


o Gerente de TI no planejamento do projeto.

Analista de Suporte

Gerenciar a equipe de implantao. Instalar o sistema,


parametrizar o sistema, realizar testes e treinamento de
usurios chaves. Auxiliar o Gerente de Projetos no
planejamento do projeto

Programador / Analista de
sistema

Desenvolvimento das rotinas, manuteno e customizao.

Tcnico de implantao

Auxiliar a instalao, parametrizao e realizao de teste no


sistema.

Deve - se estimar apenas os pacotes do ltimo nvel. O esforo necessrio para


desenvolver o trabalho no nvel acima ser dado pela soma dos esforos dos
pacotes que o compem:

E assim sucessivamente at o primeiro nvel da EAP, para que


possamos ter o esforo total necessrio para empreendimento do projeto:
Tarefa Custo Estimado
Sistema de Gerenciamento de Call Center SGC
1 Gerenciamento do Projeto
2 Desenvolver o termo de abertura do projeto

R$ 15.000,00
R$ 2.000,00

14
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

Reunio de partida da equipe


Identificar as partes interessadas
Coletar e documentar requisitos
Desenvolver a declarao do escopo do projeto
Desenvolver o plano de gerenciamento do projeto
Gesto de Recursos
Gesto de Tempo
Gesto da Qualidade
Gesto de Riscos
Gesto de Aplicaes
Gesto de Custo%
Aquisio de Equipamentos
Plano cie gerenciamento do projeto
Analise e Desenvolvimento
Analise de Sistemas
Analise das Rotinas atuais
Analise dos Documentos utilizados
Criar Relatrios de mudanas
Reunio para apresentao e aprovao das mudanas
Desenvolvimento
Reunio apresentao das mudanas pra equipe de desenvolvimento
1 Fase Desenvolvimento da customizao
Reunio de Apresentao 1 Fase
2 Fase Desenvolvimento da customizao
Fase de integrao do sistema
Testes do Sistema
Auditoria e finalizao do sistema
Instalao e adequao

Valor Total

R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 6.000,00
R$ 50.000,00

comum a diviso de um projeto em fases e essa anlise pode ser


transportada para a EAP. Um modelo bastante comum de EAP uma decomposio
de trs nveis. O nvel mais abrangente o projeto.
As fases do projeto compreendem o segundo nvel e os pacotes de trabalho o
terceiro nvel:

15
No existe limitao quanto aos nveis da EAP. Voc precisa
decompor o trabalho at um nvel que possa fazer uma boa avaliao dos esforos
necessrios para realiz-lo; todavia, uma EAP com muitos nveis pode acarretar
numa EAP de difcil leitura.

4 DESAFIO 3 - PROGRAMAO JAVA WEB

As tecnologias voltadas para o desenvolvimento de aplicaes WEB


tm mudado constantemente, como sabemos, inicialmente os sites possuam
apenas contedo esttico, ou seja, o contedo de uma pgina no podia ser
modificado em tempo de execuo. Depois, os sites passaram a oferecer pginas
com contedo dinmico e personalizado.
JSF (Java Serer Faces) a tecnologia Java para construo de pginas
dinmicas. Primefaces uma biblioteca de componentes para RIA Rich Internet
Application, o que torna os sistemas com uma interface mais amigvel para os
usurios. Hibernate um framework para o mapeamento objeto-relacional. Facilita o
mapeamento dos atributos entre um Banco de dados Relacional e o modelo de
objetos de uma aplicao.
A arquitetura Model-view-controller (MVC), em portugus modelo-visocontrolador, um padro de arquitetura de software que separa a representao da
informao da interao do usurio com ele. O modelo (model) consiste nos dados
da aplicao, regras de negcios, lgica e funes, define o comportamento do
sistema, implementando os Beans. Uma viso (view) pode ser qualquer sada de
representao dos dados, como uma tabela ou um diagrama, define a camada de
visualizao. possvel ter vrias vises do mesmo dado, como um grfico de
barras

para

gerenciamento

uma

viso

tabular

para

contadores.

O controlador (controller) faz a mediao da entrada, convertendo-a em comandos


para o modelo ou viso, define as regras de negcio da aplicao.
Projeto - Vamos criar um CRUD, para quem ainda no acostumou
com o termo Create (Criar), Read (Ler), Update (Alterar), Delete (Excluir) , iremos
implementar um cadastro de clientes. No desenvolvimento desse projeto vamos
utilizar o NetBeans 7 com suporte a JSF 2.0, Hibernate 3.6.4 Final, Primefaces 2.2.1

16
Final, para o banco de dados ser o MySql 5.
Vamos desenvolver um cadastro de clientes, para isso vamos utilizar o padro
MVC, esse modelo visa separa as classes de acordo com suas responsabilidades,
iremos criar pacotes chamados de: Model, View e Controller para visualizarmos com
mais facilidade o padro na prtica. A princpio nosso cliente ter as seguintes
informaes: nome, cpf ou cnpj, endereo, nmero, telefone, estado, cidade.
A tela final do trabalho ficara assim: ftp://sistema_sgc/

Janela Cliente:

17

Estrutura do sistema:

Aquivos de programao:

18

5 DESAFIO 4 - DIAGRAMAS DA UML

O tipo de arquitetura de sistema definido para o projeto o Cliente x


Servidor, onde:
Cliente interno: responsvel pela lgica bsica do aplicativo.
Cliente externo: responsvel pela interface com o usurio via
Internet (browser).
Servidor:

ser

um

servidor

Apache

responsvel

pelo

gerenciamento do acesso, por todas as funes relativas ao banco de dados e pelas


regras ou lgica do negcio. Nesse servidor ficaro executando a aplicao do
SGC e SGBD Sistema de Gerenciamento Call Center de Banco de Dados
(MySQL), que um banco de dados relacional gratuito, eficiente e otimizado para
aplicaes Web, multiplataforma, sendo compatvel com os sistemas operacionais
da famlia Windows e Linux e, tambm, com a linguagem de programao Java
utilizada na construo do sistema. A conexo entre a aplicao e o banco dados
ser feita atravs de uma interface ODBC (Open Database Connectivity) utilizada
para acesso de dados atravs de consultas SQL.
Dessa forma o projeto ser constitudo de duas camadas onde:
O papel da camada Cliente que ser composta de

Gerenciamento de apresentao:

Interao com o usurio

19

Entrada e consulta de dados

Lgica do aplicativo:

Funcionamento do aplicativo

Partes simples da lgica do negcio

Aplicativos de produtividade pessoal:

Processador de textos, planilha etc.

Navegador Web e Cliente de e-mail.

O papel da camada Servidor que ser composta de:

Atendimento a Usurios:

Comunicao e autenticao de usurios

Atendimento a solicitaes de clientes

Gerenciador de Banco de Dados:

Acesso e organizao de registros/dados

Seleo de registros/dados

Atualizao de registros/dados

Execuo de Regras do Negcio

Procedimentos armazenados no Banco de Dados

Processamento de Transaes

Conjuntos de operaes relacionadas aos processos de


negcio.

Diagrama de classe

20

Diagrama de classe de Domnio

Gerao de Modelo fsico Sql


CREATE TABLE Gerncia (
cod_func Numero(6),
codclient Numero(10),
FOREIGN KEY(cod_func) REFERENCES Funcionrio (cod_func),
FOREIGN KEY(codclient) REFERENCES Cliente (codclient)
)
CREATE TABLE Cliente (
codclient Numero(10) PRIMARY KEY,
nclient Texto(60),
ruaclient Texto(60),
numero Texto(15),

21
telclient Numero(13),
cpfclient Numero(11),
cnh Texto(20),
rgclient Texto(15)
)
CREATE TABLE Atendimento (
protocolo Numero(12),
codclient Numero(10),
Agendaclient Texto(60),
atendclient Texto(40),
servio Texto(60),
datainicio Numero(8),
datafinal Numero(8),
FOREIGN KEY(codclient) REFERENCES Cliente (codclient)
)
CREATE TABLE Funcionrio (
cod_func Numero(6) PRIMARY KEY,
nomefunc Texto(60),
cargo Texto(50),
setorfunc Texto(50)
)
ALTER TABLE Gerncia ADD FOREIGN KEY(codclient) REFERENCES Cliente
(codclient)
ALTER TABLE Atendimento ADD FOREIGN KEY(protocol) REFERENCES
Agenda Cliente (cod_bug)
Classes persistentes (ORM).

Diagrama de componentes

22

Diagrama de pacotes

23

CONSIDERAES FINAIS

Este

trabalho

proporcionou

uma

reflexo

no

processo

de

desenvolvimento de software diante do desenvolvimento do projeto de software e a


sua

importncia na administrao das informaes, tambm para assimilar

processo de aprendizagem em todas as etapas do Desenvolvimento de Sistemas de


Informao, evidente que se faz necessrio organizao e administrao no
processo de desenvolvimento de sistema para que os resultado tenham qualidade e
eficincia para o efeito desejado. Tambm sabemos que nos dias atuais
impensvel desenvolver uma aplicao sendo ela para qualquer plataforma sem
pensar nos item essencial para segurana e requisitos, tambem nas estrutura de
documentao e regulamentaes. O PMBOK e a UML e requisitos para a java
Web para uma aplicao funcionar de forma adequada. Abordar a viabilizao do
desenvolvimento de sistema de informao analisado, incrementar o conhecimento
em engenharia de software, gesto de projetos e programao para Web.

REFERNCIAS

ALENCAR, A. J., SCHMITZ, E. A., Anlise de Risco em Gerncia de Projetos. Rio


de Janeiro, Editora Brasport, 2006.
GAMMA, Erich et al. Padres de Projeto: Solues reutilizveis de software
Orientado a Objetos. Porto Alegre: Bookman, 2000.
GONALVES, Edson. Desenvolvendo aplicaes web com JSP, Servlet, Java
Server Faces, Hibernate, EJB3 persistence, jax. Rio de Janeiro: Cincia
Moderna, 2007.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 6 Edio. So Paulo: Pearson
Addison Wesley, 2005.
_______________. ENGENHARIA DE SOFTWARE. 8 Edio. So Paulo: Pearson
Addison Wesley, 2007.

24
SHIP, H. M. L. Tapestry In Action. Greenwich: Manning, 2004.
TIOBE.
TIOBE
Programming
Community
Index.
Disponvel
em:
<http://www.tiobe .com/index.php/content/paperinfo/tpci/index.html>. Acesso em 05
de Abril de 2015.
ZIMBRO, Geraldo. Mapeamento Objeto-Relacional Transforme um Modelo de
Classes em um Modelo Relacional. Revista SQL Magazine, Rio de Janeiro: Neofcio
Editora v.5, ano 1, p.28-33, Edio 5, 2003.
TIOBE.
TIOBE
Programming
Community
Index.
Disponvel
em:
<http://www.tiobe .com/index.php/content/paperinfo/tpci/index.html>. Acesso em 05
de Abril de 2015.

25

Anda mungkin juga menyukai