TADS Cliente Servidor WEB

1
PROF. JOS MRIO COSTA JUNIOR
PROJETO CLIENTE SERVIDOR
VITRIA 2010
Projeto Cliente Servidor
Governo Federal Ministro de Educao Fernando Haddad Ifes Instituto Federal do Esprito Santo Reitor Denio Rebello Arantes Pr-Reitora de Ensino Cristiane Tenan Schlittler dos Santos Diretora do CEAD Centro de Educao a Distncia Yvina Pavan Baldo Coordenadoras da UAB Universidade Aberta do Brasil Yvina Pavan Baldo Maria das Graas Zamborlini
Curso de Tecnologia em Anlise e Desenvolvimento de Sistemas Coordenao de Curso Andromeda Goretti Correa de Menezes Designer Instrucional Jos Mrio Costa Junior Professor Especialista/Autor Jos Mrio Costa Junior
Catalogao da fonte: Rogria Gomes Belchior - CRB 12/417 C837p Costa Junior, Jos Mrio Projeto cliente servidor. / Jos Mrio Costa Junior. Vitria: Ifes, 2009. 93 p. : il. 1. Cliente/Servidor (Computadores). 2. Banco de dados. 3. Software -Desenvolvimento. 4. Arquitetura de computador. I. Instituto Federal do Esprito Santo. II. Ttulo. CDD 004.36
DIREITOS RESERVADOS Ifes Instituto Federal do Esprito Santo Av. Vitria Jucutuquara Vitria ES - CEP - (27) 3331.2139 Crditos de autoria da editorao Capa: Juliana Cristina da Silva Projeto grfico: Juliana Cristina e Nelson Torres Iconografia: Nelson Torres Editorao eletrnica: Duo Translation Reviso de texto: Ilioni Augusta da Costa COPYRIGHT proibida a reproduo, mesmo que parcial, por qualquer meio, sem autorizao escrita dos autores e do detentor dos direitos autorais. Tecnologia em Anlise e Desenvolvimento de Sistemas
Ol, Aluno(a)!
um prazer t-lo(a) conosco. O Ifes Instituto Federal do Esprito Santo oferece a voc, em parceria com as Prefeituras e com o Governo Federal, o Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas, na modalidade a distncia. Apesar de este curso ser ofertado a distncia, esperamos que haja proximidade entre ns, pois, hoje, graas aos recursos da tecnologia da informao (e-mails, chat, videoconferncia, etc.) podemos manter uma comunicao efetiva. importante que voc conhea toda a equipe envolvida neste curso: coordenadores, professores especialistas, tutores a distncia e tutores presenciais, porque quando precisar de algum tipo de ajuda saber a quem recorrer. Na EaD Educao a Distncia, voc o grande responsvel pelo sucesso da aprendizagem. Por isso, necessrio que se organize para os estudos e para a realizao de todas as atividades, nos prazos estabelecidos, conforme orientao dos Professores Especialistas e Tutores. Fique atento s orientaes de estudo que se encontram no Manual do Aluno! A EaD, pela sua caracterstica de amplitude e pelo uso de tecnologias modernas, representa uma nova forma de aprender, respeitando, sempre, o seu tempo. Desejamos-lhe sucesso e dedicao!
Equipe do Ifes
ICONOGRAFIA
Veja, abaixo, alguns smbolos utilizados neste material para gui-lo em seus estudos
Fala do Professor
Conceitos importantes. Fique atento!
Atividades que devem ser elaboradas por voc, aps a leitura dos textos.
Indicao de leituras complemtares, referentes ao contedo estudado.
Destaque de algo importante, referente ao contedo apresentado. Ateno!
Reflexo/questionamento sobre algo importante referente ao contedo apresentado.
Espao reservado para as anotaes que voc julgar necessrias.
Tecnologia em Anlise e Desenvolvimento de Sistemas
PROJETO CLIENTE SERVIDOR
Cap. 1 - ARQUITETURA DE SOFTWARE 9

1.1 Caractersticas 9 1.2 Arquitetura distribuda 15 1.2.1 Sistemas distribudos 15 1.2.2 Arquiteturas de sistemas distribudos 19
Cap. 2 - APLICAES CLIENTE SERVIDOR 21

2.1 Vantagens da abordagem cliente-servidor 22 2.2 MVC Model View Controller 24
Cap. 3 - ESPECIFICAO DE REQUISITOS 27

3.1 O que vamos fazer nesta etapa? 27 3.2 Estudo de caso: especificao de requisitos da Locadora Passatempo 29
Cap. 4 - ANLISE 37
4.1 O que vamos fazer nesta etapa? 38
Cap. 5 - PROJETO 49
5.1 hora de fazer CERA! 49 5.2 Distribuio geogrfica 52 5.2.1 Caso de uso por localizao 52 5.2.2 Classes por localizao 52 5.2.3 Caso de Uso / Classe 53
Cap. 6 - PROJETO DE BANCO DE DADOS 57

6.1 Estimando o tamanho de banco de dados 57 6.2 Estatstica de crescimento 59 6.3 Estratgias de distribuio 62
Cap. 7 - PROJETO DE ARQUITETURA DO SISTEMA 69

7.1 Dividir para conquistar! 69 7.2 Exemplo de Projeto Orientado a Objetos (Falbo, 2003) 71
7.3 Pacote Controle de Acervo 72 7.3.1 Pacote DP_ControleAcervo 72 7.3.2 Pacote IU_ControleAcervo 75 7.3.3 Pacote GT_ControleAcervo 78 7.3.4 Pacote GD_ControleAcervo 81 7.3.5 A aplicao 84
Cap. 8 - DOCUMENTAO DE PROJETO 89 REFERNCIAS BIBLIOGRFICAS 93
APRESENTAO
Ol! Meu nome Jos Mrio Costa Junior, responsvel pela disciplina Projeto Cliente Servidor. Atuo como Analista de Tecnologia da Informao no CEAD do Ifes e tambm como professor da disciplina Banco de Dados, nessa mesma Instituio. Alm disso, trabalhei dois anos como desenvolvedor de sistemas, prestando servios para grandes empresas do Esprito Santo. Nesse tempo, tive a oportunidade de conhecer vrias tecnologias e entender como funciona a dinmica dos processos de construo de um software, desde o primeiro contato com o cliente at a implantao do programa. Foi com muito orgulho que aceitei o convite para desenvolver com voc a disciplina de Projeto Cliente Servidor. Primeiramente, porque sou formado no mesmo curso que voc agora est fazendo, embora na modalidade presencial. Depois, porque essa foi uma das disciplinas de que mais gostei durante a minha graduao. Voc at agora cursou muitas disciplinas interessantes: Gesto de Projetos, Anlise de Sistemas, Projeto de Sistemas, Banco de Dados, Engenharia de Software, Programao, entre outras. Cada uma representa uma pea de um quebra-cabea que, depois de montado, constitui um sistema de informao. a que entra em cena a disciplina Projeto Cliente Servidor: nela voc vai entender como juntar todas as peas! Espero que essa verdadeira viagem pelas fases da construo de um software seja muito prazerosa para voc. E para que essa viagem acontea de forma tranquila e seja interessante, conto com seu empenho e sua dedicao. Tenho certeza de que ao final deste curso a sua viso do processo de software estar ampliada e mais consistente. Um grande abrao, e conte sempre com a equipe CEAD! Prof. Jos Mrio Costa Junior
Agradecimentos Ao professor Ricardo de Almeida Falbo, por ter gentilmente permitido a utilizao de exemplos e notas de aula neste material. professora Vanessa Battestin Nunes, por contribuir com sua experincia profissional e tambm com notas de aula.
ARQUITETURA DE SOFTWARE
Ol Aluno! Neste captulo inicial vamos compreender as caractersticas bsicas que uma arquitetura de software deve possuir. Alm disso, vamos estudar alguns tipos de arquitetura mais comuns. Os conhecimentos adquiridos neste captulo sero teis para a aprendizagem dos demais contedos trabalhados nesta disciplina, principalmente para os estudos mais aprofundados de arquitetura cliente-servidor. Muitos conceitos aqui apresentados podem coincidir com os aprendidos na disciplina Projeto de Sistemas. Se voc j os souber, timo! Poder utilizar este captulo como reviso e consolidar ainda mais o esse conhecimento. Se no, aqui est a sua oportunidade de aprender esse importante tpico para sua formao.
1.1 Caractersticas
Ns estamos acostumados a lidar com arquiteturas o tempo todo, mesmo sem perceber. O exemplo mais comum so as construes. Um prdio possui uma arquitetura. No momento de sua construo, preciso pensar em cada parte, como constituinte de um grande projeto. H a parte eltrica, os encanamentos, a estrutura de cimento; depois necessrio pensar na fachada, nos revestimentos etc. No final do projeto, depois que cada uma dessas partes for finalizada, o prdio estar pronto. Se um arquiteto ou um engenheiro que no participou do projeto tiver acesso aos documentos gerados para cada parte, como o projeto eltrico ou a planta de um andar, ele ser capaz de entender o que foi feito e dar continuidade ao trabalho. Obviamente que o documento deve estar bem escrito e com ilustraes coerentes com a realidade. Assim, esses profissionais teriam a possibilidade de avaliar o projeto desenvolvido e poderiam at sugerir modificaes. Semelhantemente a um projeto de um prdio, os softwares de grande porte no podem ser construdos de uma s vez. Eles so decompostos em subsistemas menores. Cada subsistema fornece um servio diferenProjeto Cliente Servidor
10
Captulo 1
te. Todos eles, juntos, fornecem servios inter-relacionados, que formaram o programa final. como dividir um algoritmo em funes. Mas, para um sistema grande, essas funes so to complexas que acabam tendo inmeras outras encapsuladas, formando um subsistema. No incio da fase de projeto de um software, a primeira coisa que deve ser feita identificar esses subsistemas e estabelecer uma forma de controle e comunicao entre eles. Esse o projeto da arquitetura do software. O artefato gerado nesse projeto uma descrio da arquitetura do software. Simples, no?
A Arquitetura de um software envolve a identificao dos principais componentes do sistema e das comunicaes entre eles. Engloba, ainda, a descrio detalhada de como o sistema organizado e de como os componentes operam entre si. (SOMMERVILLE, 2006).
A definio da arquitetura vai influenciar muitas outras coisas no projeto. Ela o ponto de partida para decidirmos como vamos construir o software. Se escolhermos uma arquitetura equivocada o programa simplesmente no funcionar e o projeto ser abortado. claro que arquitetar um sistema uma atividade relativamente complexa. H vrios pontos a ponderar, envolvendo representao do negcio do cliente, infra-estrutura de hardware, organizao do software, etc. Da surge a pergunta: por que se aventurar na elaborao de uma arquitetura, gastando tempo e dinheiro?
A resposta mais simples : porque sem planejar a arquitetura, seu software corre grande risco de no funcionar. Se voc no elaborar uma arquitetura adequada, muito provvel que nem voc mesmo entenda a organizao depois de um tempo. E pode acreditar que voc precisar manter o programa depois de implantado. Se no houver documento de arquitetura, voc ter que descobrir como o software est organizado analisando o cdigo. E essa no uma tarefa agradvel. No mesmo.
Alm disso, h outras vantagens em projetar e documentar a arquitetura de um software (SOMMERVILLE, 2006): Comunicao com o cliente: o documento de arquitetura uma apresentao em alto nvel do sistema. Ele servir de ponto de disTecnologia em Anlise e Desenvolvimento de Sistemas
Arquitetura de Software
11
cusso com o cliente e j a ser possvel evitar futuros problemas de no cumprimento dos requisitos esperados. Anlise do sistema: as decises tomadas no projeto arquitetural ajudam a observar se o sistema est apto a cumprir o que foi definido na etapa de levantamento de requisitos. Itens importantes como desempenho, confiabilidade e manutenabilidade esto intimamente ligados com a arquitetura escolhida. Por exemplo, um sistema bancrio no pode demorar quinze minutos para realizar uma transferncia. Se a arquitetura no favorecer o desempenho desejado, o sistema no ter atendido a um requisito bsico para o qual foi criado. Reutilizao: um projeto de arquitetura bem elaborado deve levar em conta a reutilizao. Reutilizar economiza tempo, dinheiro e problemas, j que estaremos usando algo que foi testado. O raciocnio simples: sistemas semelhantes utilizam arquiteturas semelhantes. possvel desenvolver arquiteturas altamente adaptveis e construir uma srie de programas utilizando-as. Essa uma prtica muito desejada no mercado de software. Algumas atividades so comuns no momento de definir a arquitetura do sistema. O resultado dessas tarefas esclarece para a equipe desenvolvedora o que ser necessrio planejar e implementar para que o sistema cumpra seu objetivo. Conforme Falbo (2003), algumas delas so: Coletar estatsticas: algumas pesquisas devero ser realizadas para garantir uma arquitetura adequada, como volume de dados, frequncia de disparo de eventos, tempos de resposta, entre outros. Topologia geogrfica: em que lugares o sistema dever funcionar? Por exemplo, um sistema para uma loja ser utilizado apenas na matriz ou em todas as filiais? Particionamento de dados e processos: como os dados e processos do sistema estaro distribudos nos locais de computao? Trfego: Como ser o trfego na rede? E o tamanho dos dados a serem transportados? Projeto x Anlise: o projeto arquitetural satisfaz s exigncias da fase de anlise?
12
Captulo 1
O projeto arquitetural mapeia as definies da anlise mais voltadas ao ngocio para definies mais tcnicas, voltadas computao do problema. Enquanto a Anlise imagina um mundo perfeito, no projeto de arquitetura devemos pensar nas questes prticas de implementao do sistema de forma real. Na Anlise feita uma abordagem mais conceitual, sem levar em conta a infraestrutura disponvel, imaginando um mundo perfeito. No projeto, hora de pensar nos detalhes, como Hardware, distribuio, etc.
Durante a fase de levantamento de requisitos, identificamos os requisitos no funcionais.
Para que um sistema de informao atenda aos objetivos para o qual foi solicitado, alm do entendimento de suas funcionalidades, deve-se atentar para outros fatores que influenciam a qualidade final do produto e no fazem parte das regras de negcio que regem o desenvolvimento. Esses fatores so os requisitos no funcionais.
Os requisitos no funcionais influenciam muito na escolha da arquitetura. Podemos dizer que, enquanto na fase de anlise damos muita importncia para os requisitos funcionais ou de negcio, na definio de arquitetura vamos dar relevncia aos requisitos no funcionais. Sommerville (2003) mapeou alguns requisitos no funcionais mais comuns com os tipos de arquitetura que preferencialmente devem ser escolhidas:
13
Requisito No Funcional Desempenho
Proteo
Segurana
Disponibilidade
Manutenabilidade
Arquitetura Para sistemas que exijam grande desempenho, melhor escolher uma arquitetura com menos comunicao entre os subsistemas. Precisamos de uma granularidade maior. Na diviso de camadas, os itens mais importantes devem estar nas camadas mais internas. Haver muitas validaes (de acesso, por exemplo) para essas camadas. Operaes relacionadas segurana devem preferencialmente estar em um subsistema separado. Isso reduz validaes excessivas nos outros subsistemas. Se estivermos falando de um sistema crtico que exige disponibilidade, melhor adotar uma arquitetura redundante, ou seja, com dados repetidos. Para facilitar as manutenes, o ideal que a arquitetura possua muitos componentes encapsulados e com granularidade mnima. Assim, os subsistemas ficam mais fceis de serem mantidos.
Quadro 01: requisitos no funcionais e indicaes de arquitetura.
Granularidade tem a ver com o nvel de detalhamento dos componentes. Se os componentes possuem muitos detalhes implementados, dizemos que a granularidade menor, ou seja, as informaes esto pouco espalhadas entre os subsistemas. Quando temos componentes menores, dizemos que temos alta granularidade, ou seja, as informaes esto mais espalhadas entre os subsistemas.
14
Captulo 1
Voc notou que algumas das arquiteturas preferenciais para alguns requisitos so conflitantes? Analise melhor o caso de um sistema que exija desempenho e manutenabilidade ao mesmo tempo. Pense que precisaremos sempre utilizar um meio termo na escolha da arquitetura. Isso vai clarear sua reflexo.
Durante a definio da arquitetura do sistema, temos que documentar todas as decises. importante formalizar todas as decises durante o andamento da definio ao invs de deixar para documentar tudo no final. Detalhes importantes podem ser esquecidos e talvez problemas futuros ocorram por falta de informao. A sada do projeto arquitetural ser um documento detalhado com a representao grfica dos modelos e texto descritivo para cada um deles. A representao dos diagramas gerados geralmente feita utilizando-se a UML (Unified Modeling Language). Veja um exemplo de um trecho de um documento de arquitetura. D ateno especial Figura 1:
O diagrama de pacotes da ferramenta proposta foi bastante influenciado pela utilizao do Struts. A Figura 1 apresenta esse diagrama.
Viso Controle actions viso Modelo
domnio
actionForms
persistencia
Figura 1 Diagrama de Pacotes O pacote persistncia responsvel por controlar todo acesso aos recursos de banco de dados. J o pacote domnio encapsula as classes do negcio, com os atributos e funes necessrias para resolver as regras de negcio. Esses dois pacotes constituem a camada de Modelo do MVC. A camada de Controle constituda dos pacotes actions e actionForms. Eles so necessrios para a implementao das aes e dos FormBeans, conforme explicado no fluxo de uma aplicao Struts descrito Tecnologia em Anlise e Desenvolvimento de Sistemas
15
anteriormente. Os elementos do framework no foram representados. O pacote viso contm as pginas jsp utilizadas para apresentar informaes ao usurio.
No exemplo, foi apresentado o diagrama de pacotes de projeto e um texto descritivo explicando o que contm cada um deles. No restante do documento o projetista ainda explica cada pacote detalhadamente. No interessante? Em caso de manuteno no seria muito mais fcil? Agora que voc j entendeu o conceito de arquitetura de software e estudou algumas tarefas bsicas que realizamos para defini-la, vamos estudar um pouco sobre arquitetura distribuda na seo 1.2.
1.2 Arquitetura Distribuda

