portifolio grupo 5º semestre ads

7/17/2019 Portifolio Grupo 5º Semestre ADS

http://slidepdf.com/reader/full/portifolio-grupo-5o-semestre-ads 1/25

SISTEMA DE ENSINO PRESENCIAL CONECTADOANALISE E DESENVOLVIMENTO DE SISTEMAS

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ATIVIDADE INTERDICIPLINAR DE GRUPO

Ariquemes2015



XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

ATIVIDADE INTERDICIPLINAR DE GRUPO

Trabalho apresentado ao Curso Tecnologia Em Análise EDesenvolvimento De istemas da !"#$A% &!niversidade "orte do $araná' para as disciplinas(

$ro)eto #rientado a #b)etos' Engenharia e $ro)eto deo*t+are e $rograma,-o para .eb //

#rientador( $ro* árcio %oberto Chiaveli' uis Claudio$erini' arco /3uro 4isatomi e eronice de 6reitas

Ariquemes

2015



SUMÁRIO

1 INTRODUÇÂO.......................................................................................................5

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

3 DESAFIO 2 - BASEADO NO PMBOK................................................................124 DESAFIO 3 - PROGRAMAÇÃO JAVA WEB......................................................16

5 DESAFIO - DIAGRAMAS DA UML..................................................................1!

CONSIDERAÇ"ES FINAIS........................................................................................23

REFER#NCIAS...........................................................................................................23



7

1 INTRODUÇÂO

A produ,-o te8tual interdisciplinar grupo tem como base os assuntos

abordados no ei8o temático' envolvendo todas as disciplinas do semestre "estesemestre 9 dada continuidade em alguns temas tratados no semestre anterior' al9m

de abordar a viabili:a,-o do desenvolvimento de sistema de in*orma,-o analisado'

incrementar o conhecimento em engenharia de software' gest-o de pro)etos e

programa,-o para Web. Ao pro)etar uma arquitetura de sistemas' voc; precisa

decidir o que seu sistema e classes mais amplas de aplica,-o tem em comum' e

decidir quanto conhecimento dessas arquiteturas de aplica,-o voc; pode reusar #

principal problema 9 que ele necessita ser um *ormato comum para trans*erir dadosque possa ser reconhecido por todas as trans*orma,<es 4o)e' uma empresa' com

em um ambiente tecnologicamente preparado torna&se mais competitiva no cenário

atual' se di*erenciando dos demais e atendendo seus clientes com e8cel;ncia Cada

ve: mais as empresas buscam alternativas para *acilitar o gerenciamento de suas

atividades' visando aumentar o controle e obter in*orma,<es precisas que possam

de *ato agili:ar a tomada de decis<es e' consequentemente' melhorar o n=vel de

servi,o prestado



5

2 DESAFIO 1 - PROPOSTA DE PROJETO

# P$%&'(% )' *$+,('(,$* tem por decis-o estabelecer uma

organi:a,-o de sistema que satis*a,a os requisitos *uncionais e n-o *uncionais do

sistema Durante o processo de pro)eto de arquitetura' os arquitetos de sistema

precis-o tomar uma s9rie de decis<es *undamentais que a*etam pro*undamente o

sistema e o seu processo de desenvolvimento # istema de >erenciamento de Call

Center & >C' otimi:a todas as atividades operacionais e administrativas dentro do

processo de atendimento ao cliente incluindo todo o *lu8o de opera,<es dentro do

servi,os prestados pela empresa # >C operacional signi*ica que a empresa

depende menos da e8peri;ncia das pessoas' uma ve: que o sistema temintelig;ncia e seguem padroes e cronograma para solucionar problemas no

atemdimento ao clienteA utili:a,-o de um sistema >C 9 *undamental para o bom

*uncionamento operacional com qualidade no controle de solu,<es de problemas do

clinte sendo assim processado todos os protocolo de atendimento

Embora cada sistema de so*t+are se)a ?nico' pode ocorrer de ter

