TADS Cliente Servidor WEB

1

PROF. JOS MRIO COSTA JUNIOR

PROJETO CLIENTE SERVIDOR

VITRIA 2010Projeto Cliente Servidor

2

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.36DIREITOS 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

3

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

Projeto Cliente Servidor

4

ICONOGRAFIAVeja, 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

5

PROJETO CLIENTE SERVIDOR

Cap. 1 - ARQUITETURA DE SOFTWARE 91.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 212.1 Vantagens da abordagem cliente-servidor 22 2.2 MVC Model View Controller 24

Cap. 3 - ESPECIFICAO DE REQUISITOS 273.1 O que vamos fazer nesta etapa? 27 3.2 Estudo de caso: especificao de requisitos da Locadora Passatempo 29

Cap. 4 - ANLISE 374.1 O que vamos fazer nesta etapa? 38

Cap. 5 - PROJETO 495.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 576.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 697.1 Dividir para conquistar! 69 7.2 Exemplo de Projeto Orientado a Objetos (Falbo, 2003) 71Projeto Cliente Servidor

6

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


7

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.


8


9

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 CaractersticasNs 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 DistribudaExistem 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.Projeto Cliente Servidor

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.Projeto Cliente Servidor

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 __________________________________________________ __________________________________________________ _________________________________________________ __________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ __________________________________________________ _________________________________________________ _________________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ ______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ ______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ _______________________________________________ ____________________________________________________Tecnologia em Anlise e Desenvolvimento de Sistemas


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 servidorExistem 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.Tecnologia em Anlise e Desenvolvimento de Sistemas

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 ControllerVoc, 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

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 4. Descrio dos Casos de Uso 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: Subsistema: Nome do Caso de Uso: Analista: Data: Descrio: . Curso Normal: . Cursos Alternativos: . 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 PassatempoPara 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.Tecnologia em Anlise e Desenvolvimento de Sistemas


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:Projeto Cliente Servidor

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.

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. ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________ ______________________________________________________Tecnologia em Anlise e Desenvolvimento de Sistemas


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.

Documento de Especificao de Anlise 1. Introduo 2. Modelo de Classes 2.1 Diagrama de Pacotes 2.2 Diagrama de Classes 2.3 Dicionrio de Dados


Anlise

39

3. Modelagem Comportamental 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 emProjeto Cliente Servidor

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 DistribuidorrazaoSocial 1 cnpj pessoaContato endereco telefone nome nomeOriginal ano ator [0..*] 0..n diretor [1..*] nacionalidade [1..*] categoria [1..*] sinopse obterReservaPendente() obterItemDisponivel() obterClasse()

Classe 0..nnome 1 valorLocacao prazoDevolucao obterValor() obterPrazo()

1 0..n ItemnumSerie dtAquisicao estado obter() obterLocacaoPendente() obterTitulo() obterTipoItem() atribuirEstado() estahDisponivel() ehDoTipo()

0..n

1

TipoItemnome

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.Chequebanco agencia conta numero valor

0..n 1 Locacao Pagamentodata valor

ClientenumInscricao nome dtNascimento sexo estahAtivo obter() estahEmDebito()

1

0..n

dtLocacao dtDevolucaoPrevista dtDevolucaoEfetiva valorCobrado multaCobrada estahPendente() calcularValorASerPago() existePagamento() calcularMulta() atribuirDtDevolucaoEfetiva() estahEmAtraso() criar() atribuirDtLocacao()

1..n

0..2 1Item (from Controle Acervo)

0..n

1

TipoItem (from Controle Acervo)

Sociocpf endereco telefoneResidencial localTrabalho telefoneComercial telefoneCelular

0..n 1 0..n Dependente

ReservadtReserva hrReserva dtComunicacao hrComunicacao ehDoTipo() estahPendente()

0..n 1 0..n

1..nTitulo (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..

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.

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

.

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

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. ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ___________________________________________________ ____________________________________________________Tecnologia em Anlise e Desenvolvimento de Sistemas

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 geogrficaUma 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

X

X

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 0Quadro 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. _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________Tecnologia em Anlise e Desenvolvimento de Sistemas

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 DadosPara 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 CrescimentoNa 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 ttulosDez 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 TtulosDez 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 Titulo2016 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 DistribuioUm 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 distribu

Documents

TADS Cliente Servidor WEB