Existem algumas caractersticas importantes para que uma arquitetura seja considerada distribuda. Vamos abordar alguns tipos principais de sistemas distribudos e estudar algumas de suas qualidades e defeitos nesta seo. 1.2.1 Sistemas Distribudos At recentemente a maior parte dos sistemas funcionava de forma centralizada, em uma s mquina. Muitos funcionavam em mainframes enormes com alguns terminais burros ou seja, sem capacidade de processamento. Os mainframes realizavam todo o processamento e somente enviavam as informaes aos terminais. Com a evoluo absurdamente rpida das redes de computadores e especialmente da Internet, esse quadro mudou. Hoje, praticamente todos os sistemas de grande porte so distribudos.
Sistemas Distribudos so aqueles em que as informaes so distribudas para vrios computadores ao invs de serem processadas em uma nica mquina (SOMMERVILE, 2003).
O projeto dos sistemas distribudos possui muitos pontos em comum com o desenvolvimento de um sistema centralizado. No entanto, h muitas caractersticas especficas que devem ser pensadas no processamento distribudo. Veremos muitas delas no decorrer da nossa disciplina.
16
Captulo 1
Sommerville (2003) destaca que temos hoje basicamente trs tipos de sistemas: Sistemas pessoais: no so distribudos. So projetados para funcionar em computadores pessoais. Sistemas embutidos: so executados em um nico processador ou em um conjunto integrado de computadores. Muito utilizados em dispositivos pequenos. Sistemas distribudos: o programa executado por um conjunto de processadores pouco integrados e conectados por uma rede.
Cite, para cada tipo de sistema, dois exemplos de software que voc conhece. _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ __________________________________________________
17
Os sistemas distribudos possuem caractersticas especiais. Coulouris (1994) explicou algumas delas: Compartilhamento: sistemas distribudos permitem o compartilhamento de recursos, sejam de hardware sejam de software. Os sistemas centralizados tambm efetuam compartilhamento. Mas o controle feito por um computador central. Concorrncia: Vrios processos podem executar e se comunicar ao mesmo tempo em diferentes mquinas. Isso uma grande vantagem e um dos principais pontos a que se deve ter ateno no desenvolvimento de um sistema distribudo. A complexidade do controle de concorrncia pode ser grande. Escalabilidade: a capacidade do sistema pode ser aumentada, acrescentando-se recursos de acordo com as demandas que vo surgindo com o tempo.
A escalabilidade deve ser uma caracterstica de um bom sistema distribudo. No entanto, ela pode ser limitada por restries da rede. Imagine um sistema construdo para atender a duas filiais e que precisa ser expandido para cem. O aumento do nmero de mquinas pode fazer com que a capacidade da rede se torne ineficiente.
Tolerncia: uma das grandes vantagens de um sistema distribudo o potencial de duplicao de informaes. Por exemplo, se uma mquina falhar, podemos colocar para funcionar outra que estava mantendo as informaes atualizadas. Geralmente, falhas crticas ocorrem quando h problemas na rede.
Cuidado com o excesso de redundncia! Talvez no valha a pena replicar todas as informaes para garantir a tolerncia. Tenha em mente que a maioria das boas aes tomadas no projeto arquitetural levam em conta o meio termo das solues.
Transparncia: os usurios do sistema no precisam saber nada sobre a distribuio do sistema. Eles simplesmente podem utiliz-lo como um sistema centralizado. No entanto, saber algum detalhe da arquitetura pode melhorar a utilizao de recursos.
18
Captulo 1
Vimos at agora muitas caractersticas dos sistemas distribudos. A grande maioria delas vantajosas. Voc agora dever pensar em aspectos negativos no uso de uma arquitetura distribuda. Escreva pelo menos cinco aspectos. Para ajud-lo, pense nas seguintes caractersticas: Complexidade Segurana Gerenciamento - Imprevisibilidade __________________________________________________ __________________________________________________ _________________________________________________ __________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ _________________________________________________ _________________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ ______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ ______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ ____________________________________________________
19
1.2.2 Arquiteturas de Sistemas Distribudos Agora que voc j estudou as principais caractersticas envolvidas no projeto de um sistema distribudo, vamos revisar algumas arquiteturas para esses sistemas: Arquitetura de multiprocessadores: nessa arquitetura, h diversos processos que podem ou no serem executados em processadores diferentes. muito comum em sistemas de tempo real, de previso de tempo e de trfego areo. Essa arquitetura prope que o sistema colete informaes, tome as decises necessrias e envie sinais para os atuadores mudarem o ambiente do sistema. Os processos que realizam essas atividades podem ser controlados por um escalador (scheduler). A distribuio dos processos pode ser predeterminada ou ficar sob o controle do escalador. P2P (peer-to-peer): esta uma arquitetura na qual todas as mquinas envolvidas compartilham um pouco de seus recursos para o processamento da informao. Esses recursos podem ser processador, memria, espao em disco, banda de conexo, etc. O interessante aqui que no h um processamento central. Todas as mquinas envolvidas so responsveis pelo processamento. No h um servidor para controlar as aes do sistema. As mquinas participantes de um sistema P2P so, ao mesmo tempo, produtoras e consumidoras de servios. Sistemas desse tipo so utilizados para diversos fins, principalmente para compartilhamento de arquivos. Arquitetura de objetos distribudos: nesse tipo de arquitetura, no h a distino entre clientes (aqueles que solicitam servios) e servidores (aqueles que proveem servios). Os componentes fundamentais do sistema so objetos que possuem uma interface para o conjunto de servio que eles fornecem. Outros objetos solicitam os servios sem diferena entre cliente e servidor. Os objetos podem ser distribudos em uma rede de computadores e se comunicar via middleware.
Os componentes de um sistema distribudo podem ser implementados em diferentes linguagens e executados em processadores muito diferentes. Precisamos de um software que gerencie essas partes e garanta a comunicao entre elas, possibilitando a troca de dados. Esse software o middleware.
20
Captulo 1
Arquitetura Cliente-Servidor: nessa arquitetura que queramos chegar! Ela a que, obviamente, utilizaremos na disciplina Projeto Cliente Servidor. Por ser to importante, ela ser mais aprofundada no prximo captulo!
Aps ler este captulo, voc deve ser capaz de: Entender as caractersticas de uma arquitetura de software. Entender a importncia da adoo de uma arquitetura. Compreender o que um sistema distribudo e suas caractersticas. Ter uma viso geral dos tipos de arquitetura distribuda.
No nosso prximo captulo estudaremos com mais detalhes a Arquitetura Cliente-Servidor. Alm disso, voc j comear a fazer atividades prticas da nossa disciplina. Por isso, se voc no entendeu algum tpico deste captulo, entre no ambiente virtual e tire suas dvidas. Os tutores esto preparados para respond-las no Frum de dvidas da Semana 1. No ambiente virtual voc tambm encontrar um questionrio sobre o que foi discutido neste captulo. Assim voc poder revisar o contedo e consolidar o conhecimento adquirido. No deixe de participar do frum de discusso sobre as arquiteturas de software. Ele avaliativo! Alm disso, voc aprender muito pesquisando sobre as arquiteturas e lendo o material escrito pelos colegas.
Para complementar seus estudos, leia: SOMMERVILLE, Ian. Engenharia de Software. 6.ed.So Paulo: Pearson Addison Wesley, 2003. (Captulos 10 e 11). Notas de aula de Projeto de Sistemas do professor Ricardo Falbo. Disponvel em www.inf.ufes.br/~falbo.
21
APLICAES CLIENTE SERVIDOR
Ol! Neste captulo vamos estudar alguns aspectos das aplicaes cliente-servidor. Atualmente, a distribuio uma alternativa muito utilizada quando se pensa a arquitetura de um software. Imagine voc trabalhando em uma empresa que possui um sistema de ponto eletrnico. Vamos imaginar duas situaes: 1 O software de controle de ponto est instalado em uma mquina. Os funcionrios, ao chegarem empresa, se dirigem at esse computador e registram sua chegada. Na hora da sada, acontece a mesma coisa. 2 - O software de controle est instalado em uma mquina. Mas por meio de configuraes especiais, possvel que cada funcionrio acesse o programa de seu computador. Qual situao a mais adequada? Se voc respondeu nmero 2, est convidado a aprofundar seus conhecimentos nesta disciplina. Se respondeu nmero 1, vamos aprender juntos as vantagens de uma arquitetura mais robusta!
A primeira situao apresentada nos mostrou uma aplicao desktop que funcionava apenas em uma mquina. Quem quisesse utiliz-la teria que se dirigir ao computador. J na segunda situao, a aplicao estava em uma mquina central, de onde vrias outras poderiam acessar a aplicao. Entendemos que essa mquina central oferece o servio da aplicao, ou seja, serve vrias outras mquinas que seriam clientes.
Clientes
Servidor
Clientes
Figura 2 Arquitetura cliente Servidor Projeto Cliente Servidor
22
Captulo 2
A Figura 2 apresenta a arquitetura tpica de uma aplicao cliente servidor.
A computao cliente-servidor um processamento cooperativo de informaes de negcio por um conjunto de processadores, no qual mltiplos clientes geograficamente distribudos iniciam requisies que so realizadas por um ou mais servidores centrais (FALBO, 2003).
Simples, no? Sempre que temos uma plicao executando em mais de um computador, estamos tratando de clientes e servidores. claro que as partes conversam entre si. No caso do nosso sistema de ponto eletrnico, as informaes enviadas pelos funcionrios de suas mquinas so enviadas mquina central (servidora) e armazenados adequadamente. E as vantagens disso tudo?
2.1 Vantagens da abordagem cliente servidor

Existem vrias razes para utilizarmos a arquitetura cliente-servidor. Uma delas j conhecemos: a possibilidade de acessos simultneos por vrios usurios. Voc j pensou que, se o sistema de ponto estivesse em uma s mquina, os funcionrios brigariam para decidir quem acessaria primeiro? Se fosse assim, a hora da sada seria catica. Agora, vamos pensar nas mquinas. Assim como acontece com a gente, muito trabalho sobrecarrega os computadores! Quando utilizamos a arquitetura cliente servidor, parte do processamento fica no servidor (back-end) e parte no cliente (front-end). Isso, claro, deve ser pensado na hora em que se projeta o software. Seno, algum vai ficar insatisfeito, trabalhando muito e vendo os outros descansarem. Outra vantagem a transparncia no processamento. Os usurios no precisam saber se o cliente ou o servidor quem est processando sua requisio. Eles simplesmente recebero o que pediram aplicao. O baixo aclopamento tambm interessante nesta arquitetura. Como os mdulos so bem separados, fica mais fcil realizar manutenes sem ter que alterar o cdigo inteiro. E se quisermos acrescentar novos mdulos, fica bem mais fcil.
Aplicaes Cliente-Servidor
23
Podemos pensar tambm no encapsulamento, que voc deve ter visto na orientao a objetos. O cliente no precisa saber como o servidor implementa um determinado servio. Ele precisa apenas conhecer a interface.
Voc deve estar pensando: Uau! Que tima essa arquitetura! Ela perfeita!. No, no. Vamos com calma. Agora que estudamos algumas vantagens da arquitetura cliente-servidor, voc tem a misso de pesquisar pelo menos 5 desvantagens. Pense nos termos:
Custo Complexidade Sincronizao Distribuio Desempenho
___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ____________________________________________________
24
Captulo 2
O que vimos at aqui diz muito respeito diviso de hardware. Legal, mas e o software, como fica? Para comearmos a entender a diviso do software na arquitetura, vamos estudar um padro de arquitetura de projeto chamado MVC.
2.2 MVC Model View Controller