dom=nio de aplica,-o de arquitetura similares que re*letem os conceitos

*undamentais de dom=nio• 6oco no Cliente

• ideran,a

• Envolvimento das $essoas

• Apro8ima,-o dos $rocessos

• istema de Apro8ima,-o com a >er;ncia

• elhoria Cont=nuaApro8ima,-o Casual para

Tomada de Decis-o

• %elacionamento utuamente @en9*ico com

6ornecedor

Essa arquitetura de aplica,-o pode ser bastante gen9rica como

a arquitetura de sistemas de gerenciamento de in*orma,<es' ou muito mais

espec=*icas

• 6inalidade



A *inalidade do Plano de Desenvolvimento de Software 9 reunir

todas as in*orma,<es necessárias para controlar e gerenciar o protBtipo de pro)eto

de >erenciamento de "avega,-o e Controle >"C Ele descreve a abordagem

dada ao desenvolvimento do so*t+are e 9 o plano de n=vel mais alto gerado e usado

pelos gerentes para coordenar o es*or,o de desenvolvimento

# Plano de Desenvolvimento de Software 9 usado por estas

pessoas(

# gerente de pro)eto utili:a&o para plane)ar o cronograma do pro)eto

e as necessidades de recursos e para acompanhar o andamento do pro)eto em

rela,-o ao cronograma

embros da equipe do pro)eto utili:am&no para entender o que

precisam *a:er' quando precisam *a:;&lo e quais s-o as outras atividades das quaiseles dependem

• Escopo

Este Plano de Desenvolvimento de Software descreve o plano geral

a ser usado pelo protBtipo de pro)eto >"C incluindo a implanta,-o do produto Este

pro)eto re?ne e sinteti:a as seguintes !nidades de o*t+ares( $CDs $lata*orma

de Coleta de Dados #s detalhes de itera,<es individuais ser-o descritos nos $lanos

de /tera,-o #s planos' con*orme especi*icado neste documento' baseiam&se nosrequisitos do produto de*inidos no Documento de Visão

Este Plano de Desenvolvimento de Software cont9m as seguintes

in*orma,<es(

is-o >eral do $ro)eto apresenta uma descri,-o da *inalidade' doescopo e dos ob)etivos do pro)eto Tamb9m de*ine os produtos que se espera que opro)eto libere

#rgani:a,-o do $ro)eto descreve a estrutura organi:acional da

equipe do pro)eto$rocesso de >erenciamento e8plica o custo estimado e o

cronograma' de*ine os principais marcos e *ases do pro)eto e descreve como opro)eto será monitorado

$lanos e Diretri:es aplicáveis apresentam uma vis-o geral doprocesso de desenvolvimento do so*t+are' abrangendo m9todos' *erramentas et9cnicas a serem seguidos

>erenciamento de %equisitos

#s requisitos desse sistema s-o capturados no Documento de

is-o As mudan,as solicitadas nos requisitos s-o capturadas nas olicita,<es deudan,a e s-o aprovadas como parte do processo de >erenciamento deCon*igura,-o



F

Controle de Cronograma e #r,amento

As despesas s-o monitoradas pelo gerente de pro)eto' e reportadase avaliadas mensalmente GConsulte %elatBrios e 9tricas abai8oH

# gerente de pro)eto mant9m uma programa,-o mostrando a dataesperada de cada marco #s itens de linha na programa,-o incluem pacotes de

trabalho atribu=dos a pessoas Cada pessoa a quem 9 atribu=do um pacote detrabalho *ornece ao gerente do pro)eto in*orma,<es sobre o percentual de conclus-odas tare*as semanalmente As mudan,as na programa,-o *icar-o a cargo dospatrocinadores do pro)eto' que decidir-o se o escopo será alterado a *im depreservar as datas&alvo de conclus-o

Controle de Iualidade

#s de*eitos ser-o registrados e monitorados como olicita,<es deudan,a' e as m9tricas de de*eito ser-o coletadas Gconsulte %elatBrios e 9tricasabai8oH