Voc, nesta altura do campeonato, deve estar acostumado com o ambiente virtual utilizado pelo Ifes, o Moodle. Eu sei, eu sei. Vez ou outra ele falha. Mas vai dizer que voc no o ama? O Moodle tambm pode ser encarado como uma aplicao cliente servidor. Voc consegue acess-lo de qualquer lugar. Enquanto voc o acessa, vrios colegas tambm utilizam o ambiente. O processamento das informaes no centralizado na sua mquina. Todas as suas atividades so gravadas em um servidor remoto. O que voc v do Moodle a casca. Voc interage com a interface dele, ou seja, o Moodle disponibiliza uma viso para voc. Obviamente (Toro para que sim!) voc realiza tarefas na plataforma. Envia os dados para o tutor analisar. E esses dados so armazenados em uma base dados, garantindo, assim, que no dia seguinte voc e seu tutor possam visualizar as tarefas. Quando voc clica no boto enviar da tarefa, uma srie de processamentos so realizados, embora voc no consiga visualiz-los. Todas as aes realizadas na viso precisam ser controladas, processadas por uma srie de rotinas lgicas e, ento, armazenadas na base de dados. Pudemos perceber que o Moodle adota o padro Model-View-Controller (MVC), que separa os dados do aplicativo (contidos no modelo), dos componentes grficos de apresentao (viso) e lgica de processamento das entradas (controlador) (DEITEL, 2003). A Figura 3 apresenta os relacionamentos entre estes componentes:
Aplicaes Cliente-Servidor
25
Controlador (controller)
Viso (view)
Modelo (model)
Figura 3 Arquitetura Model-View-Controller
Model View Controller (MVC) um padro de arquitetura de software que prope a diviso do software em trs camadas distintas que se comunicam entre si. Esse padro favorece o baixo acoplamento, melhorando a estrutura do software.
A camada viso a interface grfica do sistema. Muitas vezes a qualidade de um software medida por essa camada. Ela capta as entradas do usurio e as envia para o controlador. Geralmente ela est nas mquinas clientes. A camada controladora responsvel por obter os dados da camada de viso e decidir o que far com eles. Ela requisita camada de modelo as operaes necessrias para processamento da entrada. Depois que o modelo executar as operaes de negcio e persistncia, o controlador obtm o resultado e o envia para a camada de viso. O controlador pode estar no servidor ou nos clientes. A camada modelo contm os dados e a lgica de negcio da aplicao. Geralmente fica no servidor da aplicao.
Aps ler este captulo, voc deve ser capaz de: Entender o conceito de arquitetura cliente servidor. Conhecer vantagens e desvantagens da arquitetura. Compreender o padro de arquitetura Model-View-Controller.
26
Captulo 2
Como disse no incio do material, esta disciplina uma mistura de vrias outras disciplinas que voc estudou. O nosso objetivo mostrar a voc o desenvolvimento de uma aplicao cliente/servidor. Alm disso, voc tambm construir uma pequena aplicao! No muito fcil encontrar na literatura uma referncia para a disciplina Projeto Cliente/Servidor. Ela muito prtica e multidisciplinar. Na verdade, essa a realidade que voc vai encarar no mercado de trabalho. Mas, ainda assim, existem materiais muito bons. Um deles so as notas de aula e os exemplos do professor Ricardo de Almeida Falbo, professor da Universidade Federal do Esprito Santo. No site www.inf.ufes.br/~falbo h apostilas de Anlise de Sistemas, Engenharia de Software e Projeto de Sistemas, alm de um exemplo completo de aplicao. Na nossa disciplina, vamos utilizar bastante os materiais do professor Ricardo, inclusive o exerccio da Locadora de Vdeo como estudo de caso. Vamos discutir as alternativas de Anlise de Projeto utilizadas. Paralelamente, voc ir construir sua prpria aplicao, sempre se baseando em nossas discusses. No prximo captulo trabalharemos a Especificao de Requisitos para aplicaes Cliente-Servidor. Acesse o ambiente e comece a pensar no seu projeto!
27
ESPECIFICAO DE REQUISITOS
A partir deste captulo, vamos comear a discutir as etapas de construo de uma aplicao, desde a especificao dos requisitos at o documento de projeto, dando uma olhada rpida na implementao. Ns no vamos entrar em muitos detalhes. Afinal, voc j estudou grande parte dos assuntos nas disciplinas de Anlise de Sistemas, Engenharia de Software e Projeto de Sistemas. A ideia aqui acompanhar um estudo de caso e ir desenvolvendo sua prpria aplicao. Vamos conversar sobre a Especificao de Requisitos, etapa fundamental na construo de um software. Aqui estudaremos alguns detalhes para as aplicaes cliente servidor. Analisaremos o estudo de caso da locadora e comearemos a pensar nos requisitos da sua aplicao.
Grande parte das falhas durante a construo de sistemas de informao se deve ao mau entendimento dos requisitos do projeto. Quanto mais complexo for o negcio envolvido, mais chances h de a equipe de desenvolvedores do projeto no compreenderem o escopo e o objetivo das funcionalidades que sero posteriormente transformadas em cdigo fonte. Por isso, h a necessidade da construo de um modelo que seja passvel de compreender tanto pelo time desenvolvedor quanto pelos clientes e pelas pessoas que vo de fato utilizar o sistema (conhecedores das regras de negcio) (NUNES, 2001).
3.1 O que vamos fazer nesta etapa?

Nesta etapa elaboraremos o documento de especificao de requisitos da aplicao. Iremos primeiro analisar o layout do documento, proposto por Falbo (2003). O texto em azul so as instrues de preenchimento de cada seo.
28
Captulo 3
<Nome do Projeto> Documento de Especificao de Requisitos 1. Introduo < Na seo Introduo, voc dever escrever um breve resumo dos objetivos do documento. interessante sempre esclarecer para o leitor as sees presentes no documento e o que cada uma tratar.> 2. Descrio do Mini-mundo < Na Descrio do Mini-Mundo, voc dever descrever com bastante detalhes do que trata o seu negcio. Em documentos reais das empresas, essa seo costuma ser bem detalhada, porque geralmente as regras envolvidas so extensas e complexas. > 3. Modelos de Caso de Uso <Depois da descrio das regras de negcio, hora de pensar nos casos de uso. Nesse momento, voc ir decidir, a partir das regras de negcio, os casos de uso que implementar e se eles estaro divididos em pacotes distintos.> 4. Descrio dos Casos de Uso <Aqui sero inseridas todas as descries de casos de uso. Veja mais detalhes no quadro 02.>
Quadro 02: modelo de documento de especificao de requisitos
Descrever o mini-mundo com clareza de extrema importncia. A partir daqui a modelagem do sistema inteiro comea a ganhar vida. Regras de negcio mal elaboradas e no revistas pelo cliente podem causar srios problemas no futuro, como funcionalidades mal implementadas e retrabalho dos analistas e desenvolvedores. Por isso muito importante captar os detalhes dos requisitos, utilizando as tcnicas aprendidas na disciplina de Anlise. Reunies de esclarecimento com os clientes so essenciais. Elas costumam ser longas, mas muito produtivas. Voc dever tambm descrever todos os casos de uso encontrados. O Quadro 3 apresenta o modelo de descrio de casos de uso que vamos adotar:
Especificao de Requisitos
29
Projeto: <nome do seu projeto> Subsistema: <Se os casos de uso foram divididos em pacote, colocar aqui o nome do pacote do caso de uso a ser descrito> Nome do Caso de Uso: <recomenda-se utilizar os verbos Manter ou Cadastrar no incio do nome do caso de uso> Analista: <Seu nome > Data: <data da ltima atualizao do caso de uso> Descrio: <escrever aqui uma breve descrio do caso de uso, abrangendo os cenrios envolvidos>. Curso Normal: <Sero listados os cursos normais para cada cenrio identificado. Geralmente os cenrios so Criar (ou incluir), Excluir, Recuperar (ou Consultar) e Alterar (CERA)>. Cursos Alternativos: <Sero listados os cursos alternativos para cada cenrio identificado no curso normal>. Classes: <Classes originadas do caso de uso. Essa seo apenas ser preenchida aps a elaborao do diagrama de classes>.
Quadro 3: Padro para descrio de casos de Uso (Falbo, 2003).
importante ressaltar que os modelos de documentos podem ser diferentes. Isso depende da metodologia adotada por cada empresa. Algumas solicitam documentos mais detalhados; outras optam por documentos mais sucintos; outras nem fazem casos de uso ( fujam dessas)
3.2 Estudo de caso: Especificao de Requisitos da Locadora Passatempo

Para que voc aprenda as etapas do desenvolvimento da aplicao e a elaborao da documentao necessria, vamos analisar o exemplo da Locadora Passatempo, desenvolvido pelo professor Ricardo Falbo. Neste material, veremos apenas trechos dos documentos, j que eles so muito extensos. O material completo voc pode acessar no site www.inf.ufes.br/~falbo.
30
Captulo 3
Projeto Locadora de Vdeo Passatempo Documento de Especificao de Requisitos 1. Introduo Este documento contm a especificao de requisitos para o projeto de informatizao da vdeo locadora Passatempo. Esta atividade foi desenvolvida usando a tcnica de modelagem de casos de uso e, portanto, esse documento apresenta os diagramas de caso de uso gerados, bem como as descries dos atores e dos casos de usos identificados nesses diagramas. Na seo 2, uma breve descrio do domnio do problema feita. 2. Descrio do Mini-mundo Uma locadora de mdio porte, a Vdeo Locadora Passatempo, deseja um sistema de informao para melhorar o atendimento aos clientes. Em um primeiro instante, apenas os elementos envolvidos diretamente neste contexto sero alvo do sistema, como possvel notar pela descrio a seguir. A locadora possui diversos ttulos, sendo que, para cada ttulo, h uma ou mais fitas ou DVDs. Os ttulos so agrupados por categoria, tais como drama, comdia, documentrio, policial, ertico, terror etc. Alm disso, a locadora faz um controle dos ttulos em funo de sua classe. Tipicamente so cinco as classes da Vdeo Locadora Passatempo: super-lanamento, lanamento, ouro, prata e bronze. Ao longo do tempo, um filme pode ser classificado de diferentes maneiras, geralmente comeando pela classe super-lanamento, passando pelas classes lanamento, ouro e prata, at chegar classe bronze. O valor de uma locao e o nmero de dias de prazo para devoluo so dados pela classe na qual o filme est classificado na data da locao. Os valores correntes para as locaes de filmes nas classes super-lanamento, lanamento, ouro, prata e bronze so, respectivamente, R$ 7,00, R$ 5,00, R$ 4,00, R$ 3,00 e R$ 2,00. Os prazos para essas mesmas classes so, respectivamente, 1, 2, 3, 5 e 7 dias. Contudo, o valor efetivamente cobrado por uma locao ou a sua data de devoluo prevista podem ser alterados pelo funcionrio da locadora para aplicar descontos individualizados ou ampliar prazos de devoluo. As fitas e DVDs so fornecidas por distribuidores, sendo que cada ttulo tem um distribuidor exclusivo. De um distribuidor deseja-se saber apenas a razo social, CNPJ, endereo, telefone e pessoa de contato. Apesar da distribuio de fitas e DVDs por distribuidores no estar diretamente relacionada com o atendimento a clientes, o gerente da locadora deseja manter essa informao. Assim, deseja-se saber a data de aquisio de um item, alm de seu nmero de srie.
31
Clientes locam itens (fitas ou DVDs). Um cliente pode ser um scio ou um de seus dependentes. Quando um scio faz sua inscrio na locadora, lhe dado o direito de indicar at trs dependentes. importante frisar, contudo, que a responsabilidade pelos dependentes recai totalmente sobre o scio. Ainda assim, fundamental para a locadora identificar exatamente quem locou uma fita, se o prprio scio, ou um de seus dependentes. Para efeito de controle, a locadora deseja ter mais informaes sobre o scio do que sobre seus dependentes. Sobre um scio, deseja-se saber nome, endereo, telefone, local onde trabalha, telefone comercial, sexo, CPF e data de nascimento. De um dependente, so necessrios apenas o nome, sexo e data de nascimento. O nmero de inscrio dever ser o mesmo para um scio e seus dependentes, exceto por um dgito verificador, com valor zero para o scio e um valor diferente de zero para seus dependentes. Clientes podem tambm reservar ttulos. importante registrar a data e a hora em que a reserva foi feita e se o cliente deseja uma fita ou um DVD. Assim, possvel atender as reservas por ordem de chegada. Uma locao s pode ser feita para um item, se no existir uma reserva para o filme. Quando um item de um filme reservado devolvido, comunica-se o cliente interessado e, a partir desse momento, o cliente tem 24 horas para retir-lo; caso contrrio, expira-se a reserva e o item liberado. No so aceitas reservas para ttulos que tm itens disponveis na locadora, nem reservas para datas previamente especificadas. Quando a devoluo de um item feita com atraso, cobra-se como multa o valor da locao por cada dia de atraso. Caso a locao no tenha sido paga no ato da locao, ter de ser paga obrigatoriamente na devoluo. No so aceitos pagamentos mensais ou em outros momentos que no a locao ou a devoluo. Alm disso, o cliente pode efetuar um nico pagamento para vrias locaes. Pagamentos podem ser feitos em dinheiro ou cheque, sendo que para pagamentos com cheque deseja-se saber: banco, agncia, conta e nmero do cheque. Visando atender uma solicitao constante dos diversos clientes da locadora, o gerente quer que o sistema disponibilize um terminal para consultas a ttulos, a serem feitas pelos prprios clientes. Assim, um cliente poderia consultar um ttulo para saber quais so os atores e diretores que atuam no filme, o ano, ttulo original, nacionalidade e sinopse. Alm disso, devem ser aceitas consultas por categoria, ator, diretor, ttulo original ou nacionalidade. 3. Modelo de Casos de Uso A Figura 4 mostra o diagrama de pacotes do sistema, subdividindo-o em dois subsistemas, a saber:
32
Captulo 3
Controle de Acervo: envolve toda a funcionalidade relacionada com o controle do acervo da vdeo-locadora, abrangendo controle de ttulos, fitas, classes e distribuidores. Atendimento a Cliente: envolve a funcionalidade relacionada ao atendimento aos clientes da locadora, incluindo locao e devoluo de fitas, reserva de ttulos, pagamento e cadastro de clientes.
Atendimento Cliente
Controle Acervo
Figura 4 Diagrama de Pacotes.
3.1 Controle de Acervo A figura 5 mostra o diagrama de casos de uso referente ao controle de acervo. Na seqncia, os casos de uso identificados so descritos usando o padro de descrio proposto.
Cadastrar Ttulo
Cadastrar Item
Funcionrio
Cadastrar Classe Cadastrar Distribuidor
Figura 5 Diagrama de Casos de Uso Controle de Acervo.
O nico ator a atuar neste subsistema o Ator Funcionrio, que representa o papel desempenhado pelos funcionrios da locadora, responsveis tanto pelo controle do acervo, quanto pelo atendimento aos clientes da vdeo-locadora.
33
3.1.2 Descrio dos casos de uso. _______________________________________________________ Projeto: Locadora de Vdeo Passatempo Subsistema: Controle de Acervo Nome do Caso de Uso: Cadastrar Ttulo Analista: Data: 01/12/200 Descrio: Este caso de uso responsvel pelo controle de ttulos, abrangendo a incluso de um novo ttulo, alterao, consulta e excluso de ttulos existentes. Curso Normal: Incluir Novo Ttulo O funcionrio informa os dados do novo ttulo, incluindo: nome, atores, diretores, ano, nome original, nacionalidades, sinopse, categorias, classe e distribuidor. Caso os dados sejam vlidos, as informaes so registradas. Alterar Dados de Ttulo O funcionrio informa o ttulo do qual deseja alterar dados e os novos dados. Os novos dados so validados e a alterao registrada. Consultar Dados de Ttulo O funcionrio informa o ttulo que deseja consultar. Os dados do ttulo so apresentados. Excluir Ttulo O funcionrio informa o ttulo que deseja excluir. Os dados do ttulo so apresentados e solicitada uma confirmao. Se a excluso for confirmada, o ttulo excludo. No permitida a excluso de um ttulo que possua itens. Na excluso de um ttulo, devem ser excludas as reservas feitas para o mesmo.
34
Captulo 3
Cursos Alternativos: Incluir Novo Ttulo / Alterar Dados de Ttulo Dados do ttulo invlidos: uma mensagem de erro exibida, solicitando correo da informao invlida. Excluir Ttulo Ttulo possui itens: uma mensagem de erro exibida, indicando que o ttulo possui itens. Classes: Titulo, Classe, Distribuidor, Reserva. Restries de Integridade: no h. <Para visualizar o documento completo, acesse www.inf.ufes.br/~falbo>
Agora que voc j analisou a especificao de requisitos da Locadora Passatempo, hora de comear a desenvolver a documentao da sua prpria aplicao. Em grupo de at 5 (cinco) pessoas, escolha uma aplicao que possa ser implementada com a arquitetura cliente-servidor. Elabore o documento de especificao de requisitos para ela. Antes de interagir com os colegas no ambiente, comece a pensar sobre uma sugesto de negcio e nos casos de uso envolvidos. ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________
35
Aps a leitura do captulo, voc deve ser capaz de: Entender a importncia do levantamento de requisitos. Conhecer e criticar o documento de especificao de requisitos. Elaborar documento de especificao de requisito para a sua aplicao.
Para complementar, revise a etapa de especificao de requisitos nas disciplinas de Anlise e Engenharia de Software.
36
Captulo 3
37
ANLISE
Na etapa de especificao, elaboramos um documento em linguagem natural e ainda em alto nvel. J samos da abstrao total do negcio e modelamos casos de uso, que sero as funcionalidades da aplicao. Na etapa de anlise, vamos detalhar um pouco mais o problema a ser resolvido. Vamos comear a pensar em alguns aspectos tcnicos do nosso software. Perceba que a cada etapa vamos diminuindo a abstrao do negcio, at chegar implementao. No comeo, temos uma nuvem obscura de informaes. medida que vamos prosseguindo no processo de software, as informaes vo sendo modeladas e se transformando no produto final. Assim como no captulo anterior, vamos analisar um modelo de documentao e, consequentemente, levantar os artefatos que deveremos gerar nesta etapa. Desde j comece a revisar as atividades que voc realizou na disciplina Anlise e Projeto de Sistemas I. Abrao e bons estudos.
Enquanto a fase de especificao de requisitos se preocupa em descrever as funcionalidades do sistema, a anlise engloba as atividades de modelagem do mesmo, a partir da interpretao dos casos do uso, levando em conta o contexto do sistema em um nvel mais especfico. Na anlise, importante que sejam identificadas todas as classes e suas hierarquias, alm de associaes e atributos, modelagem comportamental e identificao de operaes (FALBO, 2003). Essas subatividades devem ser realizadas priorizando-se entender o domnio do problema, e no aspectos de implementao, sendo estes adequados fase de projeto.
38
Captulo 4
4.1 O que vamos fazer nesta etapa?