erá necessário que todos os produtos liberados se)am submetidosao processo de revis-o adequado' con*orme está descrito no Caso deDesenvolvimento A revis-o 9 necessária para assegurar que cada produto liberadose)a de qualidade aceitável' usando as orienta,<es descritas nos pontos deveri*ica,-o e nas diretri:es de revis-o do %!$ para $ro)etos $equenos

Todos os de*eitos encontrados durante a revis-o que n-o *oremcorrigidos antes da libera,-o para integra,-o dever-o ser capturados comoolicita,<es de udan,a para que n-o se)am esquecidos

!m e8emplo disso s-o as linhas de produtos de aplica,<es que s-o

criadas com base em um n?cleo de arquitetura com varia,<es que satis*a:em os

requisitos espec=*icos do cliente

Ao se pro)etar uma arquitetura de sistema' necessita&se decidir o

que seu sistema e classes mais amplas de aplica,-o t;m em comum' e decidir

quanto conhecimento dessas arquiteturas de aplica,-o pode&se reusar

A arquitetura de um sistema de so*t+are pode ser baseada em um modelo ou

estilo de arquitetura espec=*ico !m estilo de arquitetura 9 um padr-o de organi:a,-o

de sistema G>arlan e ha+' 1JJKH Como uma organi:a,-o cliente&servidor ou uma

arquitetura em camadas

• # sistema possibilita ao cliente atuali:ar seus dados cadastrais

acessando o site na internet

• A organi:a,-o de um sistema requer uma estrat9gia básica

utili:ado para estruturá&lo e necessita&se tomar decis<es sobre o

modelo geral organi:acional de um sistema com anteced;ncia no

processo de pro)etos de arquitetura

• A organi:a,-o do sistema pode re*letir&se diretamente na



L

estrutura do subsistema M *reqNente que o modelo de subsistema

inclua mais detalhes que o modelo de organi:a,-o' nem sempre há

um mapeamento simples dos subsistemas para a estrutura

organi:acional

A$+,('(,$* )' ('/* )($0,)% - abe&se que quase

todos os sistemas baseados em grandes computadores atualmente s-o sistemas

distribu=dos

• # desa*io 9 pro)etar o so*t+are e o hard+are para *ornecer os

recursos de sistema distribu=do dese)áveis e ao mesmo tempo'

minimi:ar os problemas inerentes a esses sistemas

• Arquitetura cliente-servidor: *unciona como um con)unto de

servi,os *ornecidos aos clientes que *a:em uso desses servi,os De

modo que os servidores e clientes s-o tratados de maneira di*erente

nesses sistemas

• #s clientes e servidores s-o processos separados' que 9 um

modelo lBgico de uma arquitetura cliente&servidor distribu=da A

arquitetura cliente&servidor mais simples 9 chamada de arquitetura

cliente&servidor de duas camadas' na qual uma aplica,-o 9

organi:ada como um servidor ou vários servidores id;nticos e um

con)unto de clientes As arquiteturas cliente&servidor podem ter duas