Nesta fase, teremos muito trabalho e atividades no to simples. Temos que confeccionar muitos diagramas, pensar na modelagem esttica e comportamental, realizar a dicionarizao... So muitos itens para pensar. Voc j deve ter notado na disciplina de Anlise que a modelagem aqui desenvolvida de extrema importncia para o sucesso do sistema, e deve ser exaustivamente revisada e confirmada. E, mesmo revisando e testando, ela provavelmente ser alterada no futuro. Como em todas as fases, teremos que gerar a documentao para esta etapa. Vamos analisar o modelo de documento proposto por Falbo, 2003. O texto em azul indica os contedos que voc dever inserir em cada seo.
<Nome do Projeto> Documento de Especificao de Anlise 1. Introduo <Assim como na especificao de requisitos, nesta seo voc dever descrever brevemente do que trata o documento. interessante tratar rapidamente do processo de produo dos artefatos e indicar as sees em que cada item se encontra> 2. Modelo de Classes <Esta seo apresentar para o usurio a modelagem esttica, por meio do modelo de classes. Chamamos modelagem esttica porque no vamos representar aqui comportamento e sim conceitos. Faa uma pequena introduo falando sobre a importncia desta etapa> 2.1 Diagrama de Pacotes <Caso voc tenha dividido os casos de uso em pacotes, praticamente certo que a sua modelagem de classes tambm se divida em pacotes. Nesta seo, explique essa diviso e mostre o diagrama.> 2.2 Diagrama de Classes <Nesta seo, mostre os diagramas de classe desenvolvidos para cada pacote. Relembre na disciplina de Anlise que, se for preciso representar uma classe de um pacote em outra, voc deve utilizar o esteretipo (from nome_do_pacote). > 2.3 Dicionrio de Dados <Aqui voc dever descrever, com riqueza de detalhes, cada classe e todos os seus atributos e mtodos. Isso importantssimo, pois provavelmente so outras pessoas que desenvolvero o sistema, baseadas na sua especificao. Quanto mais detalhes aqui, menos questionamentos futuros. >
Anlise
39
3. Modelagem Comportamental <Nesta seo, voc descrever as atividades realizadas na modelagem comportamental. Podemos chamar esta etapa de modelagem dinmica, j que estaremos tratando de aes que acontecero no sistema. Faa uma breve introduo sobre os artefatos que voc produziu aqui. Na nossa disciplina, vamos utilizar o diagrama de estados e o diagrama de sequncia.> 3.1 Diagramas de Estado < Aqui voc vai apresentar os diagramas de estado desenvolvidos. No necessrio realizar estes diagramas para todas as classes de todos os pacotes! Voc vai escolher apenas algumas, aquelas que identificam muitas mudanas de estado. Coloque cada diagrama em uma subseo.> 3.1 Diagramas de Sequncia < Insira nesta seo os diagramas de sequncia que voc considera importantes. Note que apenas os casos de uso mais complexos devem ganhar um diagrama de sequncias, pois geralmente essa modelagem trabalhosa e leva muito tempo. No entanto, esses diagramas facilitam bastante a vida dos desenvolvedores, j que detalham muito da implementao. Crie um sub-item para cada diagrama.>
Quadro 04 Documento de Especificao de Anlise
Estudo de Caso: Especificao de Anlise da Locadora Passatempo Voc notou que o documento de anlise traz muitas informaes. Ele provavelmente o mais trabalhoso de todos. Assim, para esclarecer as ideias, vamos continuar acompanhando o desenvolvimento do sistema da Locadora Passatempo:
Projeto Locadora de Vdeo Passatempo Documento de Especificao de Anlise 1. Introduo Este documento contm a especificao de anlise para o projeto de informatizao da vdeolocadora Passatempo. Esta atividade foi desenvolvida em duas etapas principais, a primeira focando na estrutura de informao do sistema (classes, atributos e associaes), a segunda em
40
Captulo 4
seu comportamento (operaes e trocas de mensagem entre objetos). Na seo 2, so apresentados os produtos da primeira etapa, a saber: Diagrama de Pacotes, Diagramas de Classes (um para cada pacote) e um Dicionrio de Dados. Na seo 3, so apresentados os produtos da segunda etapa: Diagramas de Transio de Estados (para as classes com comportamento varivel ao longo do tempo), Diagramas de Seqncia (agrupados por casos de uso) e as Descries da Operao, fechando o conjunto de produtos gerados na fase de anlise. 2. Modelo de Classes A modelagem de classes envolve a identificao de classes, atributos, associaes e operaes, bem como o agrupamento de classes em subsistemas ou pacotes. A seguir, so apresentados os resultados da anlise, no que tange aos aspectos de informao basicamente. 2.1 Diagrama de Pacotes O propsito de um diagrama de pacotes prover uma viso de nvel mais alto do sistema, mostrando sua decomposio em subsistemas. O ponto de partida para essa decomposio o domnio do problema e, portanto, a decomposio utilizada no modelo de casos de uso foi transposta para o modelo de classes, como mostra a Figura 6.
Atendimento Cliente
Controle Acervo
Figura 06 Diagrama de Pacotes
O diagrama da Figura 6 mostra a dependncia principal entre os subsistemas, indicando que o pacote AtendimentoCliente solicita servios do pacote ControleAcervo para poder cumprir suas responsabilidades. Na prxima seo, so apresentados os diagramas de classes para cada um desses pacotes. 2.2 Diagramas de Classes A Figura 7 apresenta o Diagrama de Classes referente ao pacote ControleAcervo.
Anlise
41
Titulo Distribuidor
razaoSocial 1 cnpj pessoaContato endereco telefone nome nomeOriginal ano ator [0..*] 0..n diretor [1..*] nacionalidade [1..*] categoria [1..*] sinopse obterReservaPendente() obterItemDisponivel() obterClasse()
Classe 0..n
nome 1 valorLocacao prazoDevolucao obterValor() obterPrazo()
1 0..n Item
numSerie dtAquisicao estado obter() obterLocacaoPendente() obterTitulo() obterTipoItem() atribuirEstado() estahDisponivel() ehDoTipo()
0..n
TipoItem
nome
Figura 07 Diagrama de Classes do Pacote ControleAcervo.
A Figura 08 apresenta o Diagrama de Classes referente ao pacote AtendimentoCliente. As classes Titulo, Item e TipoItem oriundas do pacote ControleAcervo, mostram a integrao entre esses subsistemas.
Cheque
banco agencia conta numero valor
0..n 1 Locacao Pagamento

data valor
Cliente
numInscricao nome dtNascimento sexo estahAtivo obter() estahEmDebito()
0..n
dtLocacao dtDevolucaoPrevista dtDevolucaoEfetiva valorCobrado multaCobrada estahPendente() calcularValorASerPago() existePagamento() calcularMulta() atribuirDtDevolucaoEfetiva() estahEmAtraso() criar() atribuirDtLocacao()
1..n
0..2 1
Item (from Controle Acervo)
0..n
TipoItem (from Controle Acervo)
Socio
cpf endereco telefoneResidencial localTrabalho telefoneComercial telefoneCelular
0..n 1 0..n Dependente
Reserva
dtReserva hrReserva dtComunicacao hrComunicacao ehDoTipo() estahPendente()
0..n 1 0..n
1..n
Titulo (from Controle Acervo)
Figura 08 Diagrama de Classes do Pacote AtendimentoCliente.
42
Captulo 4
2.3 Dicionrio de Dados 2.3.1 Pacote ControleAcervo Classe: representa as classes nas quais ttulos podem ser classificados. Estabelece o valor a ser pago nas locaes de itens e o prazo de devoluo em dias. - nome: nome da classe (Ex: lanamento, ouro, prata ou bronze) - valorLocacao: valor em reais (R$) a ser cobrado na locao de itens de ttulos classificados na classe. - prazoDevolucao: prazo em dias para ser feita a devoluo de itens dos ttulos classificados na classe.
<para visualizar os demais itens do dicionrio, acesse http://www.inf.ufes.br/~falbo>.
3. Modelo Comportamental A modelagem do comportamento dos objetos visa apoiar a identificao de atributos e operaes de classes. Nesta seo, so apresentados os Diagramas de Transio de Estados, os Diagramas de Sequncia e as descries das operaes das classes. Os resultados dessa atividade j foram espelhados nos Diagramas de Classes mostrados na seo anterior. 3.1 Diagramas de Grficos de Estados 3.1.1 Classe Item do Pacote ControleAcervo A Figura 09 mostra o diagrama de estados da classe Item. Os eventos mostrados dizem respeito realizao dos casos de uso ou aes dos mesmos, tal como Efetuar Nova Locao. Esse diagrama deu origem a uma atributo estado na classe Item, que indica o estado de um objeto dessa classe.
Anlise
43
Cancelar reserva (automaticamente ou no) [ existeReservaPendente [ existeReservaPendente do titulo ] do ttulo ]
[ naoexisteReservaPendente do titulo ]
Reservado
Cancelar reserva (automaticamente ou no) [ naoexisteReservaPendente do ttulo ]
Disponvel
Efetuar Devoluo [ existeReservaPendente do titulo ]
Efetuar Devoluo [ naoexisteReservaPendente do titulo ]
Efetuar Locao
Locado
Efetuar Locao
Efetuar Devoluo[item Inutilizado]
[ itemInutilizado ]
Inutilizado
[ itemInutilizado ]
Figura 09 Diagrama de Estados da Classe Fita do Pacote ControleAcervo. <para visualizar os demais diagramas de estado, acesse http://www.inf.ufes.br/~falbo>
3.2 Diagramas de Sequncia A seguir, so apresentados os Diagramas de Sequncia construdos neste projeto. Apenas os cursos normais dos casos de uso / fluxos de eventos dos casos de uso foram considerados para a elaborao desses diagramas e, portanto, na atividade de Projeto Detalhado das Operaes (Projeto de Objetos) da fase de Projeto, os cursos alternativos devem ser incorporados. A Figura 10 apresenta o diagrama de sequncia para o cenrio Efetuar Nova Locao do caso de Uso Efetuar Locao
44
: Funcionrio
: Aplicacao
: Cliente
clienteLocacao : Cliente
locacoesCliente : tituloDesejado : Locacao Titulo itensTitulo : Item
classeTitulo : Classe
novaLocacao : Locacao
itemDisponivel : Item
efetuarNovaLocacao (numInscricao, tituloDesejado, tipoItemDesejado)
obter (numInscricao)
clienteLocacao estahEmDebito( ) * estahEmAtraso( )
[clienteLocacao no est em Dbito] obterItemDisponivel (tipoItem)
* estahDisponivel( )
[item disponvel] ehDoTipo (tipoItem) itemDisponivel obterClasse( ) classeTitulo obterValor( ) obterPrazo( )
Captulo 4
<para visualizar os demais diagramas de seqncia, acesse