*ormas( modelo cliente&magro e modelo cliente&gordo

!ma arquitetura cliente&magro de duas camadas 9 a abordagem

mais simples a ser usada quando sistemas legados centrali:ados evoluem para uma

arquitetura cliente&servidor A inter*ace com o usuário desses sistemas migra para

$Cs' e a aplica,-o em si atua como um servidor e cuida de todo o processamento

da aplica,-o de do gerenciamento de dados

# modelo cliente&gordo *a: uso dessa capacidade de

processamento dispon=vel e distribui o processamento lBgico de aplica,-o e a

apresenta,-o ao cliente # servidor 9 essencialmente um servidor de transa,<es

que gerencia todas as transa,<es de banco de dados !m e8emplo desse tipo de

arquitetura s-o os sistemas de cai8as eletrOnicos de bancos' nos quais o cai8a

eletrOnico 9 o cliente e o servidor 9 um main*rame que reali:a opera,<es sobre o

banco de dados de contas dos clientes



J

A$+,('(,$* )' A4*' - istemas de aplica,<es s-o criados

para atender algumas necessidades de negocio ou organi:acionais Todos os

negBcios t;m muito em comum' eles necessitam contratar pessoas' emitir *aturas'

administrar as contas e outros !m dos vários modelos de aplica,<es 9 a aplica,<es

de processamento de dados( que 9 voltada a dados(

• Elas processam dados em lotes sem interven,<es e8plicitas do

usuário durante o processamento As a,<es espec=*icas tomadas

pela aplica,-o dependem dos dados que s-o processados

• #s sistemas de processamento em lotes s-o normalmente usados

em aplica,<es de negBcios nas quais as opera,<es similares s-o

reali:adas sobre uma grande quantidade de dados• Tratam de uma grande variedade de *un,<es administrativas

Escolhi esse tipo de sistema especi*ico pelo *ato de

representarem a maioria dos sistemas em uso atualmente istemas

de negBcios s-o em geral sistemas de processamento de dados ou

transa,<es' e a maioria dos so*t+ares de computadores pessoais 9

constru=da em torno de uma arquitetura de processamento de

eventos istema de tempo real tamb9m conta com sistemas de

processamento de linguagem' como os compiladores

G'$'74*/'7(% )' 4%789,$*' - # plano de gerenciamento de

con*igura,<es descreve os padr<es e procedimentos que devem ser usados para o

gerenciamento o ponto de partida para o desenvolvimento do plano deve ser um

con)unto de padr<es de con*igura,-o' que deve ser adaptados para se atender aos

requisitos e as restri,<es de cada pro)eto especi*ico

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, ainda que algumas restrições

tenham sido explicitamente apontadas. 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 untamente com as táticas a serem aplicadas!

"sabilidade! o #eparar a interface do restante da aplicação. O prover ao usuário a capacidade de

entrar com comandos que permitam operar o sistema de modo mais eficiente. $ara tal, as

interfaces do sistema devem permitir, sempre que poss%vel, a entrada por meio de seleção ao inv&s

da digitação de campos como!



10

'anutenibilidade o Coer(ncia sem)ntica! a organi*ação do sistema deve se

dar de modo que as responsabilidades em um m+dulo trabalhem em conunto sem depender

excessivamente de outros m+dulos

Uso de interfaces com ocultação de informações espec%ficas sobre a

implementação dos m+dulos

Uso de um intermediário para isolar o mecanismo de persist(ncia de dados

Uso de um intermediário para tratar as requisições da interface.

#egurança! o Autenticar usuários usando login e senha

Autori*ar usuários, criando os seguintes grupos! / 0erente de Acervo 1 acesso

2s funcionalidades do controle de acervo / Atendente 1 acesso 2s funcionalidades de

atendimento a clientes / Administrador 1 acesso geral a todas as funcionalidades do sistema,

incluindo o cadastro de usuários. 3imitar a exposição, disponibili*ando pela nternet somente

funcionalidades de consulta ao acervo.

Manter uma trilha de auditoria para as operações de atendimento ao cliente,

sempre registrando o atendente que efetuou uma locação ou devolução e, por conseguinte, um

pagamento/.

Ainda que os demais atributos de qualidade não tenham sido considerados

como sendo condutores da arquitetura, algumas táticas foram aplicadas visando garantir o n%vel de

atendimento requerido. A seguir, as táticas consideradas são listadas!

4esempenho! o 5edu*ir overhead computacional em situações que não

comprometam a manutenibilidade. Estabelecer uma configuração de hard6are m%nima para

comportar o sistema.

4isponibilidade! uso de exceções e transações para detecção, tratamento e

prevenção de falhas.

$ortabilidade! uso da linguagem 7ava 6eb e de bibliotecas e mecanismos de

persist(ncia capa*es de rodar em qualquer navegador e sistemas operacionais 8indo6s e 3inux.

#s $rocedimentos de gerenciamento de mudan,a di:em respeito aanalise de custo e bene*icio das mudan,as propostas' a prova,-o das mudan,as

viáveis rastreabilidade de quais componentes do sistema *oram alterados #

processo de gerenciamento de mudan,as deve surtir e*eito quando o so*t+are ou a

documenta,-o associada s-o colocados em baseline pela equipe de gerenciamento

de con*igura,<es



11

Sommerville, Ian. Engenharia de Software, 6ª edição.

#s processos envolvidos no gerenciamento de vers<es

preocupam&se com a identi*ica,-o e a manuten,-o da rastreabilidade das vers<es

de um sistema !ma vers-o de sistema 9 uma instancia de sistema que di*erem' de

alguma maneira' de outra instancias ers<es de sistema podem ter *uncionalidades

distintas' desempenho aprimorado ou de*eito de so*t+are reparado Algumas

vers<es podem ser *uncionalmente equivalentes' mais pro)etadas para di*erentescon*igura,<es de hard+are e so*t+are ers<es com somente pequenas di*eren,as

s-o as ve:es chamadas de variantes

3 DESAFIO 2 - BASEADO NO PMBOK

A E($,(,$* A7*(4* )' P$%&'(% 9 *erramenta imprescind=vel no

gerenciamento de pro)etos A EA$ re?ne' em um ?nico documento' aspectos de

Escopo' Tempo e Custo "-o apenas re?ne' mas promove um melhor plane)amento

desses aspectos



12

Organograma do Projeto

# desenvolvimento da EA$ 9 a decomposi,-o do trabalho

necessário para a reali:a,-o de um pro)eto # racioc=nio 9 simples' 9 necessário

dividir o pro)eto em pacote de trabalhos organi:ados de cima para bai8o

hierarquicamente

e)amos o e8emplo simpli*icado da constru,-o de uma casa(



1K

#s pacotes s-o decompostos at9 um n=vel que permita um plane)amento

mais preciso do trabalho(

9unção Atribuição

0erente de $roetos 4esenvolver o escopo e plano do gerenciamento do proeto.

:laborar o prospecto de serviços de procedimento de ;.

0erenciar toda a execução do proeto.

Analista de #istemas Analisar as rotinas de trabalho fa*er as customi*ações.

4esenvolver as novas rotinas para o sistema. 0erenciar a

equipe de programação e implantação.

Analista de <anco de 4ados nstalar e configurar banco de dados. 5eali*ar testes e auxiliar

o 0erente de ; no planeamento do proeto.

Analista de #uporte 0erenciar a equipe de implantação. nstalar o sistema,

parametri*ar o sistema, reali*ar testes e treinamento de

usuários chaves. Auxiliar o 0erente de $roetos no

planeamento do proeto

$rogramador = Analista de

sistema

4esenvolvimento das rotinas, manutenção e customi*ação.

;&cnico de implantação Auxiliar a instalação, parametri*ação e reali*ação de teste no

sistema.

Deve & se estimar apenas os pacotes do ?ltimo n=vel # es*or,o necessário para

desenvolver o trabalho no n=vel acima será dado pela soma dos es*or,os dos

pacotes que o comp<em(

E assim sucessivamente at9 o primeiro n=vel da EA$' para que

possamos ter o es*or,o total necessário para empreendimento do pro)eto(

Tare*a Custo Estimado

istema de >erenciamento de Call Center >C1 >erenciamento do $ro)eto R$ 15.000,00

2 Desenvolver o termo de abertura do pro)eto R$ 2.000,00



17

3 %euni-o de partida da equipe R$ 1.000,00

4 /denti*icar as partes interessadas R$ 1.000,00

5 Coletar e documentar requisitos R$ 1.000,00

6 Desenvolver a declara,-o do escopo do pro)eto R$ 1.000,00

7 Desenvolver o plano de gerenciamento do pro)eto R$ 1.000,00

8 >est-o de %ecursos R$ 1.000,009 >est-o de Tempo R$ 1.000,00

10 >est-o da Iualidade R$ 1.000,00

11 >est-o de %iscos R$ 1.000,00

12 >est-o de Aplica,<es R$ 1.000,00

13 >est-o de CustoP R$ 1.000,00

14 Aquisi,-o de Equipamentos R$ 1.000,00

15 $lano cie gerenciamento do pro)eto R$ 1.000,00