criar (clienteLocacao, itemDisponivel, valor, dtDevolucaoPrevista)
http://www.inf.ufes.br/~falbo>.
valor, dtDevolucaoPrevista alterarValorDtDevolucao (valor, dtDevolucaoPrevista)
Figura 10 Diagrama de Seqncia do cenrio Efetuar Nova Locao do Caso de Uso Efetuar Locao.
atribuirDtLocacao (dtCorrente) atribuirEstado ("locado")
se cliente desejar pagar, realizar caso de uso
"Efetuar Pagamento"
Anlise
45
3.3 Descrio das Operaes 3.3.1 Pacote ControleAcervo Classe: - obterValor: informa o valor de Locao estipulado pela classe. - obterPrazo: informa o prazo para devoluo estipulado pela classe. Item: - estahDisponivel: Boolean Retorna verdadeiro se o estado do item for disponvel, ou falso em caso contrrio. - ehDoTipo (tipoItem: TipoItem): Boolean Retorna verdadeiro se o tipo do item for igual a tipoItem, ou falso em caso contrrio. - obterLocacaoPendente: Locacao Retorna, caso exista, a locao pendente do item. - obterTitulo: Titulo Retorna o ttulo do item. - obterTipoItem: TipoItem Retorna o tipo de item do item. - atribuirEstado(novoEstado: String) Atribui o valor de novoEstado ao atributo estado do item. novoEstado s pode assumir um dos valores mostrados no diagrama de grfico de estados da classe Item, mostrado na Figura 3.1. - obter(numSerie: Integer): Item Retorna o item que tem o nmero de srie informado. Titulo: - obterItemDisponivel (tipoItem: TipoItem): Item
46
Captulo 4
Retorna, caso exista, um item disponvel do ttulo, que seja do tipo item especificado. - obterClasse: Classe Retorna a classe do ttulo. - obterReservaPendente: Reserva Retorna a reserva pendente mais antiga do ttulo. <para visualizar os demais descries de operaes, acesse http://www.inf.ufes.br/~falbo>.
Voc deve ter percebido como grande a complexidade da etapa de Anlise! Deve percebido isso, porque no Curso h uma disciplina especfica para tratar desse assunto. Agora hora de praticar. Acesse o ambiente e comece a produzir a Anlise da ferramenta que voc e seu grupo escolheram. Obviamente, voc deve se basear no documento de requisitos produzido na etapa anterior. Por hora, comece a pensar nas classes que surgiro. Pense nos atributos e relacionamento entre elas, e tambm nos estados em que os objetos originados podero estar. Anote tudo aqui e depois compartilhe com os colegas. ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ____________________________________________________
Anlise
47
Aps a leitura deste captulo, voc deve ser capaz de: Compreender as atividades envolvidas na Anlise. Entender a ligao dessas atividades com a Especificao de Requisitos. Avaliar se o seu conhecimento anterior de Anlise suficiente para produzir um sistema parecido com o estudo de caso. Elaborar documento de especificao de anlise para a sua aplicao.
48
Captulo 4
49
PROJETO
Aps passarmos pelas etapas Especificao de Requisitos e Anlise, chegamos etapa chave da nossa disciplina: o Projeto. Nessa etapa, teremos que pensar em uma srie de coisas que impactaro diretamente a distribuio e implementao das aplicaes cliente servidor. Agora vamos descer mais um degrau na escada da abstrao. O degrau mais alto o nosso mini-mundo, bastante abstrato e confuso. Descemos para a especificao de requisitos - um pouco menos abstrata e depois para a Anlise, quando a abstrao comea a diminuir mais notadamente. Vamos para um degrau com atividades bem menos abstratas: no Projeto, teremos que pensar em estatsticas de uso do nosso software, na distribuio geogrfica, nos usurios e nas funcionalidades que eles podero ou no utilizar. Na implementao, teremos descido totalmente a escada, transformando uma realidade inicialmente obscura em um produto. Neste captulo, utilizaremos uma estratgia um pouco diferente das anteriores. Iremos, primeiramente, estudar cada etapa e, depois, conversaremos sobre um layout de documento. Abrao e bons estudos.
5.1 hora de fazer CERA!

muito importante na fase de projeto identificar que tipos de operao os casos de uso realizaro. Ao levantar esses dados, preparamos o terreno para projetar nosso banco de dados (precisamos saber que operaes sero realizadas para pensarmos nas tabelas e no crescimento do mesmo). E se todos os casos de uso fizerem inseres? At na distribuio geogrfica as operaes tm papel fundamental. Se em um determinado local em que meu sistema estar funcionando acontecem a maior parte das operaes, vale a pena colocar a base de dados em um outro local, muito distante?
Para estimar as operaes, vamos utilizar as letras da palavra CERA C de Consultar, E de Excluir, R de Recuperar e A de Alterar.
50
Captulo 5
E como fazemos isso? Simples! Para cada caso de uso, vamos pensar que operaes sero realizadas pelas classes em cada cenrio, gerando um quadro. Vamos estudar o exemplo do caso de uso Efetuar Locao, da videolocadora Passatempo.
Cenrio/Classe Efetuar Nova Locao Alterar Dados de Locao Consultar Dados de Locao Cancelar Locao
Locao Cliente Titulo Item Classe C R R R R RA R R R R R ER R R R R R R R R
Quadro 05 Matriz CERA Efetuar Locao
Para entendermos por que a matriz ficou assim, temos que consultar os casos de uso. Vejamos o cenrio Efetuar Nova Locao. A descrio est em itlico e as observaes em azul:
Efetuar Nova Locao O funcionrio informa o nmero de inscrio do cliente, o ttulo que este deseja locar e o tipo de item desejado. Aps a informao do nmero do cliente, o sistema ter de recuperar o registro: R para Cliente. Ser necessrio consultar o ttulo: R para Ttulo. preciso saber o tipo de item: R para Item! Verifica-se se o cliente no est em dbito. Se o cliente no estiver em dbito, verifica-se se h itens do ttulo que sejam do tipo solicitado disponveis na locadora,. Se houver um item do tipo solicitado disponvel, calcula-se o valor da locao e a data de devoluo prevista. O valor da locao dado pelo valor da classe em que o ttulo est classificado, na data de locao. A data de devoluo prevista tambm determinada pela classe, adicionando-se, data de locao, o prazo em dias da classe. Precisamos saber o valor da classe do ttulo e o prazo para entrega, que depende da classe: R para Classe! Caso o funcionrio deseje, ele poder alterar o valor ou a data de devoluo prevista. Tecnologia em Anlise e Desenvolvimento de Sistemas
Projeto Uma nova locao criada, com a data corrente como data de locao. Opa! Vamos criar uma nova locao: C para locao! Caso o cliente deseje efetuar o pagamento, realiza-se caso de uso Efetuar Pagamento. Mas isso no nos interessa agora, trataremos em outro cenrio!
51
Faa as suas prprias matrizes CERA. Para isso, consulte os casos de uso definidos na especificao de requisitos e faa uma anlise semelhante ao exemplo do caso de uso Efetuar Locao. Para ficar bem organizado, faa uma tabelinha para cada caso de uso, em que cada linha um cenrio e cada coluna uma classe. Depois, acesse o ambiente e discuta com os colegas do seu grupo, at chegarem verso final. ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ____________________________________________________
52
Captulo 5
5.2 Distribuio geogrfica

Uma informao de grande relevncia para o projeto a sua distribuio geogrfica. A partir das informaes de localidades onde o sistema funcionar, podemos definir estratgias de acesso s funcionalidades e de distribuio do software. Nesta etapa, vamos realizar trs anlises: Caso de Uso por Localizao, Localizao /Classe e Caso de Uso / Classe. 5.2.1 Caso de uso por localizao Na anlise de caso de uso por localizao, vamos elaborar um quadro para cada caso de uso, com seus cenrios, e indicar quais lugares tero acesso a quais funcionalidades. Como exemplo, imaginemos que o nosso sistema de locadora funcionar em trs unidades das lojas: a matriz em Vitria, uma filial em Colatina e mais uma filial na Serra. Para o caso de uso Cadastrar Ttulo teramos o seguinte quadro:
Cenrio/ Localizao Incluir Novo Ttulo Alterar Dados de Ttulo Consultar Ttulo Excluir Ttulo
Vitria X X X X
Serra
Colatina
Quadro 06: Matriz Caso de uso/ localizao para Cadastrar Ttulo
Neste exemplo, podemos perceber que algumas operaes s so permitidas na matriz. As outras unidades podem apenas consultar ttulos, mas no incluir, alterar ou excluir. Pensando nisso, podemos j deduzir que as telas com as atividades no permitidas no precisam estar nas filiais. 5.2.2 Classes por localizao Relacionada matriz anterior, a matriz de Classe por localizao tem por objetivo determinar que operaes sobre as entidades sero realizadas em que localidades. Continuando com o exemplo do caso de uso Cadastrar Ttulo, temos:
Projeto
53
Localizao/Classe Vitria Serra Colatina
Ttulo CERA R R
Classe CERA R R
Distribuidor CERA R R
Reserva CERA CERA CERA
Quadro 07: Matriz Localizao / Classe para Cadastrar Ttulo
De acordo com o exemplo, na matriz sero realizadas todas as operaes sobre as classes. J nas filiais, a operao ser, na maioria das vezes, de consulta, sendo que apenas a classe reserva pode sofrer todas as operaes. 5.2.3 Caso de Uso / Classe Como vimos nos exemplos anteriores, nem sempre todas as operaes so realizadas em todas as localidades nas quais o sistema est funcionando. Mas, mesmo assim, temos que garantir a integridade do sistema. Ou seja, os dados devem estar corretos em todas as operaes. Imagine o caso do cadastro de ttulos na locadora. Nas matrizes anteriores, vimos que um ttulo s pode ser includo, alterado ou excludo na matriz, em Vitria. Suponha que a entrega de novos lanamentos j foi realizada, mas aps o cadastro em Vitria demore uma semana para as bases serem atualizadas nas filiais. Ou seja, aps a chegada dos ttulos, as filiais teriam que esperar uma semana para realizar locaes. Obviamente, a situao acima absurda e no poderia acontecer de jeito nenhum! E voc, como projetista, deve definir os tempos de sincronizao. Vejamos a matriz de Caso de uso/Classe para cadastrar ttulo:
Localizao/Classe Ttulo Classe Distribuidor 0 0 3 Incluir Novo Ttulo Alterar Dados de Ttulo 0 3 3 Excluir Ttulo 0 0 0
Quadro 08: Matriz Localizao/Classe para Cadastrar Ttulo
Reserva 0 0 0
Nesse quadro, os nmeros so o tempo mximo em horas para que as classes sejam notificadas das alteraes. Tempo 0 significa atualizao instntenea.
54
Captulo 5
Realize para o seu projeto as matrizes de distribuio geogrfica. Novamente, faa uma tabelinha para cada caso de uso! Depois, acesse o ambiente e discuta com os colegas do seu grupo, at chegarem verso final. _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________
Projeto
55
Neste captulo vimos algumas atividades bsicas do projeto. Algumas matrizes essenciais que do muito trabalho para serem realizadas, pois exigem a consulta constante aos documentos das fases de Especificao de Requisitos e Anlise. No prximo captulo, continuamos tratando da fase de projeto. Discutiremos a especificao de persistncia. Falaremos sobre as estatsticas necessrias, relacionadas ao banco de dados e discutiremos estratgias de distribuio de dados.
Aps a leitura deste captulo, voc deve ser capaz de: Compreender parte das atividades envolvidas no Projeto. Entender que a fase de projeto depende muito da fase de especificao de requisitos e Anlise. Entender o uso das matrizes para projetar o seu software Ser capaz de interpretar os casos de uso e o diagrama de classes para realizar suas prprias matrizes.
56
Captulo 5
57
PROJETO DE BANCO DE DADOS
Quando estamos tratando de aplicaes cliente-servidor indispensvel pensar no projeto de banco de dados. Provavelmente a base de dados de uma aplicao desse tipo no estar no mesmo local do qual a aplicao ser acessada. Alis, provvel que a base esteja distribuda por vrios locais. Sendo assim, temos que pensar em vrias questes relevantes para que a nossa aplicao no falhe e esteja sempre disponvel. Por exemplo: qual o tamanho total da minha base de dados? Ela crescer com o passar do tempo? Quanto? Meus servidores esto preparados para suportar o crescimento? Qual a melhor estratgia de distribuio para minha aplicao? Todas essas perguntas so extremamente importantes para ns. E sobre elas que vamos conversar neste captulo.
6.1 Estimando o Tamanho de Banco de Dados

Para estimar o tamanho e o crescimento do nosso banco, primeiramente temos que obter o tamanho de cada tipo do Sistema Gerenciador de Banco de Dados (SGDB) escolhido. Vejamos um exemplo do tamanho de alguns tipos, no MySQL:
58
Captulo 6
Tipo de Campo TINYINT SMALLINT MEDIUMINT INT INTEGER BIGINT FLOAT(X) FLOAT DOUBLE DOUBLE PRECISION REAL DECIMAL(M,D) NUMERIC(M,D) VARCHAR(n)
Tamanho de Armazenamento 1 byte 2 bytes 3 bytes 4 byte 4 bytes 8 bytes 4 ou 8 bytes 4 bytes 8 bytes 8 bytes 8 bytes M+2 bytes se D > 0, M+1 bytes se D = 0 M+2 bytes se D > 0, M+1 bytes se D = 0 n +1 bytes
Quadro 09: tamanho de alguns tipos no MySQL
A partir dessa informao, voc dever calcular o tamanho inicial da base para cada tabela do seu modelo relacional. Vejamos um exemplo, levando em considerao a tabela Titulo do projeto da locadora Passatempo:
Titulo idoTitulo: INTEGER idoClasse: INTEGER idoCategoria: INTEGER idoDistribuidor: INTEGER nome: VARCHAR(20) nomeOriginal: VARCHAR(20) sinopse: VARCHAR(300) ano: INTEGER
Figura 11 Tabela Titulo.
Tabela Ttulo idoClasse idoClasse idoCategoria idoDistribuidor nome nomeOriginal sinopse ano Total:
Tamanho (bytes) 4 4 4 4 21 21 301 4 363
Observaes
Tabela 01 Tamanho dos campos no MySQL. Tecnologia em Anlise e Desenvolvimento de Sistemas
Projeto de Banco de Dados
59
preciso realizar este clculo para cada tabela. Depois, soma-se o total de cada uma e temos o tamanho inicial da base de dados.
Para realizar a estimativa de tamanho, voc j dever ter pronto o diagrama relacional. Essa etapa realizada mais adiante, junto com o projeto arquitetural. Voc pode fazer as estimativas de tamanho da base aps a realizao do modelo relacional. No entanto, as estimativas aparecem antes, para que o leitores do seu projeto tenham logo uma idia do tamanho do mesmo, sem precisarem l-lo na ntegra.
6.2 Estatstica de Crescimento

Na seo anterior, estimamos apenas o tamanho inicial da base de dados. Precisamos, agora, estimar o crescimento dos dados, quando o banco comear, efetivamente, a ser utilizado. Para isso, recomenda-se levantar 3 estatsticas: crescimento do nmero de registros por tabela, crescimento mensal por tabela (em Kbytes) e crescimento anual por tabela (em Kbytes). Para entendermos melhor, aplicaremos as estatsticas para a tabela Ttulo. Vamos supor que a locadora Passatempo receba cerca de 10 novos lanamentos por ms. No primeiro ms, sero registrados 1000 ttulos j existentes. Assim, o crescimento de registros na tabela ttulo assume o seguinte grfico:
Crescimento de registros mensais de ttulos
Dez Nov Out Set Ago Ms Jul Jun Mai Abr Mar Fev Jan Dez 0 0 200 400 600 Ttulos 800 1000 1200 1110 1100 1090 1080 1070 1060 1050 1040 1030 1020 1010 1000
Figura 12 Crescimento de registros mensais de ttulos
60
Captulo 6
Se a locadora recebe 10 ttulos por ms e cada linha da tabela ocupar 363 bytes (ver Tabela 1), conseguimos calcular o crescimento do espao ocupado pela nossa tabela. Veja o grfico abaixo:
Crescimento da Tabela Ttulos

Dez Nov Out Set Ago Jul Ms Jun Mai Abr Mar Fev Jan Dez 0 0 100 200 KBytes 300 400 500 393 390 386 383 379 376 372 369 365 362 358 354
Figura 13 Crescimento mensal da tabela Ttulos
A partir do cresimento mdio mensal, podemos nos programar para o crescimento anual. Para esse clculo, multiplicamos os meses (12) pelo crescimento mensal (10 registros X 363 bytes por registro), ou seja, 12 x 10 x 363 = 43560 bytes por ano. Em Kbytes: 43560 / 1024 = 42,5 Kbytes/ ano. Vamos considerar 43 Kbytes/ano. Veja o grfico:
Crescimento anual tabela Titulo
2016 2015 2014 Ano 2013 2012 2011 2010 2009 0 200 694 651 608 565 522 479 436 393 400 KBytes 600 800
Figura 14 - Crescimento anual da tabela Titulo.
61
Alguns pontos importantes a lembrar: As estimativas devem ser feitas para todas as tabelas. O cresimento mensal e anual podem ser feitos para cada tabela ou pode refletir o crescimento de todas. importante ficar atento aos crescimentos sazonais. Imagine que na locadora Passatempo, durante o ms de setembro, cheguem os lanamentos do vero americano e o registro de ttulos seja 20. Isso deve ser levado em considerao.
Comece a pensar nas tabelas do seu banco de dados. Voc pode fazer isso se baseando no diagrama de classes da fase de anlise. Provavelmente ele sofrer algumas mudanas, mas desde j voc conseguir identificar as tabelas principais. ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ____________________________________________________
62
Captulo 6
6.3 Estratgias de Distribuio

Um parte importante do projeto de banco de dados a distribuio das tabelas geograficamente. Para faz-lacorretamente, precisamos pensar em vrios aspectos. Uma boa fonte de consulta so as matrizes CERA, desenvolvidas no captulo anterior. Precisamos saber quais operaes podem ser realizadas em que localidades e tambm quais usurios podero realizar quais operaes em que tabelas. Um fator essencial o tempo em que as tabelas devem refletir as atualizaes. Como sero distribudos os dados entre as localidades? A infraestrutura disponvel ser capaz de suportar os requisitos funcionais e no funcionais? Para entender melhor, vamos estudar um exemplo de distribuio. Imaginemos uma aplicao que funcionar nas cidades de Vitria (matriz), no Rio de Janeiro (filial) e em So Paulo (filial). A Figura 15 apresenta a aplicao:
Vitria
Tabela A Tabela B Tabela C Tabela D
Rio de Janeiro
So Paulo
Vitria
Tabela A VT - XX - 111 VT - YY - 222 RJ - ZZ - 333 SP - LL - 444 SP - NN - 555
Tabela B VT - AA - 1 VT - BB - 1 RJ - CC - 2 RJ - DD - 2 SP - EE - 1
Tabela C VT - A1A1 VT - B1B1 RJ - C1C1 RJ - D1D1 SP - E1E1
Tabela C Local VT - A1A1 VT - B1B1
Tabela D VT - FFF1 VT - GGG1 RJ - HHH1 RJ - III1 SP - JJJ1
Rio de Janeiro
Tabela A RJ - ZZ - 333
Tabela B RJ - CC RJ - DD
Tabela C Local RJ - C1C1 RJ - D1D1
DB LinkTabela D VT - FFF1 VT - GGG1 RJ - HHH1 RJ - III1 SP - JJJ1
So Paulo
Tabela A SP - LL - 444 SP - LL - 555
Tabela B SP - EE
Tabela C Local SP - E1E1
DB LinkTabela D VT - FFF1 VT - GGG1 RJ - HHH1 RJ - III1 SP - JJJ1
Figura 15 Exemplo de distribuio Tecnologia em Anlise e Desenvolvimento de Sistemas
63
Para esse projeto, foram tomadas as seguintes decises: Tabela A Descrio: Em Vitria, essa uma tabela central que contm todos os dados de todas as localidades. Nos bancos de dados do RJ e de SP, a tabela existe, porm contm apenas os dados da respectiva regio. Inseres/atualizaes/excluses/consultas: So realizadas apenas na base de dados local. Periodicamente executada uma rotina batch que atualiza a base central de Vitria. Prs: Est de acordo com a distribuio geogrfica, pois as pessoas de uma regio atuam apenas em dados da sua regio. Existe uma regio que controla os dados de todas as outras regies. Quanto segurana, boa opo, pois as pessoas de uma regio (exemplo: SP) s podero acessar os dados daquela regio. Porm, h a exceo de Vitria, pois seus usurios podero acessar dados de todas as regies. Porm, nesse caso, esse o objetivo, j que a matriz est em Vitria. O desempenho/tempo de resposta bem adequado, uma vez que o acesso sempre local e a atualizao da tabela central feita via batch, no interferindo no trabalho do usurio.
Batch aqui se refere a alguma tarefa agendada que ocorrer futuramente. No caso das replicaes de dados do banco, significa que a alterao ser feita em uma tabela e, depois, em um determinado momento, as outras sero atualizadas.
Contras: Os usurios de Vitria esto podendo acessar dados de outras regies. Isso o desejado nesse caso, mas pode no o ser em outros. Ou seja, pode ser desejado que, mesmo que Vitria seja uma base central, seus usurios possam at acessar os dados de outras regies, mas incluiam, alterem e excluam dados apenas de Vitria. Os usurios da base central (Vitria) tero acesso aos dados atualizados de outras localidades com certa defasagem, uma vez que a atualiProjeto Cliente Servidor
64
Captulo 6
zao via batch. Isso pode no ser desejado em algumas situaes. Mesmo que os usurios s possam criar/atualizar/excluir dados apenas na sua regio, pode ser necessrio consultar os dados de outras regies. Nesse caso, haveria a possibilidade de controlar isso por meio de programas. Tabela B Descrio: Em Vitria, essa uma tabela central que contm todos os dados de todas as localidades. Nos bancos de dados do RJ e de SP, a tabela existe, porm contm apenas os dados da respectiva regio e apenas algumas colunas. Inseres/atualizaes/excluses/consultas: So realizadas tanto na base de dados local como na base central de Vitria. Prs: Est de acordo com a distribuio geogrfica, pois as pessoas de uma regio atuam apenas em dados da sua regio, e existe uma regio que controla os dados de todas as outras regies. Est acessando apenas os atributos que interessam. Quanto segurana, boa opo, pois as pessoas de uma regio (exemplo: SP) s podero acessar os dados daquela regio. Porm, h a exceo de Vitria, pois seus usurios podero acessar dados de todas as regies. Porm, nesse caso, esse o objetivo. Os usurios de Vitria enxergaro os dados sempre atualizados. Contras: Os usurios de Vitria esto podendo acessar dados de outras regies. Isso o desejado nesse caso, mas pode no o ser em outros. Ou seja, pode ser desejado que, mesmo que Vitria seja uma base central, seus usurios possam at acessar os dados de outras regies, mas incluam, alterem e excluam dados apenas de Vitria. Os usurios da base central (Vitria) tero acesso aos dados atualizados de outras localidades com certa defasagem, uma vez que a atualizao via batch. Isso pode no ser desejado em algumas situaes. O desempenho/tempo de resposta deixa a desejar, uma vez que a cada insero/atualizao/excluso haver tambm o acesso base central (remota).
65
Tabela C Descrio: Essa tabela existe em todas as localidades, com todos os dados de todas as localidades. Porm, em cada localidade, existe tambm uma tabela local. Inseres/atualizaes/excluses/consultas: As inseres, atualizaes e excluses so realizadas apenas na tabela local. Porm, no mesmo instante atualizada a tabela que possui todos os valores, que fica na mesma regio. A atualizao dos dados das demais regies feita periodicamente. Esse batch difere do batch da Tabela A, pois no atualizada uma nica tabela (l era a tabela A de VT) e sim a tabela C de todas as regies. As consultas so realizadas na tabela com todos os dados. Prs: Est de acordo com a distribuio geogrfica, pois as pessoas de uma regio podem apenas incluir/alterar/excluir dados da sua regio. Os usurios de cada regio podem consultar os dados das demais regies. Quanto segurana, boa opo, pois as pessoas de uma regio s podero incluir/alterar/excluir os dados daquela regio, diferentemente das opes anteriores, em que na base central era possvel acessar tudo. O desempenho/tempo de resposta bem adequado, uma vez que o acesso sempre local e a atualizao das demais tabelas feita via batch, no interferindo no trabalho do usurio. Contras: Maior quantidade de tabelas e, consequentemente, de espao de armazenamento. Maior possibilidade de inconsistncia de dados, uma vez que uma mesma informao est em vrias tabelas. Caso o batch falhe alguma vez, as tabelas podem ficar com valores diferentes. Ao realizar uma consulta de dados de outra localidade, os usurios podem ter acesso a dados desatualizados, uma vez que eles s so atualizados com o batch.
66
Captulo 6
Tabela D Descrio: Essa tabela existe apenas em Vitria, com todos os dados de todas as localidades. Nas demais localidades existe penas um link para essa tabela. Inseres/atualizaes/excluses/consultas: So feitas diretamente na tabela de Vitria. Prs: Os usurios de cada regio tm acessos aos dados de todas as regies. Simplicidade, uma vez que existe apenas uma nica tabela. Maior garantia da consistncia dos dados no h necessidade de replicao de dados. Os usurios tero sempre acesso aos dados atualizados. Contras: No est de acordo com a distribuio geogrfica, uma vez que o acesso no local e sim em Vitria. No boa opo em termos de segurana, pois as pessoas de uma regio tero acesso aos dados de todas as regies. O desempenho/tempo de resposta no adequado, uma vez que o acesso sempre remoto (Vitria).
Agora com voc. Comece a pensar na distribuio do seu sistema e justifique por que fez suas escolhas. Quando elaborar o modelo relacional definitivo, volte aqui e atualize as informaes. ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ____________________________________________________
67
Neste captulo vimos alguns aspectos importantes do projeto de banco de dados. Voc deve ter percebido que as tarefas envolvidas no so to simples e impactam no futuro da sua aplicao cliente servidor. importante, ento, uma boa documentao de tudo que for realizado e um cuidado especial no momento de levantar as estatsticas. A distribuio geogrfica, na maioria das vezes, depende das unidades do cliente, mas dever do projetista do sistema adequ-lo realidade proposta. Isso nem sempre fcil. No prximo captulo vamos estudar uma proposta de arquitetura cliente servidor, na qual voc dividir sua aplicao em camadas com funcionalidades especficas. Vamos l?!
Aps a leitura do captulo, voc deve ser capaz de: Compreender a importncia do projeto de banco de dados. Saber as principais fases do projeto de banco. Ser capaz de levantar estatsticas reais sobre um projeto de banco de dados. Ser capaz de definir uma arquitetura de distribuio e de justificar cada deciso tomada.
68
Captulo 6
69
PROJETO DE ARQUITETURA DO SISTEMA
Neste captulo vamos conversar sobre a arquitetura de uma aplicao cliente servidor. Estudaremos a diviso em camadas, baseada no MVC e em algumas boas prticas para que a sua arquitetura seja eficiente. Voc ter de se lembrar de muitas coisas da disciplina de Anlise, pois os diagramas UML que voc aprendeu nessa disciplina vo aparecer bastante. Os conceitos da disciplina de Banco de Dados tambm sero necessrios, principalmente o mapeamento de classes para modelo relacional. Este um dos principais captulos desta disciplina e voc provavelmente utilizar os conceitos aqui aprendidos na sua vida profissional. Ento, aproveite o mximo e tire dvidas com os tutores no ambiente virtual. Bons estudos!
7.1 Dividir para conquistar!