16 Analise e Desenvolvimento R$ 1.000,00

17 Analise de istemas R$ 1.000,00

18 Analise das %otinas atuais R$ 1.000,0019 Analise dos Documentos utili:ados R$ 1.000,00

20 Criar %elatBrios de mudan,as R$ 1.000,00

21 %euni-o para apresenta,-o e aprova,-o das mudan,as R$ 1.000,00

22 Desenvolvimento R$ 1.000,00

23 %euni-o apresenta,-o das mudan,as pra equipe de desenvolvimento R$ 1.000,00

24 1Q 6ase Desenvolvimento da customi:a,-o R$ 1.000,00

25 %euni-o de Apresenta,-o 1Q 6ase R$ 1.000,00

26 2Q 6ase Desenvolvimento da customi:a,-o R$ 1.000,00

27 6ase de integra,-o do sistema R$ 1.000,00

28 Testes do istema R$ 1.000,0029 Auditoria e *inali:a,-o do sistema R$ 1.000,00

30 /nstala,-o e adequa,-o R$ 6.000,00

31 Valor Total R$ 50.000,00

M comum a divis-o de um pro)eto em *ases e essa análise pode ser

transportada para a EA$ !m modelo bastante comum de EA$ 9 uma decomposi,-o

de tr;s n=veis # n=vel mais abrangente 9 o pro)eto