J estudamos, no Captulo 2, o modelo MVC. Ele ser a soluo para resolver vrios problemas de arquitetura! Sempre que for planejar uma arquitetura, d uma olhada se o MVC lhe ser til. No nosso caso, ele cai como uma luva. A diviso de camadas proposta por ele traz vantagens para a nossa aplicao. Baixo aclopamento, interfaces bem definidas e facilidade de manuteno. A nica parte que o MVC no cobre a gerncia de dados. Isso porque ele antigo, e no se pensou nisso quando foi criado. Porm, Coad et al. (1993) , apresentaram uma tima soluo, que tambm foi adotada pelo professor Falbo. Ao invs de trabalharmos com trs camadas, trabalharemos com 4, incluindo a gerncia de dados. Veja o esquema e a explicao de cada camada na Figura 16:
70
Captulo 7
Componente de Domnio do Problema (CDP)
Componente de Interao Humana (CIH)
Componente de Gerncia de Tarefa (CGT)
Componente de Gerncia de Dados (CGD)
Figura 16 Arquitetura Bsica de Projeto Orientado a Objetos (Coad et al., 1993)
A camada Componente de Domnio do Problema (CDP) corresponde ao tratamento direto dos requisitos do usurio. Essa camada trata das regras de negcio, aquelas que levantamos nos casos de uso. A camada Componente de Interao Humana (CIH) corresponde s interfaces grficas que sero apresentadas aos usurios. Aqui no deve haver processamento de informaes, mas apenas visualizao de dados.
Algumas dicas para uma interface grfica de qualidade (FALBO, 2003): - Apresente o progresso de operaes longas aos usurios. Eles ficaro mais calmos. Para isso, modifique o ponteiro do mouse ou utilize barras de progresso. - O vocabulrio das mensagens de sucesso e erro deve ser claro e o usurio capaz de entend-lo. Nada de cdigos inteligveis. - Pea sempre confirmao quando o usurio solicitar excluso. Ele pode ter se enganado. - Permita reverso das operaes. - Mostre apenas informaes relevantes da operao que est sendo realizada.
A camada Componente de Gerncia de Tarefas (CGT) contm o cdigo responsvel por coordenar as tarefas. Ela faz o meio de campo entre a interface grfica e o domnio do negcio. A camada Componente de Gerncia de Dados (CGD) a responsvel pela persistncia dos objetos. Tudo relacionado a armazenamento e recuperao de objetos responsabilidade dessa camada. Para entender melhor a diviso por camadas, estudaremos um exemplo
Projeto de Arquitetura do Sistema
71
completo, inclusive com implementao. Vamos acompanhar na prxima seo a especificao de arquitetura para o pacote Controle de Controle de Acervo. Voc ter a oportunidade de visualizar e implementar o fluxo completo para a insero de um ttulo na aplicao.
7.2 Exemplo de Projeto Orientado a Objetos (Falbo, 2003)

A organizao de classes em pacotes deve ser o ponto de partida para a definio da arquitetura do sistema, j que um meio de estabelecer nveis de abstrao para o modelo. Esses nveis de abstrao podem ser organizados em camadas e, assim, tratados separadamente durante a fase de projeto. A organizao de classes em pacotes til tambm para permitir a produo de componentes para reutilizao no futuro. Neste trabalho, foram utilizadas duas formas complementares de agrupamento de classes em pacotes: primeiramente, pelo domnio do problema, aproveitando os subsistemas definidos na fase de anlise, e, depois, por esteretipos, tendo sido utilizados os esteretipos propostos por Coad e Yourdon (Coad93). Sendo assim, o diagrama de pacotes de nvel mais alto, mostrado na Figura 17, praticamente o mesmo da fase de anlise, exceto pela introduo do pacote Utilitario, que trata classes reutilizveis em outros contextos. O diagrama da Figura 17 mostra as dependncias entre os subsistemas, indicando que os pacotes AtendimentoCliente e ControleAcervo solicitam servios ao pacote Utilitario. Mantendo a coerncia com o diagrama da fase de anlise, o pacote AtendimentoCliente solicita servios do pacote ControleAcervo. Os pacotes AtendimentoCliente e ControleAcervo foram decompostos em outros pacotes, segundo os esteretipos, dando origem a novos diagramas de pacotes, a serem discutidos nas prximas sees.
Atendimento Cliente
Controle Acervo
Utilitario
Figura 17 Diagrama de Pacotes Projeto Cliente Servidor
72
Captulo 7
7.3 Pacote Controle de Acervo

Esse pacote foi decomposto no diagrama de pacotes da Figura 18, agora tomando por base os esteretipos.
UtilitarioPessoa (from Utilitario)
GT_ControleAcervo
DP_Controle Acervo
IU_Controle Acervo
GD_Controle Acervo
UtilitarioInterfaceGrafica (from Utilitario)
Figura 18 Diagrama de Pacotes do Pacote ControleAcervo.
7.3.1 Pacote DP_ControleAcervo A Figura 19 apresenta o Diagrama de Classes referente Componente do Domnio do Problema do pacote ControleAcervo. importante realar que as alteraes introduzidas em relao ao modelo de anlise dizem respeito a requisitos no funcionais importantes para o sistema, tais como: - Facilidade de uso: para apoiar a construo de interfaces amigveis, foram criadas as classes Ator, Diretor, Categoria e Pas. - Reusabilidade: visando construir classes reutilizveis em domnios diversos, optou-se por desenvolver uma hierarquia de Pessoa (pacote UtilitarioPessoa), na qual foi inserida a classe Distribuidor.
73
Pais
(from UtilitarioPessoa)
+nacionalidade PessoaJuridica
(from UtilitarioPessoa)
0..*
Diretor nome : String
0..* Titulo nome : String ano : Integer sinopse : String nomeOriginal : String obter() obterFitaDisponivel() obterValorLocacao() obterReservaDaVez() obterNome() 1 0..* Fita numSerie : Integer dtAquisicao : Date estado : String disponivel() obter() obterLocacaoPendente() obterTitulo() atribuirEstado() criar() 1..* 0..*
Classe descricao : String preco : Currency prazo : Integer obterPreco()
Distribuidor
0..*
0..*
0..*
0..* 1 Categoria nome : String
0..* Ator nome : String
Figura 19 Pacote DP_ControleAcervo
Para que o projeto fique mais claro para voc, foi realizada a implementao resumida da Classe Ttulo, a partir da proposta de Falbo (2003). Isso prova que, com uma boa documentao, fica fcil implementar o cdigo. O exemplo original no possui os cdigos, mas entendendo a documentao ficou fcil codificar. Classe Titulo:
package DP_ControleAcervo; import GD_ControleAcervo.TituloPersistente; public class Titulo { private String nome; private int ano; private String sinopse; private String nomeOriginal; /*Para simplificar, no foram criadas as classes
Classe, Categoria, Distribuidor e Diretor.

Lembre-se que na implementao completa voc dever colocar
74
Captulo 7
um objeto de cada classe aqui.*/ public Titulo(){ } public Titulo(String nome, int ano, String sinopse, String nomeOriginal){ this.nome = nome; this.ano = ano; this.sinopse = sinopse; this.nomeOriginal = nomeOriginal; } /*No est no diagrama, mas necessrio*/ public boolean criar(){ TituloPersistente tp = new TituloPersistente(); return tp.salvar(this);
/*Demais mtodos do diagrama suprimidos para simplificao. Ser implementada apenas a inser o de um Ttulo.*/ //mtodos get e set. public int getAno() { return ano; } public void setAno(int ano) { this.ano = ano; } public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getNomeOriginal() { return nomeOriginal; } public void setNomeOriginal(String nomeOriginal) { this.nomeOriginal = nomeOriginal; } public String getSinopse() { return sinopse; } public void setSinopse(String sinopse) { this.sinopse = sinopse; }
75
7.3.2 Pacote IU_ControleAcervo Neste pacote devem estar as classes de interface grfica. Geralmente desenvolvida uma interface para cada cenrio de caso de uso que precise de interao com o usurio. A situao ideal, se for possvel, desenvolver uma classe me com componentes em comum. Para o nosso exemplo, duas classes foram desenvolvidas. Observe os cdigos das classes JanCadastrarTitulo e JanPrincipal. Classe JanCadastrarTitulo:
package IU_ControleAcervo; import java.awt.*; import javax.swing.* import GT_ControleAcervo.AplControlarTitulo; public class JanCadastrarTitulo extends JInternaFrame implements ActionListener { protected JLabel jl_nome; protected JTextField jt_nome; protected JLabel jl_ano; protected JTextField jt_ano; protected JLabel jl_sinopse; protected JTextField jt_sinopse; protected JLabel jl_nomeOriginal; protected JTextField jt_nomeOriginal; protected JButton salvar; protected JButton limpar; protected GridLayout layout; JPanel mainPanel = new JPanel(); JPanel infoPanel = new JPanel(); JPanel buttonPanel = new JPanel(); JanCadastrarTitulo(){ layout = new GridLayout(); /*Foram criados vrios painis, um para cada tipo de informao.*/ mainPanel.setLayout(new BorderLayout()); infoPanel.setLayout(layout); buttonPanel.setLayout(new FlowLayout());
76
Captulo 7
setBounds(60, 50,300,180); jl_nome = new JLabel(Nome:); jt_nome = new JTextField(); jl_ano = new JLabel(Ano:); jt_ano = new JTextField(); jl_sinopse = new JLabel(Sinopse:); jt_sinopse = new JTextField(); jl_nomeOriginal = new JLabel(Nome Original:); jt_nomeOriginal = new JTextField(); salvar = new JButton(Salvar); limpar = new JButton(Limpar); salvar.addActionListener(this); limpar.addActionListener(this); addInfoInPanel(jl_nome, jt_nome); addInfoInPanel(jl_ano, jt_ano); addInfoInPanel(jl_sinopse, jt_sinopse); addInfoInPanel(jl_nomeOriginal, jt_no meOriginal); buttonPanel.add(salvar); buttonPanel.add(limpar); mainPanel.add(infoPanel, BorderLayout.NORTH); mainPanel.add( buttonPanel,BorderLayout.CENTER); add(mainPanel);
} /*Este mtodo adapta o gridLayout para receber uantos labels e campos de textos quisermos.*/ public void addInfoInPanel(JLabel label, JTextField textField){ layout.setRows(layout.getRows() + 1); infoPanel.add(label); infoPanel.add(textField); } //Tratador de eventos do boto Salvar e Limpar. public void actionPerformed(ActionEvent e) { if(e.getSource() == salvar){ /*Chama funo da camada de gerncia de
77
tarefas. Aqui podemos apenas apresentar e obter informaes para o usurio. Processamentos de negcio so passados para outra camada.*/ if(AplControlarTitulo.incluirTitulo( jt_nome.getText(), Integer.parseInt( jt_ano.getText()), jt_sinopse.getText(), jt_nomeOriginal.getText())){
JOptionPane.showMessageDialog(
}else
);
JOptionPane.PLAIN_MESSAGE
null, Ttulo cadastrado com Sucesso, Resultado,
} if(e.getSource() == limpar){ jt_nome.setText(); jt_ano.setText(); jt_sinopse.setText(); jt_nomeOriginal.setText(); }
JOptionPane.showMessageDialog( null, Erro ao inserir ttulo, Resultado, JOptionPane.WARNING_MESSAGE );
Classe JanPrincipal:
package IU_ControleAcervo; import java.awt.event.*; import javax.swing.*; /*Cdigo da janela principal da aplicao*/ public class JanPrincipal extends JFrame{
78
Captulo 7
JMenu mainMenu; JMenuItem titulosMenu; JInternalFrame cadTitulosWindow; public JanPrincipal() { super(Locadora Passatempo); mainMenu = new JMenu(Cadastros); titulosMenu = new JMenuItem(Ttulos); titulosMenu.addActionListener( new ActionListener(){ public void ActionPerformed(ActionEvent e) { cadTitulosWindow. setVisible(true); }}); mainMenu.add(titulosMenu); JMenuBar bar = new JMenuBar(); setJMenuBar(bar); bar.add(mainMenu); setBounds(100,100,400,400); setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE); JDesktopPane desktop = new JDesktopPane(); add(desktop); cadTitulosWindow = new JanCadastrarTitulo(); cadTitulosWindow.setClosable(true); desktop.add(cadTitulosWindow); setVisible(true);
D uma olhada na documentao de interface grfica para o pacote IU_AtendimentoCliente no site www.inf.ufes.br/~falbo.
7.3.3 Pacote GT_ControleAcervo A Figura 20 apresenta o Diagrama de Classes referente ao Componente de Gerncia de Tarefas do pacote ControleAcervo.
79
AplCadastrarPais incluirNovoPais() alterarDadosPais() consultarPais() excluirPais() 0..1 1 AplControlarTitulo incluirNovoTitulo() alterarDadosTitulo() 0..1 consultarTitulo() excluirTitulo() incluirNovoAtor() alterarDadosAtor() consultarAtor() excluirAtor() incluirNovoDiretor() alterarDadosDiretor() consultarDiretor() excluirDiretor()
AplCadastrarFita incluirNovaFita() alterarDadosFita() consultarFita() excluirFita() 0..1 1 AplControleAcervo 1 1 1 1 0..1 0..1 AplCadastrarDistribuidor incluirNovoDistribuidor() alterarDadosDistribuidor() consultarDistribuidor() excluirDistribuidor()
0..1 AplCadastrarClasse incluirNovaClasse() alterarDadosClasse() consultarClasse() excluirClasse()
AplCadastrarCategoria incluirNovaCategoria() alterarDadosCategoria() consultarCategoria() excluirCategoria()
Figura 20 Diagrama de Classes do Pacote GT_Controle Acervo.
A classe AplCadastrarTitulo trata do caso de uso Cadastrar Ttulo e dos casos de uso fortemente relacionados a ele, a saber: Cadastrar Ator e Cadastrar Diretor. Esses casos de uso foram agrupados em uma nica classe de aplicao, devido ao fato de, ao se cadastrar um ttulo, se poder querer cadastrar novas informaes de atores e diretores. As demais classes lidam com seus respectivos casos de uso, exceto a classe AplControleAcervo, que d forma aplicao Controle de Acervo como um executvel. Veja o cdigo desenvolvido para as classes AplControlarTitulo e AplControleAcervo: Classe AplControlarTitulo:
package GT_ControleAcervo; import DP_ControleAcervo.Titulo; public class AplControlarTitulo { public static boolean incluirTitulo( String nome, int ano, String sinopse,
80
Captulo 7
String nomeOriginal){ Titulo t = new Titulo( nome, ano, sinopse, nomeOriginal); return t.criar(); } /*Demais mtodos da classe. Ainda no implementados.*/ public static void ConsultarTitulo(){}; public static void excluirTitulo(){}; public static void incluirNovoAtor(){}; public static void alterarDadosAtor(){}; public static void consultarAtor(){}; public static void excluirAtor(){}; public static void incluirNovoDiretor(){}; public static void alterarDadosDiretor(){}; public static void consultarDiretor(){}; public static void excluirDiretor(){};
Classe AplControleAcervo: package GT_ControleAcervo; import IU_ControleAcervo.JanPrincipal; public class AplControleAcervo { /*Classe principal da aplicao*/ public static void main(String args[]){ new JanPrincipal(); } }
81
7.3.4 Pacote GD_ControleAcervo A persistncia dos objetos deste sistema ser realizada em um banco de dados relacional. Assim, interessante procurar minimizar os impactos da tecnologia de bancos de dados sobre o sistema. Optou-se, portanto, por trabalhar com classes-sombra responsveis pela interao direta com o banco relacional e, consequentemente, com conhecimento de cdigo SQL. Para tal, foi utilizada a infra-estrutura genrica de persistncia. Em tal infra-estrutura, cada classe a ser persistida tem uma correspondente classe-sombra, responsvel pela interao com a base de dados relacional, como mostra a Figura 21.
ClasseBaseSombra
(from UtilitarioGerenciaDados)
CategoriaPersistente DiretorPersistente
FitaPersistente
AtorPersistente
PaisPersistente ClassePersistente
TituloPersistente
DistribuidorPersistente
Figura 21 Diagrama de Classes do Pacote GD_ControleAcervo.
Foi necessrio construir um Diagrama Relacional, mapeando as classes e objetos em tabelas e linhas. O Diagrama Relacional para o pacote ControleAcervo apresentado na Figura 22. Nesta figura, as chaves primrias aparecem na parte superior e as chaves transpostas so os primeiros itens da parte inferior. importante ressaltar que, no mapeamento da hierarquia de herana Pessoa, PessoaJuridica e Distribuidor, optou-se por criar apenas tabelas para classes concretas, no caso, Distribuidor. Sendo assim, todas as relaes e os atributos das superclasses foram mapeados na tabela correspondente classe concreta Distribuidor. Essa deciso decorre de, neste sistema, no haver processamento sobre as superclasses, mas apenas na subclasse concreta. Outro detalhe importante que, como a implementao acontecer no SGDB MySQL, no ser necessrio se preocupar com a sequncia dos cdigos chave, j que no MySQL existe auto incremento. Para outras bases de dados, como Oracle, existem os procedimentos chamados SEQUENCE, que implementam a sequencialidade de atributos identificadores.
82
Captulo 7
Fita idoFita: Long Integer idoTitulo: Integer numSerie: Long Integer dtAquisicao: Date/Time estado: Text(20) Ator idoAtor: Integer nome: Text(20) Distribuidor idoDistribuidor: Integer idoBairro: Integer razaoSocial: Text(20) cnpj: Long Integer pessoaContato: Text(20) rua: Text(40) numero: Text(10) complemento: Text(10) cep: Integer
Titulo idoTitulo: Integer idoClasse: Integer idoCategoria: Integer idoDistribuidor: Integer nome: Text(20) nomeOriginal: Text(20) sinopse: Memo ano: Integer
Categoria idoCategoria: Integer nome: Text(20) TituloDiretor idoTitulo: Integer idoDiretor: Integer Diretor idoDiretor: Integer nome: Text(20)
TituloAtor idoAtor: Integer idoTitulo: Integer
Classe idoClasse: Integer descricao: Text(20) preco: Currency prazo: Integer Pais idoPais: Integer nome: Text(20) sigla: Text(3) Estado idoEstado: Integer nome: Text(20) sigla: Text(2)
TituloNacionalidade idoTitulo: Integer idoPais: Integer
Bairro idoBairro: Integer idoCidade: Integer nome: Text(20)
Cidade idoCidade: Integer idoEstado: Integer nome: Text(20)
Figura 22 Diagrama Relacional do Pacote GD_ControleAcervo
Implementao do pacote GD_ControleAcervo para Titulo: ClasseBaseSombra:

package UtilitarioGerenciaDados; import java.sql.*; public class ClasseBaseSombra { public static Connection conn = null; private String url = jdbc:mysql://localhost:3306/; private String dbName = locadora; private String driver = com.mysql.jdbc.Driver; private String userName = root; private String password = root; private String expressao; protected String tabela; /*valores dos campos separados por,. Quando string, colocar entre aspas simples.*/ protected String values; protected String fields; public void connectMySQL(){ Tecnologia em Anlise e Desenvolvimento de Sistemas
83
try{ if(conn == null){

Class.forName(driver). newInstance();
conn = DriverManager. getConnection( url+dbName, userName, password); } }catch (Exception e) {

de excees*/
/*obviamente precisamos melhorar o tratamento e.printStackTrace(); }
} public boolean montaExpressaoSalvar(){ expressao = INSERT INTO + tabela + ( + fields + ) + VALUES ( values + ); ; try{
Statement st = conn.createStatement();
st.execute(expressao); return true; } catch (SQLException s){ return false; } } }
84
Captulo 7
Classe TituloPersistente: package GD_ControleAcervo; import DP_ControleAcervo.Titulo; import UtilitarioGerenciaDados.ClasseBaseSombra;

public class TituloPersistente extends ClasseBaseSombra { public boolean salvar(Titulo t){ tabela = TITULO; fields = nome, nomeOriginal, sinopse, ano; values = + t.getNome() + , + t.getNomeOriginal() connectMySQL(); return montaExpressaoSalvar(); } } +,+ t.getSinopse() + , + t.getAno();
Cdigo de Criao do Banco de Dados.
CREATE DATABASE LOCADORA; USE LOCADORA; CREATE TABLE TITULO( IDOTITULO INTEGER AUTO_INCREMENT PRIMARY KEY, NOME VARCHAR(20) NOT NULL, NOMEORIGINAL VARCHAR(20) NOT SINOPSE VARCHAR(300) NOT NULL, ANO INTEGER NOT NULL ); NULL,
85
Perceba que neste exemplo alguns campos da tabela foram suprimidos para simplificao. 7.3.5 A aplicao A Figura 23 apresenta a tela principal da aplicao, com o menu Cadastros e o submenu Ttulos.
Figura 23 Tela principal com submenu Ttulos
Ao clicar em Ttulos, a tela de cadastro de ttulos apresentada, conforme Figura 24.
Figura 24 Cadastro de um ttulo
Ao clicar no boto Limpar, os dados preenchidos pelo usurio so limpos. Ao clicar em Salvar, os dados so armazenados no banco de dados. A Figura 25 apresenta a mensagem de sucesso aps o cadastro.
86
Captulo 7
Figura 25 Mensagem de sucesso aps cadastro.
Como no foi construda a tela de listagem (adivinhe quem far isso?), para conferirmos se o registro foi efetivamente feito, temos que conferir no banco de dados. A Figura 26 apresenta o resultado da consulta.
Figura 26 Resultado da consulta na tabela Titulo.
87
Agora que voc viu o exemplo completo, realize as seguintes alteraes sobre ele: 1 Transforme o campo de texto Sinopse em um componente JTextArea com scroll. 2 Inclua uma tela de listagem de Ttulos. 3 Possibilite ao usurio excluir um ttulo do banco de dados. 4 Implemente cdigo, de forma a permitir que um usurio busque um determinado ttulo e consiga alter-lo. O cdigo do exemplo est disponvel no ambiente virtual. Acesse e obtenha-o para realizar o exerccio. Faa o modelo relacional da sua aplicao escolhida. Depois, lembre-se de atualizar as estimativas relacionadas ao banco de dados.
Ufa! Esse captulo foi extenso e pesado no?! Isso porque o projeto de arquitetura de software geralmente complexo, principalmente para programas de complexidade mdia. Porm, voc deve ter percebido que no h muito mistrio. Com a documentao bem elaborada, a implementao se torna uma parte tranquila, e at legal de se fazer. Por falar em documentao, agora que j estudamos todas as atividades do projeto, vamos estudar no prximo captulo o template de documentao. V se preparando para trabalhar em sua aplicao. Comece desde j a projetar e implementar o sistema que escolheu como trabalho para a disciplina.
Aps a leitura do captulo, voc deve ser capaz de: Compreender as vantagens da diviso de cdigo em camadas. Entender softwares multicamadas. Alterar softwares divididos em camadas. Projetar camadas para aplicaes cliente-servidor. Projetar o modelo relacional, a partir do modelo de classes do projeto.
88
Captulo 7
89
DOCUMENTAO DE PROJETO
Estamos chegando ao final da nossa jornada. Este o ltimo captulo do nosso material. Aps estudar todas as etapas do desenvolvimento integradas, acredito que a sua viso de Anlise e Desenvolvimento de Software deve ter mudado bastante. Quando estudamos tudo separado, cada disciplina em um tempo, no temos muita noo de como as coisas se integram ao final. O objetivo desta disciplina foi esse: mostrar o desenvolvimento de uma aplicao do incio ao fim. Para fechar nossos estudos, vamos analisar um template de documentao para projeto. Voc dever, juntamente com seu grupo, realizar as atividades de projeto e preencher o documento. Foi um prazer trabalhar com voc! Espero que tenha sido uma experincia interessante. Abrao e sucesso!
<Nome do Projeto> Documento de Especificao de Projeto 1. Introduo <Faa uma breve descrio do documento. Especifique os assuntos que sero tratados e indique as sees ao leitor.> 2. Plataforma de Implementao <Nesta seo, voc deve descrever e justificar as ferramentas que utilizar no projeto. Cite as linguagens de programao, softwares de apoio, Sistema gerenciador de banco de dados...> 3. Complementao de Minimundo <Nesta seo, faa adendos ao minimundo, se achar necessrio. Pode ser que algum requisito de projeto tenha surgido. Escreva aqui.>
90
Captulo 8
4. Levantamento de Estatsticas <Faa uma introduo consistente sobre a importncia do levantamento de estatsticas.> <Crie uma seo para cada Matriz desenvolvida. Faa uma introduo para cada uma, explicando sua importncia e o mtodo utilizado para chegar aos resultados.> <Insira tambm nesta seo os requisitos de distribuio geogrfica, seguindo o mesmo estilo das matrizes.> 5. Especificao de Persistncia <Faa uma boa introduo da importncia do assunto e explique as estatsticas que voc fez acerca da persistncia. Coloque todos os clculos de crescimento de base de dados nesta seo.> 6. Camadas Arquiteturais <Explique detalhadamente a arquitetura escolhida. Mostre a distribuio geogrfica das tabelas. Mostre um mapa mostrando a distribuio do seu sistema. Mostre os diagramas para cada um dos itens abaixo: - Diagrama de Pacotes da aplicao, se houver. - Componente de Domnio do Problema. - Componente de Interao Humana. - Componente de Gerncia de Tarefas. - Componente de Gerncia de Dados. - Lembre-se de apresentar o modelo relacional. No necessrio inserir cdigo fonte. S os coloque se forem muito S os coloque se forem muito complexos e importantes para a documentao. 7. Concluso <Escreva suas concluses para o projeto. Insira tambm sugestes de melhorias futuras para o projeto e explique por que no foram implementadas. D direcionamentos equipe desenvolvedora.>
Documentao de Projeto
91
Agora com voc! Realize a etapa de projeto para a aplicao escolhida. Interaja com o seu grupo no ambiente virtual e implemente pelo menos um caso de uso completo. Gere a documentao completa do sistema, de acordo com os templates apresentados durante todo o material. ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ____________________________________________________
92
Captulo 8
93
COAD et al. Projeto Baseado em Objetos. Campus:1993. COLOURIS, G; DOLLIMORE, J; KINDBERG, T. Distributed systems: concepts and design. 3.ed. Rio de Janeiro: Addison Wesley, 1994. COSTA JUNIOR, J.M. Processo, ontologia e ferramenta para a gesto de competncias. 2008. Monografia (graduao em Anlise e Desenvolvimento de Sistemas). Instituto Federal do Esprito Santo. 2008. DEITEL, H.M; DEITEL, P.J. Java, como programar. 4.ed. Porto Alegre:Bookman, 2003. FALBO, R.A. Notas de aula. Universidade Federal do Esprito Santo, 2003. NUNES, V.B. Ferramenta case de apoio construo de diagramas de sequencia. 2001. Monografia (graduao em Cincia da Computao). Universidade federal do Esprito Santo,Vitria, 2001. NUNES, V.B. Notas de aula. Instituto Federal do Esprito Santo, 2009. SOMMERVILLE, I. Engenharia de software. 8.ed. So Paulo:Pearson Education, 2006.

TADS Cliente Servidor WEB

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TADS Cliente Servidor WEB

Uploaded by

Copyright:

Available Formats

1

PROF. JOS MRIO COSTA JUNIOR

PROJETO CLIENTE SERVIDOR

Projeto Cliente Servidor

Conceitos importantes. Fique atento!

Indicao de leituras complemtares, referentes ao contedo estudado.

Destaque de algo importante, referente ao contedo apresentado. Ateno!

Reflexo/questionamento sobre algo importante referente ao contedo apresentado.

Espao reservado para as anotaes que voc julgar necessrias.

Tecnologia em Anlise e Desenvolvimento de Sistemas

PROJETO CLIENTE SERVIDOR

Cap. 1 - ARQUITETURA DE SOFTWARE 9

Cap. 2 - APLICAES CLIENTE SERVIDOR 21

Cap. 3 - ESPECIFICAO DE REQUISITOS 27

Cap. 6 - PROJETO DE BANCO DE DADOS 57

Cap. 7 - PROJETO DE ARQUITETURA DO SISTEMA 69

Cap. 8 - DOCUMENTAO DE PROJETO 89 REFERNCIAS BIBLIOGRFICAS 93

Tecnologia em Anlise e Desenvolvimento de Sistemas

Projeto Cliente Servidor

Tecnologia em Anlise e Desenvolvimento de Sistemas

Projeto Cliente Servidor

Durante a fase de levantamento de requisitos, identificamos os requisitos no funcionais.

Tecnologia em Anlise e Desenvolvimento de Sistemas

Requisito No Funcional Desempenho

Quadro 01: requisitos no funcionais e indicaes de arquitetura.

Projeto Cliente Servidor

1.2 Arquitetura Distribuda

Tecnologia em Anlise e Desenvolvimento de Sistemas

Projeto Cliente Servidor

Tecnologia em Anlise e Desenvolvimento de Sistemas

APLICAES CLIENTE SERVIDOR

Figura 2 Arquitetura cliente Servidor Projeto Cliente Servidor

A Figura 2 apresenta a arquitetura tpica de uma aplicao cliente servidor.

2.1 Vantagens da abordagem cliente servidor

Projeto Cliente Servidor

2.2 MVC Model View Controller

Tecnologia em Anlise e Desenvolvimento de Sistemas

Figura 3 Arquitetura Model-View-Controller

Projeto Cliente Servidor

Tecnologia em Anlise e Desenvolvimento de Sistemas

3.1 O que vamos fazer nesta etapa?

Projeto Cliente Servidor

Tecnologia em Anlise e Desenvolvimento de Sistemas

3.2 Estudo de caso: Especificao de Requisitos da Locadora Passatempo

Projeto Cliente Servidor

Figura 4 Diagrama de Pacotes.

Cadastrar Classe Cadastrar Distribuidor

Figura 5 Diagrama de Casos de Uso Controle de Acervo.

Tecnologia em Anlise e Desenvolvimento de Sistemas

Projeto Cliente Servidor

Projeto Cliente Servidor

Tecnologia em Anlise e Desenvolvimento de Sistemas

Projeto Cliente Servidor

4.1 O que vamos fazer nesta etapa?

Tecnologia em Anlise e Desenvolvimento de Sistemas

Figura 06 Diagrama de Pacotes

Tecnologia em Anlise e Desenvolvimento de Sistemas

Figura 07 Diagrama de Classes do Pacote ControleAcervo.

0..n 1 Locacao Pagamento

TipoItem (from Controle Acervo)

0..n 1 0..n Dependente

Figura 08 Diagrama de Classes do Pacote AtendimentoCliente.

Projeto Cliente Servidor

Tecnologia em Anlise e Desenvolvimento de Sistemas