As *ases do pro)eto compreendem o segundo n=vel e os pacotes de trabalho o

terceiro n=vel(



15

"-o e8iste limita,-o quanto aos n=veis da EA$ oc; precisa

decompor o trabalho at9 um n=vel que possa *a:er uma boa avalia,-o dos es*or,os

necessários para reali:á&loR todavia' uma EA$ com muitos n=veis pode acarretar

numa EA$ de di*=cil leitura

4 DESAFIO 3 - PROGRAMAÇÃO JAVA WEB

As tecnologias voltadas para o desenvolvimento de aplica,<es .E@

t;m mudado constantemente' como sabemos' inicialmente os sites possu=amapenas conte?do estático' ou se)a' o conte?do de uma página n-o podia ser

modi*icado em tempo de e8ecu,-o Depois' os sites passaram a o*erecer páginas

com conte?do dinSmico e personali:ado

6 Gava erer 6acesH 9 a tecnologia ava para constru,-o de páginas

dinSmicas $rime*aces 9 uma biblioteca de componentes para %/A %ich /nternet

Application' o que torna os sistemas com uma inter*ace mais amigável para os

usuários 4ibernate 9 um *rame+or3 para o mapeamento ob)eto&relacional 6acilita o

mapeamento dos atributos entre um @anco de dados %elacional e o modelo de

ob)etos de uma aplica,-o

A arquitetura Model-view-controller GCH' em portugu;s modelo&vis-o&

controlador' 9 um padr-o de arquitetura de so*t+are que separa a representa,-o da

in*orma,-o da intera,-o do usuário com ele # modelo Gmodel H consiste nos dados

da aplica,-o' regras de negBcios' lBgica e *un,<es' de*ine o comportamento do

sistema' implementando os @eans !ma vis-o Gview H pode ser qualquer sa=da de

representa,-o dos dados' como uma tabela ou um diagrama' de*ine a camada de

visuali:a,-o M poss=vel ter várias vis<es do mesmo dado' como um grá*ico de

barras para gerenciamento e uma vis-o tabular para contadores

# controlador GcontrollerH *a: a media,-o da entrada' convertendo&a em comandos

para o modelo ou vis-o' de*ine as regras de negBcio da aplica,-o

$ro)eto & amos criar um C%!D' para quem ainda n-o acostumou

com o termo UCreate GCriarH' %ead GerH' !pdate GAlterarH' Delete GE8cluirH V' iremos

implementar um cadastro de clientes "o desenvolvimento desse pro)eto vamos

utili:ar o "et@eans F com suporte a 6 20' 4ibernate K7 6inal' $rime*aces 221



1

6inal' para o banco de dados será o Wql 5

amos desenvolver um cadastro de clientes' para isso vamos utili:ar o padr-o

C' esse modelo visa separa as classes de acordo com suas responsabilidades'

iremos criar pacotes chamados de( odel' ie+ e Controller para visuali:armos com

mais *acilidade o padr-o na prática A princ=pio nosso cliente terá as seguintes

in*orma,<es( nome' cp* ou cnp)' endere,o' n?mero' tele*one' estado' cidade

A tela *inal do trabalho *icara assim( *tp(sistemaYsgc

anela Cliente(



1F

Estrutura do sistema(

Aquivos de programa,-o(



1L

5 DESAFIO - DIAGRAMAS DA UML

# tipo de arquitetura de sistema de*inido para o pro)eto 9 o C'7(' :

S'$;)%$ ' onde(

C'7(' 7('$7%( responsável pela lBgica básica do aplicativo

C'7(' ':('$7%( responsável pela inter*ace com o usuário via/nternet Gbro+serH

S'$;)%$ ( será um servidor Apache o responsável pelo

gerenciamento do acesso' por todas as *un,<es relativas ao banco de dados e pelas

UregrasV ou UlBgicaV do negBcio "esse servidor *icar-o e8ecutando a aplica,-o do

>C e >@D istema de >erenciamento Call Center de @anco de Dados

GWIH' que 9 um banco de dados relacional gratuito' e*iciente e otimi:ado para

aplica,<es .eb' multiplata*orma' sendo compat=vel com os sistemas operacionais

da *am=lia .indo+s e inu8 e' tamb9m' com a linguagem de programa,-o ava

utili:ada na constru,-o do sistema A cone8-o entre a aplica,-o e o banco dados

será *eita atrav9s de uma inter*ace #D@C GOen Database !onnectivit" H utili:ada

para acesso de dados atrav9s de consultas I

Dessa *orma o pro)eto será constitu=do de duas camadas onde(

# papel da camada UClienteV que será composta de

• >erenciamento de apresenta,-o(

• /ntera,-o com o usuário



1J

• Entrada e consulta de dados

• Bgica do aplicativo(

• 6uncionamento do aplicativo

• $artes simples da lBgica do negBcio

• Aplicativos de produtividade pessoal(

• $rocessador de te8tos' planilha etc

• #ave$ador Web e Cliente de e&mail

• # papel da camada UervidorV que será composta de(

• Atendimento a !suários(

• Comunica,-o e autentica,-o de usuários

• Atendimento a solicita,<es de clientes

• >erenciador de @anco de Dados(

• Acesso e organi:a,-o de registrosdados

• ele,-o de registrosdados

• Atuali:a,-o de registrosdados

• E8ecu,-o de %egras do "egBcio

• $rocedimentos arma:enados no @anco de Dados

• $rocessamento de Transa,<es

• Con)untos de opera,<es relacionadas aos processos de

negBcio

Diagrama de classe



20

Diagrama de classe de Dom=nio

Geração de Modelo físico – Sql

CREATE TABLE G'$<74* =4%)>8,74 N,/'$%=6?@4%)4'7( N,/'$%=1?@FOREIGN KE=4%)>8,74? REFERENCES F,74%7$% =4%)>8,74?@FOREIGN KE=4%)4'7(? REFERENCES C'7(' =4%)4'7(??CREATE TABLE C'7(' =4%)4'7( N,/'$%=1? PRIMAR KE@

74'7( T':(%=6?@$,*4'7( T':(%=6?@7,/'$% T':(%=15?@



21

('4'7( N,/'$%=13?@484'7( N,/'$%=11?@47 T':(%=2?@$94'7( T':(%=15??CREATE TABLE A('7)/'7(% =$%(%4%% N,/'$%=12?@4%)4'7( N,/'$%=1?@A9'7)*4'7( T':(%=6?@*('7)4'7( T':(%=?@'$;% T':(%=6?@)*(*74% N,/'$%=!?@)*(*87* N,/'$%=!?@FOREIGN KE=4%)4'7(? REFERENCES C'7(' =4%)4'7(??CREATE TABLE F,74%7$% =

4%)>8,74 N,/'$%=6? PRIMAR KE@7%/'8,74 T':(%=6?@4*$9% T':(%=5?@'(%$8,74 T':(%=5??ALTER TABLE G'$<74* ADD FOREIGN KE=4%)4'7(? REFERENCES C'7('=4%)4'7(?ALTER TABLE A('7)/'7(% ADD FOREIGN KE=$%(%4%? REFERENCES A9'7)* C'7(' =4%)>0,9?

Classes persistentes G#%H

Diagrama de componentes



22

Diagrama de pacotes



2K

CONSIDERAÇ"ES FINAIS

Este trabalho proporcionou uma re*le8-o no processo de

desenvolvimento de so*t+are diante do desenvolvimento do pro)eto de so*t+are e a

sua importSncia na administra,-o das in*orma,<es' tamb9m para assimilar

processo de aprendi:agem em todas as etapas do Desenvolvimento de istemas de

/n*orma,-o' evidente que se *a: necessário Z organi:a,-o e administra,-o no

processo de desenvolvimento de sistema para que os resultado tenham qualidade e

e*ici;ncia para o e*eito dese)ado Tamb9m sabemos que nos dias atuais 9

impensável desenvolver uma aplica,-o sendo ela para qualquer plata*orma sem

pensar nos item essencial para seguran,a e requisitos' tambem nas estrutura dedocumenta,-o e regulamenta,<es # $@#[ e a ! e requisitos para a )ava

.eb 9 para uma aplica,-o *uncionar de *orma adequada Abordar a viabili:a,-o do

desenvolvimento de sistema de in*orma,-o analisado' incrementar o conhecimento

em engenharia de software' gest-o de pro)etos e programa,-o para Web.

REFER#NCIAS

AE"CA%' A ' C4/T\' E A' A7' )' R4% '/ G'$<74* )' P$%&'(%. %iode aneiro' Editora @rasport' 200

>AA' Erich et al Padrões de Projeto Solu%&es reutili'(veis de softwareOrientado a Ob)etos. $orto Alegre( @oo3man' 2000

>#"]AE' Edson !ese"#ol#e"do a$licações %e& co' (SP) Ser#let) (a#aSer#er *aces) +i&er"ate) E(B3 $ersiste"ce) ,ja-. %io de aneiro( Ci;nciaoderna' 200F

#E%/E' /an ENGENARIA DE SOFTARE Edi,-o -o $aulo( $earson Addison .esleW' 2005

YYYYYYYYYYYYYYY ENGENARIA DE SOFTARE L Edi,-o -o $aulo( $earson Addison .esleW' 200F



27

4/$' 4 T*'($ I7 A4(%7 >reen+ich( anning' 2007

T/#@E TIOBE P$%9$*//79 C%//,7( I7)': Dispon=vel em(^http(+++tiobe cominde8phpcontentpaperin*otpciinde8html_ Acesso em 05de Abril de 2015

\/@%`#' >eraldo M*'*/'7(% O0&'(%-R'*4%7* H Trans*orme um odelo deClasses em um odelo %elacional %evista I aga:ine' %io de aneiro( "eo*=cioEditora v5' ano 1' p2L&KK' Edi,-o 5' 200K

T/#@E TIOBE P$%9$*//79 C%//,7( I7)': Dispon=vel em(^http(+++tiobe cominde8phpcontentpaperin*otpciinde8html_ Acesso em 05de Abril de 2015



25

portifolio grupo 5º semestre ads

Documents